Slashdot Mirror
Slashdot HTML 4.01 and CSS
After 8 years of my nasty, crufty, hodge podged together HTML, last night we finally switched over to clean HTML 4.01 with a full complement of CSS. While there are a handful of bugs and some lesser used functionality isn't quite done yet, the transition has gone very smoothly. You can use our sourceforge project page to submit bugs and we'd really appreciate the feedback. Thanks to Tim Vroom for putting the HTML in place, Wes Moran for writing the HTML in the first place, and Pudge for writing the code to convert
900k users, 60k stories, and 13 million comments to comply. And for the brave, download the stylesheet and start experimenting with new themes and designs for Slashdot: some sort of official contest to re-design Slashdot is coming soon, so you can get a head start now.
Response to some reader notes in the forum:
- There are a handful of validation errors. Some will be fixed in the next day or so. Others are external HTML that is out of our hands. We may never toally validate with zero errors. yes we're comfortable with that.
- We're not going to XHTML for the same reasons as above- we control almost all of our HTML, but some of it (like the ads, and imports from other sites) just isn't ours to muck about with. We could go to XHTML, and someday we might, but today we're happy to just get to HTML 4.01 and CSS.
- Light Mode will be back in some form or another. The problem is that light mode served two purposes: Low Bandwidth, and Simplified Design. The later will probably be handled with a CSS theme (we have a handheld theme already). Low Bandwidth is a little trickier, but we will resolve that soon.
- All of our code is beta tested on www.slashcode.com and use.perl.org. Unfortunately there's always a few issues from those tiny tiny sites and the giant bohemoth that is Slashdot itself.
I was wondering if there was going to be a story on this. I noticed the upgrade last night. Let me be the first (post? ha ha) to say, "Good job guys!" Yeah. it took you awhile. But better late than never, eh?
:-)
/team!
And for the brave, download the stylesheet and start experimenting with new themes and designs for Slashdot:
I was just going to ask if we could get a few more CSS styles like we saw in the Beta. Glad to see you're already on top of it.
I did some testing with a FireFox version I *know* contains the infamous "Slashdot bug". (Not sure if it's corrected in recent versions since I normally use Mozilla or Safari.) As far as I can tell from testing, the bug is completely fixed. Considering the upgrades, one would expect this to be the case, but you can never be too sure.
Last but not least, the "Politics" and "Apple" sections look as nice as ever, but I'm afraid that the other sections look worse than ever. Can we turn off the colors for the other sites until better CSS sheets can be made? (Preferrably ones that don't hurt our eyes?) Yeah, the games section has the full treatment too, but I swear that the shades of purple it uses are causing me to go blind.
An alternative solution to turning off the CSS for the other sections is to provide the front page CSS as a style option on all the pages. That way we could simply shut off the crazy colors without pulling the whole "games.slashdot.org/article.pl -> slashdot.org/article.pl" trick.
Well, that's my 3.14159265 cents worth. Again, good job
Javascript + Nintendo DSi = DSiCade
Yes, and for those of us using "Light" slashdot version (it's in "Preferences" - white background etc, _much_ easier to read IMHO) now it looks like a buttload of shit. $(SUBJ). Will it be fixed?
You mean like this site that has been acting as the beta site for Slashdot?
Javascript + Nintendo DSi = DSiCade
Why don't you guys have a formal testing process in place for slashcode?
They do. Beta code gets tested here before it's put on Slashdot. Now the upgrade process often generates quite a few 503s (since Slashdot is actually down during that time), but it's just a temporary problem.
If you're still getting 500s and 503s, try deleting all your cookies that point to "slashdot.org". Sometimes the upgrades have problems with old cookies.
Javascript + Nintendo DSi = DSiCade
These are the ones I could find in the head:
http://images.slashdot.org/base.css
http://images.slashdot.org/comments.css
http://images.slashdot.org/ostgnavbar.css
http://images.slashdot.org/slashdot.css
http://images.slashdot.org/print.css
http://images.slashdot.org/handheld.css
Long signatures suck.
Because.
There are 11 types of people in the world: those who can count in binary, and those who can't.
Most die-hard firefox users will know this, but since Taco threw down the gauntlet, those mere firefox mortals who wish to muck with the CSS and "win a prize!" can take a look at: Jesse Ruderman's page on using local style sheets (good links there) and there's always the style sheet chooser plus add on (yeah, the site's in French and I haven't tried that extension in a while since I use Safari mostly, but it should work).
Mind the gap...
I let someone else explain this one, but basically you should be using html 4.01 and not xhtml unless you really know what you are doing and have good reason to do so.
http://hixie.ch/advocacy/xhtml
"In a time of universal deceit - telling the truth is a revolutionary act." - George Orwell
http://images.slashdot.org/base.css
http://images.slashdot.org/comments.css
http://images.slashdot.org/ostgnavbar.css
http://images.slashdot.org/slashdot.css
http://images.slashdot.org/print.css
http://images.slashdot.org/handheld.css
my sig's at the bottom of the page.
Because XHTML is harder to write, and browsers can render HTML fine anyway, so what's the point? Yes, XHTML makes a cleaner spec if you're starting from nothing, but HTML is a standard that browsers have to be able to render, so XHTML doesn't make things any easier for anyone.
I am trolling
This topic was done to death last time.
Short summary: there are a few compatibility downsides and there's no real point because there's no benefit to using XHTML yet.
Bogtha Bogtha Bogtha
...get the following fixed? When you browse with a threshold that doesn't show all comments, the page numbers to click are completely broken. Sometimes, when I click on the 3rd or 4th page, I _still_ see the first post according to my threshold.
There is actually no way to view all comments in order. I usually resort to clicking a page way later, like the 6th or 7th until I see a comment other than the first. But then I don't know if I missed any.
The pages seem to count all comments regardless of score. The proper way is to count the posts _after_ the threshold is applied.
This has been bugging me _for ages_!
Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
HTML 4.01 was released on December 24, 1999, so they're not quite here yet...
I am TheRaven on Soylent News
You're in Light Mode. Slashboxes don't appear in Light Mode for obvious reasons (and I believe that's a change from before). Go to Preferences: Homepage and uncheck Light, then save. That should do the trick.
Those are simply empty tags in XHTML, but in HTML4 (and any other SGML application using the Reference Concrete Syntax) they are empty tags followed by ">" characters treated as content. Some browsers get this wrong, but it's not a good idea to rely on it. No matter what W3C claims, it's not really possible to modify a document so a HTML4 parser gives the same DOM as an XML parser--the grammars conflict.
The plan right now is to have a few large chunks of the site drop in and out for a less bandwidth intensive version. Essentially we strip the site down to what must be here: Less menu items, less boxes on the right. Basically, "Title" "Advertisement" "Stories" "Some Menus And Links". VERY minimal. Get the page down to as few bytes as possible. This We'll probably have a stylesheet too, but mainly this page will just have far fewer bytes of stuff.
Design-wise we can create themes for modern handhelds. A generic theme is already available but it's a real quickee job. But now we can create thinned down look and feel customized for any individual handheld. Of course we don't really have any of these fancy devices ourselves, so hopefully readers will help by designing CSS that does just that.
Pants are still optional, but recommended for you.
There is no reason to go to XHTML. Bottom line: most browsers will render it as HTML and not XML, and for those that do render it as XML, we would need to have *perfectly valid* XML or else it would break, and we are not yet at that point, as we still have various invalid things in our source. So there's no reason to bother, not any time soon.
The code can easily handle a switch to XHTML 1.0 Strict, should we someday desire to do that.
We already forced HTML 4.01 strict compliance on comments six months ago. Almost no one noticed.
We already converted 13M comments to valid HTML 4.01 strict. A couple of months ago. No one noticed.
It would be relatively trivial to force XHTML 1.0 strict compliance. I'd flip a switch to force compliance on new content, then rerun the converter for old content. The code's been tested to work for both HTML 4.01 strict and XHTML 1.0 strict (since we allow only a relatively small subset of HTML tags and attributes, this isn't that hard for comments, or even stories, which allows a lot more variety in tags, but everything still fits in the intersection of the two, so it's just a matter of changing a very few number of things, that the code already knows about).
I've read this rant a few times now, and of all of his reasons, none are very compelling.
.toUpperCase() or .toLowerCase() when checking tag names, and you have to be able to detect whether to use namesapace aware functions or not based on which mime type you are using. Also, for sites (like slashdot) that don't use much javascript, this is probably not really an issue.
/>" have very different semantics when parsed as HTML4. So if there was to be a fully compliant HTML4 UA, it would be quite correct to show ">" characters all over the page.
* <script> and <style> elements in XHTML sent as text/html have to be escaped using ridiculously complicated strings.
Or you could refer to external files which you should probably be doing anyways. Besides, it's 2005. Are there still browsers in use that don't recognize the script tag? I haven't run across one in at least five years. Even browseres that don't support JavaScript at least know to ignore the contents of this tag.
* A CSS stylesheet written for an HTML4 document is interpreted slightly differently in an XHTML context (e.g. the element is not magical in XHTML, tag names must be written in lowercase in XHTML). Thus documents change rendering when parsed as XHTML.
Well, the second case is easily solved by writing tag names in lower case anyway. Wow, that was tough. I can't remember ever seeing a non-contrived case where the first was an issue, and even then it could be trivially worked around.
* A DOM-based script written for an HTML4 document has subtly different semantics in an XHTML context...
This is probably his one valid point. I do agree with this one, but also feel that it could be worked around with a little thought if you had a valid reason to use XHTML. Mainly you just need to use
* Scripts that use document.write() will not work in XHTML contexts.
Good! document.write() should have been put out to die years ago.
* Current UAs are, for text/html content, HTML4 user agents (at best) and certainly not XHTML user agents. Therefore if you send them XHTML you are sending them content in a language which is not native to them, and instead relying on their error handling. Since this is not defined in any specification, it may vary from one user agent to the other.
And this is different from sending your document as HTML 4 how?
* XHTML documents that use the "/>" notation, as in "<link
Probably technically true, but I've never seen this "SHORTTAG minimisation" discussed anywhere else, and I can't recall ever having dealt with a UA that treats self closing tags in such a manner.
In short, there are issues to watch out for, but there are a lot of cases when XHTML may be preferable to HTML 4 (e.g. using an XML based content management system), and as the most popular web browser on the internet doesn't handle XHTML when served as application/xhtml+xml (and it has been announced that the next version will not either) and all remotely modern UA's will handle XHTML served as text/html, there are a lot of cases where it doesn't put make sense to put off adoption of XHTML for 2 years or more until the majority of browsers can handle it properly.
That said, HTML 4 is still a perfectly valid alternative, and for a site like Slashdot where there are no compelling reasons to go with XHTML, and a lot of valid reasons for not, I don't see why anybody should complain that the site was done as HTML4+CSS and not XHTML+CSS.
If I don't put anything here, will anyone recognize me anymore?
In a normal browser, that's fine and dandy. However, HTML itself (devoid of CSS) is read and used by other devices. For instance if I am browsing in Lynx, that list makes a huge difference in display and don't even get me started on voice readers and other things.
HTML is not there purely to be used as an anchor for style. It is there to explain what kinds of content a document contains. I mean, why use an h1 - h6 or a p or em or strong? You could simply create contextual style definitions for divs and spans which would, more or less, do everything that other tags do.
I mean really, if HTML was really just there for CSS all you'd need would be , , , , , , , and . You wouldn't even need since you could could just define inline divs.