Over at Slash Central, we are actually working on converting Slash -- including Slashdot -- over to XHTML + CSS.
I'm not kidding.
My current task is taking the code we have to massage your comment and journal text into somewhat reasonable HTML, and making it spit out perfectly valid XHTML. And then converting all existing comments to such valid XHTML.
I'm not kidding!
It's actually coming along well, better than I'd have thought. I took 1,000 random Slashdot comments and ran them through my code and, after fixing some bugs found in the process, got the number of XHTML errors from 7,000+ down to 0. And a side-by-side comparison shows them to still look mostly the same. There's a few small/necessary changes, like putting content inside an UL tag in an LI. Which was a HUGE pain.
A lot more to do, but the progress is encouraging.
Awesome! (Score:2)
I actually think that's great news. Woo hoo! Will you let people apply their own stylesheets?
Re:Awesome! (Score:2)
Re:Awesome! (Score:2)
I seem to recall that this sort of thing happened on advogato a while back, although not as offensive.
-Dom
Re:Awesome! (Score:1)
Re:Awesome! (Score:2)
Re:Awesome! (Score:1)
You're more likely to get the malicious-goatse-attack scenario by external pointing, unfortunately:
This also assumes that the URL can survive the continual Slashdotting of point 2, which is several times less likely than the above attack.
Re:Awesome! (Score:2)
Re:Awesome! (Score:2)
-Dom
Re:Awesome! (Score:2)
oh my (Score:2)
Network IO (Score:1)
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.
ALA's redesign of /. (Score:1)
Something you might want to look at (Score:1)
http://hixie.ch/advocacy/xhtml
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
Re:Something you might want to look at (Score:1)
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.
Re:Something you might want to look at (Score:2)
Re:Something you might want to look at (Score:2)
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
Re:Something you might want to look at (Score:1)
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
Re:Something you might want to look at (Score:2)
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?
Working example; might be helpful (Score:1)
The site's been running for over a year. A few interesting things we've done are:
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