Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I actually think that's great news. Woo hoo! Will you let people apply their own stylesheets?

    • At first, I doubt it. But if there's enough request for it, who knows?
      • Applying your own stylesheets opens the potential for abuse, sadly. It's giving people complete control of the layout. What's to stop some troll from using a bit of absolute position to completely overlay the entire page with a picture of goatse?

        I seem to recall that this sort of thing happened on advogato a while back, although not as offensive.


        • Well, if you allow people to paste raw CSS into their own user prefs, the only people who see goatse are the ones who specifically asked for it. I don't see what the problem is.
          • If we do it at all, it probably would only be in the form of allowing somone to point at a stylesheet URL. That should be sufficient, I think.
            • You're more likely to get the malicious-goatse-attack scenario by external pointing, unfortunately:

              1. Someone creates a nifty new stylesheet
              2. Stylesheet URL gets really popular
              3. Stylesheet suddenly gets switched to goatse, either by hacking or malicious owner

              This also assumes that the URL can survive the continual Slashdotting of point 2, which is several times less likely than the above attack.

              • It's not like we'd be keeping a public list of the stylesheets. If someone wants to link to their friend's stylesheet, that's their business.
                • That all sounds better than what I had in mind -- allowing specification of style="" attributes. That really causes a problem because everybody gets to see it.


                  • Oh, you mean so someone gets your style if they see your page? Yeah, we won't be doing that. For that, if we may decide to accept themes from the community, but we would have to host them.
  • Jarkko and I will both being looking up and watching for the signs that the end of the world has arrived. Next you're going to say that it installs on Solaris without a hitch! :D
  • Aside from the usual it's-about-time comments, I'm extremely curious how this effects network bandwidth.

    I've always found the 'it makes your bandwidth usage smaller' argument of XHTML/CSS to be an intersting one, especially when you look at the before and after numbers of just the file sizes.

    Hopefully after the conversion we'll get a nice tech report on such geeky details. :-)
  • Don't forget ALA's article [] on where they redesigned /. to be standards compliant CSS/XHTML
  • While working on this redesign, you might want to keep a few things in mind, as poited out by the article below.

    to sum it up,

    IE6 does not support application/xhtml+xml (in fact, it does not support XHTML at all)

    Documents sent as text/html are handled as tag soup by most UAs.

    This is the key. If you send XHTML as text/html, as far as browsers are concerned, you are just sending them Tag Soup. It doesn't matter if it validates, they are just going to be treating it the same w
    • 'poited' ? heh I must have been in Pinky & The Brain mode.

      Anyway, I wanted to add that some lively discussion of these issues can be had in the #web channel on Freenode (great bunch of folks by the way. one of my favorite freenode channels.) in addition to more FAQ info linked therein by its helpful denizens.
    • Yeah, I've been wondering if we should bother with XHTML, and this gives me more reason to wonder.

      At this stage, there's no real difference between HTML and XHTML, as long as I we're being XHTML-compliant, except in whether to add the slash to empty tags like <br />. But pretty soon we will need to make that decision.
      • IMHO, Hixie's comments are valuable and interesting, but concerned more with correctness than practicality. Porting a major CMS from tag-soup to HTML in 2005 is a half-measure. XHTML requires little extra effort and is more forward-compatible.

        If you read his page, you'll notice that nearly all of his points against XHTML are of the "unless you're careful, this will bite you" variety. Solution: use XHTML, and be careful. Just internalizing what he writes will give you a significant leg up on the probl

        • The thing is, if we are not going to have perfect XHTML, then there is no point to using XHTML.

          So that is the issue I am going over right now with my peeps. WIll it be perfect, always? If not, why bother using XHTML at all?
  • News4Neighbors []

    The site's been running for over a year. A few interesting things we've done are:

    • full XHTML templates; CSS for all style and positioning
    • photo upload plugin for story submissions
    • a Perl module which sets up enough of Slash code for automated testing
    • a custom plugin to manage organizations, to allow them to edit and publish their own data

    All of it's under version control, but not yet publicly available.

    I did all the templating/styling myself, and I'll be the first to admit that it's