{Part I of a two-part series.}
Ask an IT person if they know what Slashdot’s tagline is and they’ll reply, “News for Nerds. Stuff that Matters.” Slashdot is a very prominent site, but underneath the hood you will find an old jalopy that could benefit from a web standards mechanic.
In this article we will show how an engine overhaul could take place by converting a single Slashdot page from their current HTML 3.2 code, nested tables, and invalid, nonsemantic markup, to a finely tuned web standards racing engine. The goal is not to change Slashdot, but to rebuild it with web standards and show the benefits of the transition.
Before you panic because I’m picking on Slashdot, let me inform you that I asked Rob “CmdrTaco” Malda, the guru behind Slashdot, for permission to post this information, and he stated in his reply email:
Have fun. Feel free to submit patches back to us if you come up with anything useful. Slashdot’s source code is open source and available at www.slashcode.com.
The breakdown#section2
We started by freezing a copy of Slashdot on Tuesday July 22, 2003. Once we had a copy of the page, the first step was to remove all non-essential tags. The only tags left were anchors, lists, forms, images, scripts and header information. From the stripped down version, the code was converted to XHTML 1.0 Transitional, and validated. At this point, the page looks like a minefield of links in a sea of information. It’s valid, but not pretty to look at, so on to the next step.
The semantic conversion#section3
While viewing the now-valid markup, it became apparent that most of the information would be better described as lists. For example, the images for the categories of Slashdot were now just sitting next to each other. Essentially, anything that there was more than two of was put it into a list, for example: login, sections, help, stories, about, services, etc. Lists can be described and positioned in any way that we want, and by stating that elements are part of a list, we are describing their relationship to each other.
The next step was to use header tags. The page has lots of titles and information, but none of the information was described appropriately or explained its relationship to other bits of information. So we gave the title of an article an <h1>, the author information an <h2>, the department received an <h3>, and the “read more” area an <h4>. This then uniquely identified each part of information of an article, while describing the relationship of those parts. Then came the simple part: identify paragraphs, and clean up the code.
The benefit of the semantic conversion is that we are using tags for what they were meant for. It is clear that a list of objects belongs together, and there is a title hierarchy. Another benefit is that this also helps with search engine optimization.
Boxes everywhere#section4
What we have now is a a jumbled mess of well-described information. The information needs to be bound together, with relationships to other information. To begin with, each article is placed into a <div class="node">. Now all information about an article belongs together and all articles are equal, with hierarchy established by the physical order they are placed in.
Next, we uniquely identify each remaining information group, and encapsulate them in their own <div>. For instance:
- <div id=”advertisement”>
- <div id=”header”>
- <div id=”leftcolumn”>
- <div id=”centercolumn”>
- <div id=”footer”>
The purpose of boxing the information into <div> is so that information is logically grouped together, which makes shaping the information easier. The CSS can now address each information group and assign attributes to it, such as layout and design. It’s not necessarily semantic, but it is necessary for the presentation. Here’s the semantically organized example. There’s no CSS layout, yet; it’s just structured markup.
The reconstruction of the skeleton#section5
Now that each information group is identified by a <div>, the page is shaped with CSS so that the design matches the old look and feel. This is a matter of time, patience, and practice. The first goal is not to mimic the old site, but to get things to position themselves correctly in the three-column format with an overall header / masthead and footer. This becomes the first CSS file: layout.css.
The benefit of positioning a page with a single CSS file is simple: you know where to look if there is a positioning problem. Often, if you have a problem, it is usually with the positioning. In this step, we were mindful of the page’s behavior in a variety of browsers, so we choose to utilize the @import feature, as any browsers that don’t support that directive will not get the layout. This includes web-enabled cell phones, PDA devices, old browsers, and other Internet devices. Here’s the page with the positioning CSS applied.
Applying the skin#section6
Now we have the page displaying the correct layout, but it still doesn’t look like Slashdot. The second CSS file that is attached is the markup.css, which contains information about fonts, colors, background images, and the way lists are displayed. Here’s the final example.
We also have the ability to add a second skin if we want to give the user an option on how they want to view the page. The second skin doesn’t have to duplicate all of the layout information, which should already be cached from the layout.css file.
The CSS link#section7
We link the CSS files in the header to complete the transition.
<link rel="stylesheet" type="text/css" href="styles/layout.css" media='screen' /> <style type="text/css"> @import "styles/markup.css"; </style>
In this example, the layout.css file is linked with a media type of screen. This is intentional. The information there is only important for display on a screen, it doesn’t have any benefit for printed media type, or any other (aural, tv, braille, etc.) for that matter. The markup.css file, which is the “skin” of the page, is imported, and thus hidden from noncompliant web devices because some of its features could be harmful or interpreted incorrectly.
Benefits!#section8
The page will now correctly render in standards-compliant browsers, just as it did before, and will fail gracefully for non-standard browsers. So, while the design is not as pretty in very old browsers, the content is still available to their users. It is also much cleaner and more predictable with screen readers. By having the CSS fail gracefully, content is even available to PDAs and web phones. Plus, there are no horizontal scroll bars! Finally, there is also a printer-friendly version using only CSS (no separate “printer-friendly” page). Perhaps the biggest benefit of this particular example is the bandwidth savings:
- Savings per page without caching the CSS file: ~2KB per request
- Savings per page with caching the CSS file: ~9KB per request
Though a few KB doesn’t sound like a lot of bandwidth, let’s add it up. Slashdot’s FAQ, last updated 13 June 2000, states that they serve 50 million pages in a month. When you break down the figures, that’s ~1,612,900 pages per day or ~18 pages per second. Bandwidth savings are as follows:
- Savings per day without caching the CSS files: ~3.15 GB bandwidth
- Savings per day with caching the CSS files: ~14 GB bandwidth
Most Slashdot visitors would have the CSS file cached, so we could ballpark the daily savings at ~10 GB bandwidth. A high volume of bandwidth from an ISP could be anywhere from $1 – $5 cost per GB of transfer, but let’s calculate it at $1 per GB for an entire year. For this example, the total yearly savings for Slashdot would be: $3,650 USD!
Remember: this calculation is based on the number of pages served as of 13 June, 2000. I believe that Slashdot’s traffic is much heavier now, but even using this three-year-old figure, the money saved is impressive.
Everything explained so far is discussed in more detail at the University of Wisconsin – Platteville’s Slashdot Web Standards example site.
The challenge#section9
I now challenge the ALA community. We need a good web standards mechanic (or team of mechanics) to dig though Slashdot’s engine, Slashcode, and make it web-standards-compliant. CmdrTaco has encouraged us to submit patches, and I know we can show the benefits! The challenge is there — any takers?
Next time: printer-friendly and handheld-friendly Slashdot with a few simple additions.
Quite a lot of money! 🙂 Nice layout, I’m sure with more time that site could look a lot prettier to Joe Human rather than to Joe Browser.
I’m just wondering why the center column (the bulk content of the page) is near the bottom of the page with all the left and right column stuff above it? Not that I think that there are many Slashdot visitors using Netscape 4, but also for search engine optimization I thought that one of the points of semantically marking up a page is to get the content as close to the top of the page as possible (something I’m doing while redesigning my own site).
Other than that I think the retooling is a great idea (and a great job was done here) not only for helping to save on code-bloat, but also to bring CSS layouts even futher into the spotlight.
My first thought regarding the xhtml (before getting to the css)was ‘where is the skip to content link?’ After all, there is alot of scrolling in any non-css situation just to get to the most prominate section of the site. But then I see you added the link at the top right corner of the final example and it would appear on the first line in a text-only browser. Good job. That link is the only difference I see between the original and yours.
I wonder: should you have included that link in all the examples and maybe even mentioned it breifly?
Oh yeah, nice print layout, and, if implemented, I would not be stuck with that ugly (in my opinion anyway – thats the beauty of alternate style sheets) green.
FWIW, what you are talking about has nothing to do with Slash itself, but merely the templates/theme. Well, in your case, that’s not entirely true, since slashcode would need a few minor tweaks to work with XHTML, but other than that, it’s all in the templates, not the code/engine. Slash itself cares nothing about whether you use style sheets or semantic tags etc., that’s all up to the site designer.
So would Slashdot let us have the ability to toy with their templates? Or do they use some kind of default template packaged with Slashcode? Essentially, I am wondering if there is any way we can change the publicly available Slashcode to make the eventual template changes to Slashdot.
Quite a feat, seems like the discussion pages would be even more of a challenge though.
Wow, very impressive bandwidth figures! It’s hands-on savings like this that’s going to impress the big ones.
I find it so amusing that ALA decides to make an article out of converting Slashdot’s templates to XHTML. I have been toying with the idea for quite some time, and even started laying the groundwork. I found the steps you took in order to accomplish this task to be rather insightful. My approach was to take it “module” at a time. I think your version of “deconstruction” works well, and I will probably use it in the future.
Absolutely brilliant. Great job. While I am not affiliated with Slashdot in any capacity save having a slashdot ID since 1996, I’d be more than happy to help patch the Slashcode system.
Again, great job!
CMH
Not sure Dan remembers, but I had provided him with a link to someone who is working on an XHTML version of slashcode:
http://strict.openflows.org/
Thanks for the idea of separating the positioning from the formatting. One of those “why didn’t *I* think of that” ideas 🙂 Great article.
It’s a quintessential case study of semantic web design, CSS migration and their benefits. Thank you!
Did nobody notice the big difference between the original and the converted page? It’s quite obvious.
The original page has more than 75% of italic text, as always on Slashdot. The new version of the page has no italic.
If nobody noticed the omission, it’s because it’s SUCH AN DAMN IMPROVEMENT. Congratulations, Daniel, for making the first readable Slashdot page ever.
1). Fix non-standard /. markup
2). ????????
3). Profit!
http://soupisgoodfood.net/area51/frontpage.html
I did that nearly a year ago! I’m sure there are many designers out there with a redesign of Slashdot sitting on their HD. Finnaly someone put it into an artical.
Now the big question: Will we ever see this code used at Slashdot?
Way back in 2001 I recall making the same point — that SlashDot uses cruddy, invalid, bloated markup http://www.macedition.com/cb/cb_20011203.php . And sure enough, pudge came along and pointed out that it wasn’t SlashCode’s fault, it was the templates. Just as has occurred with this article. Two years later, almost to the day, SlashDot’s default templates still have not been updated and made valid, and neither has SlashDot’s template.
That should read: “Two years later, almost to the day, SlashCode’s default templates still have not been updated and made valid, and neither has SlashDot’s template.”
‘Cause y’know if you get the code and the templates mixed up, shame on you.
“I’m sure there are many designers out there with a redesign of Slashdot sitting on their HD.”
YUP
This is an excellent howto/whyto for those of us holding out on standards compliance, thanks.
Definitive proof that standards compliant design is now mature enough for *anything* on the Web. Although I second Joe Kaczmarek’s question (http://www.alistapart.com/discuss/slashdot/#c5665) about why the navigation comes first when you switch the style off. Content should come first but, I’m guessing that positioning gambit won’t really work with a layout as complex as Slash.
Maybe someone should form a volunteer goon squad to systematically clean up all the open source CMS tools (slashcode, PHPNuke, Scoop, the lesser known blog and shopping cart scripts, etc.) out there.
One thing I’d love to see is the use of
First off, I _LOVE_ the alternate look – is it permissable to use the XHTML and CSS in non-slashdot projects?
Secondly, I did a save on the source, and noticed that the output was still ‘pretty’ – ie, nested tags are indented, etc. Although this makes the code wonderful to work on, it is not needed on a site such as slashdot that will auto-generate the code. Instead, a pretty-formated template could be retained in original form, and an automated tool could strip redundant newlines and tabs out of the source.
This all sounds trivial, but it adds up – I get the same exact experience when viewing the page after doing such replacements, and the size drops from the original 33923 to 31870 – a savings of 2053 bytes. Going by the page-views-to-bandwidth calculations within the story, this would save an additional 3GB a day, and thus save slashdot an additional 1095$ a year.
I’m willing to work on the code for slashdot to move to this new system, and provide tools to allow for template size-reduction via the methods described.
MacEdition’s web standards columnist, “CodeBitch” analyzed Slashcode and offered a detailed proposal, based on her own unreleased rewrite of a Slashdot page. She also claimed about a 50% savings in html size.
http://www.macedition.com/cb/cb_20011203.php
I posted this link on /. and called their html “spaghetti code” and I got modded down -2 Flamebait.
Ok, I like ALA, I’m a bit of standards guy even, my whole website is XHTML 1.0 strict. Unfortuanately slashdot has a table based layout, which, to put it simply, CSS cannot handle.
I’ve spent days researching correct CSS tables in the past and it is an impossibility. The problem? Font overlapping. Try a text zoom to as little as 200% (yes, doubling the text size is not that extreme) and all CSS table based designs instantly break. Much like this one.
My site works fine with CSS as everything is positioned such that font size only breaks at absurdly high magnification, but if it were any more complex I’d HAVE to use tables. I’m lucky to need such a simple site design.
I don’t know if this is a browser issue, or a problem with the CSS spec, but text overflow is a serious issue, one which breaks nearly every CSS page using complex layout. There needs to be a way to style tables in CSS without having to use a table tag.
In short, CSS boxes are just that, boxes, they don’t link together to correctly handle font sizes. The new ‘compliant’ slashdot is more broken than the current slashdot in a functional sense, regardless of the philosophical correctness of standards.
As the only person known to have been slashdotted, textismed, *and* zeldmanised in the same week *and* the sole person to have delivered the A part of a Slashdot Q&A in valid XHTM (only to see the whole shebang, DOCTYPE and all, plunked wholesale into tag soup like tofu into miso), it is my honour and, indeed, duty to have slashdotted the article about retooling Slashdot.
http://developers.slashdot.org/article.pl?sid=03/11/21/2223256
This new site has two HUGE problems. First, the content is in a narrow column in the center of the screen, wasting 2/3 of the screen real estate (in I.E. and in NS 7.02). Second, it has problems with text zoom – the text just runs everywhere. Both need to be fixed before rollout. Please!
I just didn’t find the right page. It does flow the whole screen, but the text still doesn’t scale right. (which is an issue for me).
Although it is wonderful to see another conversion of a table-based site to CSS, it seems we are beginning to beat a deadhorse. Anyone who reads this article will already know the benefits of CSS design and when looking at all the tables used for Slashdot it should already be assumed that there would be a great decrease in file size. I think it would have been better to simply redesign the site itself so that it wasn’t so ugly and violated so many usability rules. That would be a great article…
Everything mentioned in these comments are fixable, including Andrew’s “CSS tables.”
Have a look at http://projects.exclupen.com/slashdot/ (does not work well in IE, but that is fixable if there is interest)
– Italics are back (using cite) so you can tell what is contributed and what is editorial remarks.
– I have “jump to” links to the content, navigation, and right-side boxes.
– Labels are used on the forms.
– The content column comes first
– Padding is fixed so some text isn’t touching the edges of the boxes (maybe it’s just a personal pet peeve, but that really bugs me)
– I’m sure there’s more stuff I did, but this was a month ago and I forgot already. 🙂
I’m also willing to help get /. up to speed. Where’s the best place for interested parties to discuss this further?
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
If you add a GZIP filter to Slashdot with the redesign you can save, for the browsers that support it (which is most everything) a lot more space:
Slashdot.html 33654 -> 9955
layout.css 3546 -> 915
markup.css 3511 -> 742
Almost 30k. Put that in your bandwidth bill and smoke it. Hey, lets see what happens with the original page with all that redundant markup:
Original Slashdot 42861 -> 11503
So now if both CSS files are cached you can save .5k per pageview by doing all these changes, or you can just use GZIP compression and get rid of redundant code the old fashioned way — brute force 🙂
Great to hear that Slashdot also seems to go for the new standard.
Now I found something that might help with this: A friend of mine wrote a tool that converts reasonably simple HTML-like XML files into XHTML using XSLT. Perhaps people who are interested in designing their own XHTML 1.0 page want to have a look ? 🙂
For the software go to:
http://www.phil.uu.nl/~gjv/software/sitetools/index.html
For a short documentation, have a look at:
http://www.os3.nl/~jeroen/howto/sitetools.html
It looks horrible with iCab. Hopefully iCab will improve its CSS support soon, but until then we still need to check the website look in every browser and avoid using unsupported CSS features.
The experiment is useful though.
Yep, this is really long, long overdue, so thanks for the efforts!
There’s one problem, and that’s not scaling everything. For example, I like to use a large font, 18 pt at least, as that’s more readable to me. But I’ve got excellent eyesight, there are people who rely on really large fonts just to be able to read the page. If you scale up the final example in for example Firebird, before long, it blows up, because the columns doesn’t scale. That’s slightly irritating. IMNSHO, one should always make sure that the page scales well if users magnify it. (This page doesn’t scale either, BTW).
The other thing I’d like to point out is that things may break if posters post bad code. For that reason, I’d like to Tidy the posts at Preview and Submit. There’s a project to create HTML::Tidy on Sourceforge, but it isn’t really off the ground:
http://sourceforge.net/projects/ptidy
My comment on /. on this:
http://developers.slashdot.org/comments.pl?sid=86694&cid=7535452
I’ve already seen my Strict Slash theme ( http://strict.openflows.org/ ) mentioned a couple of times here.
It’s been lacking updated a while because I’ve been busy at work, but since people are interested in this I can certainly put in the time to get my theme updated to the latest version of Slash ( http://slashcode.com ) that Slashdot uses. And make needed changes to make it more complete.
The goal have never been to make a slashdot web standards theme but rather a web standards theme with it’s own design. But that doesn’t mean it’s not possible to build something like this based on my theme.
If you have any questions about my theme or Slash itself feel free to email peter |at| openflows.org
There’s no layout in NS4.7 – it looks quite crappy. I know life would be so much better without NS4.XX, but it’s still a fact of life in a lot of corporate settings.
My suggestion would be to display the headlines first at the top, and the slashboxes after, in the no-layout version, I think it would render it a bit more useful.
The other problem is that for increased font size, the text starts overlapping other columns… not that big a deal for me.
Despite these problems I still hope Slashdot would adopt it.
Like many people it seems I’ve been waiting for something like this to happen.
The seperation between layout CSS and style CSS is something I have been doing on my site (and I’m going to write up an article about it sometime) and I’m glad to see it in use elsewhere too.
The reworked slashdot example doesn’t work correctly in KHTML/3.1.3, but I imagine its only a minor fix.
Great example, it clearly demonstrates the benefits.
I would however reconsider the id attributes for the divs. The “main” div now has an id of “overall”. That’s fine, but why not call it “slashdot” or something else that indicates what’s inside that div?
The same, and these really bother me ;), goes for the leftcolumn, rightcolumn and centercolumn. One one end we’re removing anything that indicates layout from the html, and here you put it back in?? What if the CSS puts the “rightcolumn” to the left? wouldn’t be much of a rightcomumn would it?
The best improvement, would be one that made the link to the article a (slightly) different colour.
When you first come to slashdot, you are confronted by a sea of links for each article + a read more, it can be confusing to know which is the important link, this needs to be indicated better
just try it, its broken in konqueror.
’nuff said.
In the “Boxes Everywhere” part of your article (which is excellent) you say:
To begin with, each article is placed into a <div class=”node”>
When you’re talking about semantics and self-describing code, I’d thought you would have used <div class=”article”>
While technically that would be a good thing to do, please find a designer to enhance the graphical presentation – it is terrible and cluttered, and optically unstable. Way too many different font sizes and styles and no clear optical style. It is definitely worse than the current design and that already is terrible. Good design is about both beauty and usability. Please also remember to follow the W3C accessability guidelines for people with disabilities.
Instead of just duplicating the old-school Slashdot, why not have a CSS Zen Garden-like competiton to completely re-do its look
Seems to load faster to me, but that might just be because there is no database call.
I have just 2 nits to pick.
First, I think it’s a bad practice to name divs based on their leyout and positioning, i.e., “leftcolumn”, “rightcolumn”, “bottomNav”, etc. Even “header” and “footer” give me problems.
Using that type of div naming convention is comparable to naming a class “12ptRedHelvetica”.
You yourselves demonstrate perfectly why it’s a bad idea – in INDEX2.HTML you display “leftcolumn” on the right, and vice-versa.
I don’t even think it’s a good idea to use the word “column” in the name, as some designers might prefer a 2-column layout, with what currently appears in “rightcolumn” to instead appear at the bottom. Better to use very generic names like “maincontent”, “articleList”, “miscInfo”, “subContent1”, etc.
My only other nit is with the fact that without CSS, your main content displays below the contents of “leftcolumn” and “rightcolumn”. It would be preferable to have it display near the top, as others have mentioned.
As Marshall pointed out, there doesn’t seem to be any place for those of us interested in participating to gather. Where do we go if interested in helping out??
I’m not sure I agree with the ‘semantic conversion’ section. While I agree with the principle, the heading tags create a semantic hierarchy — an H3 is “part of” the H2.
I cannot see any reasonable argument for making the department a subheading under author. The only relationship between author and department is that they are both attributes of the article. Likewise, ‘Read More’ is certainly not a “member of” the department. Again, they are not related.
Imagine storing each article as XML. Would it make sense to store the department inside of the author element? I think most people would make author and department “equal”. Now consider the ‘Read More’ link. Should it be stored in the XML at all? No. There is no content related to the link (on this page). It cannot be a heading to introduce content of the article.
The headings may have been convenient because they did not require new CSS classes, but I do not think they were used in a semantically correct way.
It was a really great article otherwise. Keep up the good work.
I think it’s horrible, for a lot of years it always stayed the same. So I wonder, why didn’t anyone try and remodel the layout to be more appealing? The font they use in italic for example hurts my eyes 😀
I can’t currently send slashdot links to visually impaired friends. They just can’t negociate the page. They can’t even register becuase you need to look at a image to do it!
Contact me if you want some help making it more “blink” friendly.
I noticed a great difference–I use Mozilla Firebird, which “appreciates” web standards, and the page loaded much faster and “crisper.” Besides, I’m an XHTML + CSS freak myself, and this looks kickass.
I noticed that, when looking at the sample sheet with MS IE (6?) installed with AdShield (http://www.allstarss.com/store/adshield.html), the top images float out of positon if an ad is blocked.
When mozilla blocks an image from displaying, the area is left as a ‘blank’ space (well, you can still link to the ad if you click in the blank space), but when Adshield tanks an image on Internet Explorer, it is often the case that the dynamic space set up for the image gets removed, so it is as if the image was never there.
This ‘disappearance’ of the entire ad banner space is causing the ‘slashdot’ logo and topic images to be displayed over the text of the topmost story.
I have a Palm Tungsten C and I regularly surf slashdot.org/palm on my 320×320 screen. Not just presentation is involved, they also do nice things like show the top ranked replies as a sort of discussion summary. Would that be easy to accomodate in your rework?
Whats with all the people posting ‘this seems faster to me!’ Its a static page on a different server, you cannot compare the speeds emperically until it is running live, with all the DB calls, perl evaluation and BW usage that entails.
Organizationally the lists of items (such as: “YRO”, “Older Stuff”) look ugly. Especially for lines that wrap. I’d expect to see lines that start on the left line, and then wrapped text be indented instead of the other way around. But other then that I like the look. (I hate the italisized news header text in the second example style though, hard to read)
I definitely like what you did. The code is a lot cleaner and leverages existing standards. Something I always try to do when possible.
But it doesn’t solve my problem – and I expect the problem for most people here. We have to convince the people who pay the bills that this is worth doing – rewrite legacy HTML. Otherwise it’s just another academic exercise.
The savings in bandwidth on 3-4000 USD / year is not significant for most sites that have as much usage as slashdot. Most sites and web applications out there have a lot less usage and hence will see a lot less savings.
How many person-hours where put into this? Counting discussions and planning as well as the coding? How many hours would be spent putting it in slashdot?
I expect the ‘cost’ to implement this would be at least $30-40,000 USD. That means you have a 10 year return on this work. No business person would consider it. Not to mention the risk of doing it in the first place and the potential revenue lost of having the people work on something else (that has a better return).
What I would like to see is how much this saves in maintenance and bad fixes for the slashdot site. That might make a better business case.
Ya know, I think this very same thing should be done with phpBB. I’m just waiting for version 2.2…
(Spirit)
Thank you for a great article!
This is not only a useful insight into the “retooling” of an existing website but should also be of interest to people planning future website projects.
I look forward to your followup article and have a small request/suggestion, in-line with several comments already posted:
It would be useful to mention what needs to be considered, and/or how you allow, the graceful support of magnification. Many sites CSS driven sites allow only a small amount of magnification before becoming unreadable.
Here’s one thing you didn’t think of. Users can now use their own custom CSS to disable the advertisements:
#advertisement {
display: none;
visibility: collapse;
}
(I think I got that right)
I can only use slashdot in low-bandwidth format (both for visual and crap dialup reasons). So preserving that is high on my personal priorities list 🙂
This CSS is pretty well-behaved in that the non-CSS version degrades to very nearly the normal low-bandwidth appearance. The only notable diff being that the headlines are in a larger font than I’m accustomed to seeing. Of course, how the comment pages degrade remains to be seen. 🙂
In my browser, which does not do CSS (and has js and images disabled), the “skip to content” link does not work. Maybe an ordinary A NAME tag instead of whatever you’ve got right now?
(This form doesn’t wrap… makes it hard to see what I wrote… grrr!)
~REZ~
It is neat to see an entire page that does not include tables.
What software did you use to redo Slashdot’s page or was it done with just a text editor?
Please include any validating software tools too.
What CSS/XHTML reference materials/books/web sites do you recommend?
I would really like to create a standards compliant site but I have problems doing it, even with reading many tutorials and such. If someone is willing to help me get started on creating a good looking layout with only css (I know the basics of css already) then it would be much appreciated!
admin [at] sandwiregames [dot] com
thanks!
In response to the gentleman who claimed the ROI was 10 years:
Your calculations for the lablor involved are _Way_ off.
#1) The real work has already been done by ALA, saving slashdot significantly. Even if done by a real developer, sice it is a translation of an existing design, it would only take 24 hours, at the most, to come up with the XHTML and CSS in the form ALA has it.
#2) With the grunt work done, all that remains is template modifications. I downloaded slashcode and got about 25% done with modifying the templates in only 4 hours. Assume I’m faster than average and/or some ‘snags’ would be hit – you’re still looking at 20 hours. Add 4 for some testing (or do it the slashdot way and put up a test server and let your audience test). Even with work inflation (someone taking their time or documenting things according to a process slashdot has in place) and testing, you’re looking at no more than 26 or so hours.
In this post-boom world, a coder can be had for fairly low prices – especialy when it’s the cookie-cutter work of #2. Assume you pay the high rate of 80$/hour. This may appear low to you if you live in the valley, but its a rate I see all the time in the realworld. Except I see it being charged by companies – I could see a true independant charging less.
So, 80 * 30 (lets inflate more and take into account the time needed to find someone to do it – which wont be much with slashdot) results in 2400$. Add another 400$ for the time of the people approving the result and such.
2800$ – less than the bandwidth savings, so less than a year ROI. Even if the overhead of the internal processes and approvals were higher, you’re looking at a year ROI.
If # 1 were still involved, you’d have a much different picture… but still less than 2 years ROI.
Now, most companies won’t see the bandwidth savings slashdot would get – simply because they don’t have the traffic. However, the resulting XHTML/CSS is easier to modify (content _and_ design), reducing costs to update the site in the future. Without a case study or access to a company’s books (to see the amount spent currently on maintaining and modifying a website), the ROI is much harder to determin. Many companies get redesigns every 2-3 years anyway, so the costs could just be absorbed during one of these upgrades.
Slashdot has a distinct advantage in this case – people will climb all over each other to do the work for free.
Even with the overhead of rolling the changes out, the ROI on near-0$ of changes is hard to argue with.
Have a look at http://software.lottadot.com/article.pl?sid=03/06/17/224243&mode=thread&tid=10&tid=11
Way back when, I took a fresh check-out of slashcode, broke down it’s layout, and started converting to CSS.
You can grab it out of our CVS server if you want to have a look. It’s being used on sites such as the Bookiejoint http://bookiejoint.org (which, if you’re curious about how comments look on a CSS’d site, check it out).
The benefits of CSS’ing, well, all that’s been said numerous times, and we’ve demonstrated that by taking a story that has many thousands of comments and running it under our CSS’d templates. The bandwidth and speed benefits are just awesome.
Anyway, pty started doing one at http://strict.openflows.org and there’s mine over at http://www.lottadot.com/. Those are the only 2 publicly available that I know of. The one at openflows isn’t geared to the standard 3-column slashcode look, wheres mine was inteneded to be a direct drop-in replacement.
Your code seem to have one mistake:
<link rel="stylesheet" type="text/css"
href="styles/layout.css" media=’screen’ />
<style type="text/css">
@import "styles/markup.css";
</style>
Shouldn’t the layout.css be in the @import statement so that browser that doesne support the @import rule doesn’t try to position the page ??
Also, like someone notice before, I don’t really like the leftcolumn class either, not generic enough for my taste. I would also like the main text to be on top but it’s always a challenge with a 3 column layout.
That’s:
Sorry, I though that you didn’t accept HTML caracteres.
“We gave the title of an article an
, the author information an
, the department received an
, and the “read more” area an
.”
The heading tags are for, well, headings. Using them for the author, department and “read more” sections makes no semantic sense, and is little better than the bad old days of using these tags whenever you wanted big bold text.
Much better (IMO) to use something like
instead.
Of course they’re headings; they provide information about the section that follows (or precedes). They’re not paragraphs of text; making them paragraphs is no better than using
If there’s any semantic problem with them, it’s that each of
through
all apply to the same section. If you’re going to be a zealot about saying “Deeper levels of headings MUST apply to deeper sections,” then the solution is that all FOUR of those headings should be
. They all apply to the same section, so they all get the same number.
I personally don’t think it’s necessary to be a zealot about such things, though. There’s nothing, even in the spec, that says
HAS to be the heading of a section exactly one level deeper than
. I see no problem with making it the subheading of an
as long as you’re consistent.
I have a slight problem with
being used for the information in the links, though. That kind of puts the links on the same “level” as the articles, which I don’t think is good.
Also, I think the markup for the “Sections” links is pretty bad. The “n more” lines are treated as list items, which they certainly aren’t. The only things that are
Not to be too negative, though. It’s great to see this done. 🙂
You say, “Two years later, almost to the day, SlashCode’s (sic) default templates still have not been updated and made valid, and neither has SlashDot’s (sic) template. (sic)”
(One would think you would have learned to spell “Slashcode” and “Slashdot” in the intervening years.)
Did you have a point beyond, “I already said this?” It almost seems like you are saying that it hasn’t been fixed is evidence of something in particular, but as it is not evidence of anything in particular — except that they’ve not been “made valid” — your words are a bit confusing.
I must admit I am surprised at the number of posters who seem to think there is some sort of voodoo involved in using (x)HTML in the manner it was intended.
If you’re looking to make the transition away from table based layouts then I can suggest the following resources:
http://www.inknoise.com/experimental/layoutomatic.php
http://css.maxdesign.com.au/listamatic/
While we are on the topic, has anyone ever taken note to how bad the html is behind javadocs, which are now sprawled all over the web? Maybe someone should kick off an initiative to fix those things up and send it over to Sun!
Which tools (Dreamweaver, UltraEdit, etc.) you use ?
thnkx.
j/k
We’re not nerds, we’re geeks. Get it right!
I do all my coding by hand using EditPlus. A majority of serious web coders would probably use HomeSite but I find it bloated and buggy.
Hand coding is the ideal as it gives you an appreciation of the underlying structure of what you are doing, and that’s what markup is mostly about; structuring and presenting a document.
Dreamweaver is ultimately for people who don’t really know what they are doing.
Oh, and Fireworks is the way to go for web graphics.
Nice article, the idea was there but it needs to go a bit deeper. Ideally Slashdot, and it’s underlying SlashCode need to be rebuilt from the ground up, but as stated in the FAQ under “Have you considered PHP?”, which I believe sums up the rebuilding on the whole, “the effort involved in rewriting it would be prohibitive…”
If possible, the site would benefit from being rebuilt from backend to stylesheets, not just to comply with standards, but also to address usability and accessibility issues.
Another thing, not entirely on topic, but after reading the article, I wondered if in the future, instead of “retooling” a site, what about doing an article(s) on creating a site from scratch, from idea to final product, using xhtml, css, php and maybe mysql.
I believe would be good for people to see how things can be done, from start to finish, and in turn learning some lessons on the process/journey/struggle in developing a site.
Fantastic article and great food for thought for those large and popular sites that think it may be ‘too hard’ to keep up with standards.
Thank you for an excellent example to show my clients.
Hell,
I wanted to redesign our institution’s webpage using CSS-P Layout upon knowing its advantage over table-based layout design. I tried starting a page from the templates that come with Dreamweaver MX 2004, Page Designs(CSS). I previewed the resulting new layout design using Opera, Netscape 7.1 & Explorer locally in my computer and was amazed by its control in the overall design. All my three browsers were successful in viewing the sample page.
However, when I uploaded the page into my server, I was surprised to see why it did not show up in my Netscape browser the same way as I previewed it locally in my computer. While Opera & Explorer on the other hand have no problem viewing the page from the server at all.
I tried uploading the same files again to other server and were successful in viewing the page using the three browsers this time.
What seems to be the problem here? A Netscape bug or a server problem? Does a server need to be configured to parse a CSS page design?
Please do check the page:
(this site does not work)
http://wwww.cdc-cdh.edu/css_site/csstest.htm
(this site works)
http://www.feu-alumni.com/css_site/csstest.htm
Regards and hoping you can enlighten me,
Raoul
Raoul: Sounds like a server problem. Mozilla (and thus probably Netscape 6+) won’t read CSS files that aren’t sent out by the server with the MIME type “text/css”, at least not if the HTML document has a fairly recent doctype. This is not a bug in Mozilla, but I think it’s unnecessarily strict.
To fix it, the server should just be instructed to send out files ending with “.css” as “text/css”. Under Apache, this can be done either with a .htaccess file (I don’t remember the exact syntax, though. Anyone?) or in the global configuration (which I’m not familiar with at all), if you have access to that. Under other servers, I’m not sure how to do it.
“id = name [CS]
This attribute assigns a name to an element. This name must be unique in a document.”
— http://www.w3.org/TR/REC-html40/struct/global.html#adef-id
It looks good – but as with many of these layouts then when you reduce the width of browser window all the elements start colliding and looking a bit odd. I’ve stuck with tables for “stretching” layouts so far because of effects like this, despite a string desire to switch to a div based layout. Any ideas?
“Next week: printer-friendly and handheld-friendly Slashdot with a few simple additions.”
so, it already 9 days since the article came out. where’s part two?
Honest question here, but how is that so many “standards” examples and practices involve pages that make such heavy use of javascript?
Not only does it make the site useless for those visitors without javascript (either disabled due to paranoia or weak mobile browsers), but for all the talk about bandwidth savings javascript remains a client-side service that requires every client to download it — even if it doesn’t apply to a particular client.
Surely there must be a server-side platform/language out there that can manage all the benefits of providing “web standards” without requiring the use and download of javascript?
I agree with Greenie above, I don’t know why people use Javascript for so many things.
A website should still be functionnal without javascript. There is more people out there with javascript disabled/not available than there is people using 4.0 browsers, and still people use Javascript without even thinking about it.
I’m all for standards-compliance and all, but there’s so many silly things possible with javascript that I always leave it disabled for fear of being annoyed by the current (stupid and useless) funny craze (such as images following your cursor).
If you can’t make a website that won’t work without javascript, a lot of people don’t even bother enabling it, they just go elsewhere.
In my opinion, Javascript is only useful for forms and similar cases.
Greenie wrote: “Honest question here, but how is that so many “standards” examples and practices involve pages that make such heavy use of javascript?”
Don’t know what you’re talking about. The answer is that, to the best of my knowledge, many “standards” examples and practices don’t make any use at all of JavaScript.
Or did you mean to reply to the “JavaScript Image Replacement” article? Well, that’s kinda like the exception that confirms the rule. If you look around the websites of people who take web standards seriously, you’ll find that they’re avoiding JavaScript as far as humanly possible, even in cases where JavaScript has previously been considered the only solution.
When said people resort to JavaScript, there usually aren’t any other options. One example that springs to mind is PNG images. IE/Win doesn’t support alpha channels in PNG by default, but there is a way to make it, using JavaScript a la Microsoft. There simply isn’t any other way to achieve it. Certainly not server-side. But of course, there’s always the option of not using PNG alpha at all, or not caring about it working properly in IE/Win.
“Did you have a point beyond, “I already said this?” It almost seems like you are saying that it hasn’t been fixed is evidence of something in particular, but as it is not evidence of anything in particular — except that they’ve not been “made valid” — your words are a bit confusing”
Yep, I had a point, and I think everyone else might have seen it: Despite the issue being raised several times over the years, including by me two years ago, SlashDot’s administrators still haven’t fixed their site’s templates. Given the claims on the SlashCode web site that this is easy, the fact that it hasn’t been done for SlashDot is evidence that either the SlashDot administrators don’t care enough to fix them, or they don’t know enough about HTML/CSS to know how to do so. I suspect the former, but I’m willing to believe the latter.
[sorry about the delay in replying, I’ve been on the road AGAIN]
flaimo wrote:
>>”Next week: printer-friendly and handheld-friendly Slashdot with a few simple additions.”
>>so, it already 9 days since the article came out. where’s part two?
delayed by the u.s. thanksgiving holiday i should think
Precisely. We celebrated Thanksgiving instead of publishing another issue of ALA.
The next ALA issue comes out Friday 4 December and will include Part II of the Slashdot article.
I just changed the copy to read “Next time” instead of “Next week.”
hi,
there were complaints, about that the css enabled page does not scale well, if using very large fonts.
I’m not an CSS expert, but playing around with the proper display value, it should be possible to make content, leftcolumn, centercolumn, and rightcolumn to behave like a table.
This way the font-scaling problem might get solved.
Quote:
It looks horrible with iCab. Hopefully iCab will improve its CSS support soon, but until then we still need to check the website look in every browser and avoid using unsupported CSS features.
Dude, iCab has had zero CSS support for the past four years. It is for all intents and purposes dead. The only people I can see continuing to use it are die-hard Microsoft haters running Mac OS 9. On OS X, there’s no shortage of standards-compliant browsers. At this point iCab can be considered a browser with roughly the functionality of lynx.
“The next ALA issue comes out Friday 4 December and will include Part II of the Slashdot article.”
Friday 5 December? 😉
>> Friday 5 December? 😉
yeah, yeah. it’s out now.
http://www.alistapart.com/issues/165/
Am I the only one that thinks markup should never contain words like “leftcolumn,” “centercolumn,” and “rightcolumn?” What if an alternate stylesheet has the columns switched? What if a future version of the page doesn’t use columns at all?
Yet I see this all the time. Sometimes the markup is as horrible as “bluetext,” “bold,” etc. This is not what CSS is all about.
The slashdot redesign contains the following code:
Just wondering if you used a guideline for whether id was used in place of class. I suppose I would base my decision to use id for structural elements that do not repeat. Is there any other reasons?
Ref: http://www.alistapart.com/discuss/slashdot/2/#c5678
Peter,
I know this is a few months after the event but as a hosting compnay that’s been trying to deliver a solution around the basis of the /. site these three things that you cite are really important:
1). Fix non-standard /. markup
2). ????????
3). Profit!
They are all things that we’ve had months of hair pulling and a majority of it is the inability of the coders to use any form of standardisation, let alone WS.
No’3 is the hardest for us to come to terms with as virtually no-one this year is going to look at re-tooling unless there’s visible profit!
McQ