Retooling Slashdot with Web Standards
Joe Clark writes "Nearly a year after an interview with this correspondent highlighted a few problems with Slashdot's HTML, Daniel M. Frommelt and his posse have recoded a prototype of Slashdot that uses valid, semantic HTML and stylesheets. Frommelt projects four-figure bandwidth savings in the candidate redesign, were it adopted, not to mention better appearance in a wide range of browsers and improved accessibility. Next he needs volunteers to retool the Slashdot engine. And yes, he did it all with CmdrTaco's blessing." Slashdot has kept its HTML 3.2 design for a long time ("because it works"), but perhaps this effort will be a catalyst for change...
That's not true.
IE's character code handling is heuristic if no character code is specified in the HTTP header or the HTML head block.
It scans through the page and tries to match the character frequency against average character frequencies for various languages. If you're seeing Slashdot as Big5, then that means IE thought that the character frequency matched Big5 most closely.
If XHTML, there are some things to consider:
It's important to note that using XHTML 1.1 requires you to send your documents as XML. This means the document should have an XML declaration above the doctype, and needs to be sent with an XML mime-type, ideally application/xhtml+xml. This has a significant drawback; IE can't see it.
A fairly well established workaround is to use mod_rewrite and munge the mime-type of a document based on what a user agent sends in its Accept header (To date, Mozilla is the only browser to include application/xhtml+xml in its Accept header). However, some would argue that this too has drawbacks. Since only Mozilla understands application/xhtml+xml, your documents will be sent as text/html, and XHTML does not validate as HTML.
The arguments around this issue have been summarized in the widely linked "Sending XHTML as text/html Considered Harmful"
BeauHD. Worst editor since kdawson.
This is an elegantly-designed page, and a nice recode of the original.
For the last several months I've been working on the same project from a slightly different perspective. We have a working Slash-based site, currently in live beta, at http://www.news4neighbors.net.
The site doesn't validate, but it's all structural XHTML with CSS for layout and style. This is much rougher than the beautiful markup presented here, but the difference is that nearly our entire site is running this template system. My work is based on the Openflows strict theme, released early this year at http://strict.openflows.org. But not much of that theme is left, as their project and mine had very different goals. I've changed all of the 120-something templates, and much of the code that sends them data.
The site needs a lot of work, no doubt. But we're developing it rapidly, and have made much progress.
The biggest challenge is that Slash itself doesn't separate content from presentation from business logic. To change one set of tags you may have to rewrite a template, change a database variable, write some Perl, or a combination. This isn't a knock on Slash -- it's very powerful and I enjoy using it -- it's just that the presentation layer hasn't been their focus.
The end-goal for this project, Slash-wise, is to have a fully XHTML/CSS compliant theme that people can easily use on their sites.
If you want more information about it, send me email at randall -at- sonofhans.net
[ FYI, I also posted this in the ALA discussion ].
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
I'm a blind /. user and I use either JAWS interfacing with IE (yes, I know, windows sucks but Gnopernicus is not there yet) or command-line browsers such as lynx and links. For the most slashdot works alright, and I'd say CSS and XHTML only affect people using more semantic tools, like those who use Emacs to browse.