Slashdot Mirror
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...
Could you please make page 2 of comments actually be page 2 of the comments. I might be incredibly naive, but it seems something more like page 1.5. I don't know about the rest of you, but I always just read the odd numbered pages of comments, because like way too much stuff if repeated from the previous page on the even numbered ones.
but perhaps this effort will be a catalyst for change...
How about a new look altogether?
I had a look at the new site, and while it does fix many problems and should certainly be used to replace the existing setup, why not go a little farther and retool the look of the site as well?
The look of slashdot has barely changed since the late 90's, and while the look certainly brings part of it's character, it's beginning to look dated. Perhaps it can be redesigned with a more effecient and cohesive interface while still retaining some of it's previous character?
Or is it just a pipe-dream...
I would expect such blatant racism on Fark, but on Slashdot? Mods please ban this asshole.
that's almost as standard as you can get.
perl -e '$_="\007/4`\cp%2,".chr(127);s/./"\"\\c$&\""/gees
This is long long long long long overdue. Just because HTML 3.2 "worked" didn't make it good, or right. A proper application of [X]HTML and CSS can be a huge bandwidth saver. It looks like Google also updated their design yesterday or today - no doubt to subtly cut down on the huge amounts of bandwidth they serve out. More importantly for Slashdot, however, is that writing their code in an open and updated fashion really opens up the market for the kinds of people that can access the site, and that's never a bad thing. So congratulations on starting this project, and I hope it gets underway soon!
.sig!
Now maybe I'll finally be able to change my
When the time comes, please add some code to switch to a light design when browsing with a PDA. I know right now you can select light mode, but it affects all browsers used from an account which isn't at all what I want...
Perhaps you could add a section to preferences that lets users choose which color schemes to use on all of the Slashdot sections. If they don't want to set the same color for all sections, let them choose a default (individual settings for each section would probably eat up a lot of space).
It would be GREAT to see them finally, 3 or 4 years later, dump the old theme and streamline it with CSS and stuff. Is it going to happen anytime soon. Probably not.....
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
Now that you've made slashdot standards compliant, why not make it look good? CSS has powerful leading, word spacing and font tools (all of them with relative measurements to look good across most browsers). If a browser doesn't like a text attribute, it won't display it, so you won't have to worry about the same unpredictability as you would with layers and div boxes. The one thing that sucks the most on slashdot is its typesetting. Type is the one thing web designers forget about, but doing it right drastically improves the appearance and readability of a site.
Fuck html standards, I'd like to see slashdot live up to basic community standards.
is a bad idea. Personally, I like it. Reducing the necessary bandwidth to use the site is a good thing though for everyone involved. Why spend money you don't have to in a down economy.
/. is not an issue so what's to prove by changing the look? Gain new users? Have more impact?
/. would prove to be a mistake.
Things do look a bit dated, but maybe that is a good thing. The popularity of
Anyone that matters knows the site already. The content is the reason they return, not the pretty icons. Getting more impact through a more compelling rendering might matter to a few folks, but will the expense be worth it?
Maybe this is the wrong comparison... Take an established publication like the Times or WSJ. Do they make big changes often? No. The formula works and is a big part of their identity.
I think they keep things the way they are because they know change works against the needs of their readers; namely, access to relevant content easily.
Unless I am missing something, major changes to
Blogging because I can...
This is the classic response to that comment (about wasteful whitespace), yet I don't buy it.
a) Totally guessing, but about 99.9999% of the pages served up are interpreted by "no one" other than the browser. It's more "readable" by the browser minus the whitespace.
b) Most pages, like this, is "mechanically generated" - What you see in the final results was rendered: It isn't the "source-code". As such there is absolutely no code maintenance issues.
What you're left with is the prospect that maybe one out of every million page hits is going to a Slashdot developer who's debugging that the rendered properly, though if it's XHTML transitional then a XML editor would be a great choice and would again make it irrelevant if it's clogged full of waste whitespace.
Not a flame.
If you're thinking of retooling the slash engine itself, I hope you consider some of the oft-complained areas for the most improvement. Things get mixed up in any random-access submission "queue" engine, but slash seems to suffer from these things often. Even editors have grumbled about not seeing other editors' status on various stories.
[
Well that's one of the key reasons to convert it - an alternate stylesheet can be provided for PDAs, though I don't know if any actually use it -- but more importantly it will lay out in clean text and respect the semantic structure, showing headlines (H tags), paragraphs, lists, etc., so all the freaks here could check it on their phones and such constantly and it should be good and readable.
Good article, just a couple of suggestions...
In general, it's usually better to avoid giving layout-suggestive names to your div tags. In the example, the author calls the Login/Sections/Help div leftcolumn. It would probably be better to name it something that is more suggestive of it's content rather than it's location - this way, if in the future a new skin was added that moved the content to the right-side, or even bottom of the page, the div name wouldn't contradict it's location.
Another suggestion would be to disable all images in the print.css file. The author already went ahead and disabled the advertisement, the left and right columns, but he left those pesky story icons. I know that when I print an article, usually all I care about is the text. It's a simple way to make a page a little more printer friendly.
My last suggestion would be to move the content div tag, up near the top of the page. This way, as your browser downloads the information from the server, it will download the story information (important) before downloading the left/righthand content panes (unimportant). If someone stops loading their browser before the page download has been completed, at least the browser can attempt to render the story data. And with css, the layout will be preserved.
how about eliminating all of the completely wasteful, bandwidth and processor consuming, whitespace?
As you point out, XML, CSS, and ECMAScript, unlike Python, are not very sensitive to whitespace. Slashdot can mitigate whitespace's contribution to bandwidth in two ways: 1. mod_gzip (which Slashdot already uses), and 2. caching proxies that strip excess whitespace. But this article itself is intended to be read by developers, and clarity counts.
Will I retire or break 10K?
Come on, Slashdot still hasn't converted its GIFs to PNGs. That alone would save a good amount of bandwidth, not to mention that Slashdot is supposedly pro-open source and all that.
The only argument I've seen against them is for compatibility's sake -- honestly, I would be surprised if even as much as 1% of Slashdot's readership was using an image-based browser that did not support PNGs. There are probably plugins available for the ones that don't. So, why not?
Karma: Terrifying (mostly affected by atrocities you've committed)
Fast page loads would be one thing. Do a view page sometime and see all the CRAP that is in there. If you could reduce it then you could be speeding up your web viewing (slashdot reading) experience, and unclogging/freeing up Slashdot's bandwidth. Sounds like a win/win to me.
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
However, someone sufficiently motivated can rip it out and slap in something new. Sometimes people end up rewriting amazing portions of software when it's big enough. I'm not sure slashdot really does enough to warrant that kind of manhandling, it might be better to start entirely over.
But then, I've never looked into slashcode, because while slashdot is a fine site, I would never want to run it. I'll learn a lot more if I write my own code, and I don't have lofty goals for my website.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
There's no way to tell a DIV to be a certain width & height, but grow larger if the content demands it. Feel free to post some html and prove me wrong.
I'm being facetious of course -- Tables are only better because they have certain features that weren't included in CSS for whatever reason.
I don't see why so many sites have such a fetish with tabbed and spaced HTML when the browser discards it as garbage bytes,
Whitespace isn't going to be your biggest bandwidth waster. So why not leave human readable.
actually wasting time (albeit a tiny amount, but nonetheless) parsing through it.
Why don't you measure it and compare it to other optimizations before you recommend that people spend their time changing it? "Premature optimization is the root of all evil", or something like that?
I'm not really up on my css, but I would guess a solution would be to have the centre column floating next to the left column, or to define the distance from the left hand side in em units instead of pixels.
Or the CSS property overflow , which could be used in a variety of ways to make the text visible when it gets too large for the column.
Er, 'fontface'? WTF is a 'fontface'?
As for CSS resizing automagically, resize in relation to what, pray tell? A box with width: 30%; resizes in relation to the viewport, a box with width: 15em; resizes in relation to font size, as of CSS 2.1 a box with float: left or float: right and no width resizes in relation to content (most browsers--including IE/Win--do this anyway) and table-layout will get you table-style layout with whatever tags you like. MS just didn't feel the need to support it in IE 5/Win or IE/Mac so people don't use it much. That's Microsoft's fault, not the W3C's
Ian Hickson edited the CSS2.1 spec, and he's been 'solving real world web design problems' since at least 1998 when I worked with him at the Web Stanards Project. Hakon Wium Lie edited CSS 1, 2 and 2.1 and has been working on Opera since 1999, earned an MS in Visual Studies from MIT and wrote his thesis on electronic display of newspapers. TantekCelik is responsible for the widely-lauded Tasman rendering engine used in IE 5.x/Mac. These people do use this stuff in the real world, and if you don't like the directions they're taking your'e free to join the www-style discussion list and let them know.
One line of CSS is 'a bunch of work'? I suppose you find tying your own shoes a pretty onerous task as well?
Let me get this straight: you're hacked because the site doesn't use your settings for font size and face, but setting your browser to override the site's settings with your choices is 'undesirable'? Huh?
I don't know if this si a browser issue, or a problem with the CSS spec, but text overflow is a serious issue, one which breaks nearly every CSS page with complex layout in existance.
Yeah, you'd think somebody would come up with an " overflow " property and put it in the CSS spec to fix that, wouldn't you?
Snarky comments aside, most problems with layouts being broken by text magnification can be fixed with careful design. Yeah, it takes some work, but generally no more than what you'd put in nesting 800 tables...
I hope they implement ASAP.
But there is another challenge, and that's the posts people write. Anybody care about their code? For example, quoting, to do it properly, one should write: <blockquote><p>blah, blah</p></blockquote>. That's an awful lot of typing.
A page is not going to validate unless the posts are correct.
The way I have planned to do this on one of my sites, is to make sure that every time somebody clicks "Preview" or "Submit", the post is handled to Tidy for sanity checks and conversion. By using preview, you can correct you're code, but you can never submit something that isn't well-formed.
I'm using Perl too, not Slashcode, but AxKit. Nevertheless, a good Perl implementation of Tidy is still lacking. There is a HTML::Tidy project page on Sourceforge, but it hasn't really gotten off the ground.
Does anybody else want to work on this, or do you have other ideas for cleaning up posts?
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Whitespace isn't going to be your biggest bandwidth waster
True enough, but you don't always have to take on the biggest foe first - whitespace is one of those things that was actually intentionally added (it was more work to cleanly whitespace), so it would actually be less work to have skipped it.
Why don't you measure it and compare it to other optimizations before you recommend that people spend their time changing it?
Slashdot serves up millions of pages a day. One useless tab is several MB of Slashdot's bandwidth for absolutely no, or little, gain. I don't need to measure it (and, quite simply, I don't care enough too, though if someone wants to they can grab the tidy utility from the W3C, which strips out whitespace) to see that there is considerable waste in there. In the grand scheme of things it really isn't that much of a hit, but given that it was work to add it...
The article suggests as a consequence of the CSS-based implementation that printer-friendly and handheld-friendly views would be available. Now that's surely going to be the killer argument for many of us. How much time would I save if I could read slashdot comfortably on the way to and from work? I'd get my life back finally after five years of being glued to my desk every evening...
During development, people have to look at the generated HTML. To preserve their sanity, they use whitespace. Removing whitespace would be extra work (and it would end up being put back in by the next fellow who had to work on that code).
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Don't forget the 'light mode' in your /. preferences. Makes this site a lot more palatable even on full graphical browsers.
Escher was the first MC and Giger invented the HR department.
Having read some of the other posts in this thread, there is a solution--DON'T use TABLES!!! I personally think that tables are a bad idea, and should be avoided at all possible.
In most cases, one can replace tables with division tags, which work much better in general. The only caveat is that IE tends to break CSS based DIV tags if you use the wrong type of positioning. To be specific, if you use position: fixed; IE will NOT position this correctly, and really has trouble with multiple elements being fixed position. Mozilla actually fixes this position relative to your screen, not the rest of the page, allowing things like floating menu bars without crazy javascript solutions.
It would be possible, (not necessarily convenient or easy) to migrate to a non-table based layout that would LOOK just about identical for most people, and solve the problems you mention.
"We don't know what we are doing, but we are doing it very carefully,..." Wherry, R.J. Personnel Psychology (1995)
I use this all the time with Smarty output filters.
In development the filters are disabled, when it goes to production they strip white space and single line comments.
Combine that with Smarty caching and phpa and you get dynamic PHP pages that perform like static ones.