Retooling Slashdot with Web Standards Part II

by
Published in Accessibility, Browsers, CSS, HTML
A note from the editors: Part II of a two-part series.

In Part I, we showed how Slashdot could save money and reduce bandwidth requirements by converting to semantic XHTML markup and CSS layout. In Part II, we explore how standards-compliant markup and deft use of CSS could make Slashdot (and your sites) play nicely in print and on handheld devices.

Article Continues Below
Article Continues Below

Printer-Friendly Slashdot#section2

The print.css file adds a feature
that Slashdot didn’t have before, and it is only 10 lines of CSS code. We
simply turn off the floating on each <div>, and then do a display:none;
on any <div> of information that is useless to a printed documented, such
as search, advertisements, etc. (The ALA 3.0 print style sheet takes a similar approach. — Ed.)

Finally, the file is linked with the
appropriate media type so that the CSS is only applied when the browser calls a
print command:

<link
rel="stylesheet" type="text/css" 
href="styles/print.css"
media='print' />

The Slashdot site now has a printer-friendly version without specially designed web pages or server-side scripts.

Handheld-Friendly Slashdot#section3

Handheld Internet devices are
dramatically increasing in popularity. So why not build the website to take
advantage of these devices? The problem that most developers have with this boils down to: “I don’t have a bunch of handheld devices to test on!” An easy
solution is to get emulators. Here are a couple of links to some that I use:

Let’s take a look at what Slashdot’s website used to look on the Openwave Phone Simulator (figure 1).

[Image shows original Slashdot site as displayed in the Openwave Phone Simulator. The layout is fragmented and the majority of the text is invisible.]
Figure 1

Notice the major problem? There is
black text displayed on a black background with no way to select the text to
see what it says! The only words that are visible are links. This happened
because in the 3.2 HTML document the code states: <body BGCOLOR="#000000" ...>.

That’s fine for most browsers since
later in the document, there are other background color changes via tables, but
the table structure was completely broken to fit the cell phone display. For
example if you look toward the top of this same web page, you will see just
where the tables were broken to make the document fit (figure 2).

[Image shows detail of original Slashdot site as displayed in the Openwave Phone Simulator. The table-based layout displays text in two-letter sections, one above the next.]
Figure 2

You can almost read the page: “Lo…gi…n W…hy Lo…gin…?” Now let’s take a look at
the web standards version that was re-constructed using XHTML and CSS (figure 3).

[Image shows original Slashdot site as displayed in the Openwave Phone Simulator. The article title and author information display in their entirety.]
Figure 3

This is displaying the same location
in the web page as Figure 1. The only difference is the code is following Web
Standards. No additional code changes were necessary.

Let’s take a quick peek at the Palm
Emulator viewing the old Slashdot code (figure 4).

[Image shows original Slashdot site as displayed in the Palm Emulator. The layout is much too wide to fit on the screen and would require extensive side-scrolling to view even the article title.]
Figure 4

The first thing you notice is that
there is a left-right scroll bar in the display window. It’s a lot like looking
at a web page though a microscope. You can view the information if you don’t
mind scrolling. The page is set up to display on a computer screen, not your
handheld screen.

Let’s compare it to the web standards version of Slashdot (figure 5).

[Image shows retooled Slashdot site as displayed in the Palm Emulator. The article title, author information, and category information display in their entirety.]
Figure 5

What a clean display using web standards!

But I can hear you saying, “Hey,
there’s a horizontal scroll bar!” Yes, I know. If you look at the “Adopting
Open Source” article on the page, you will see that the department name is, “the
don’t-worry-they’ll-print-more-money dept.” That’s a 36-character word that is
too big for the display! So that is actually a problem with the content, which
of course I didn’t alter!

As in Part I of this series, everything explained so far is discussed in more detail at the University of Wisconsin – Platteville’s Slashdot web standards example site.

23 Reader Comments

  1. I think portability across devices is one of the most important aspects of the XHTML/CSS combo.

    To have printer and handheld friendly pages without duplicating your content is a boon and should be something that most on-line publishers can advantage of.

  3. I’m trying to find out if many of the handheld browsers even support the handheld media type. If they don’t you won’t get very far with this approach. 🙂 The one I’m most insterested in at this point is Plucker (http://www.plkr.org) and Avantgo.

    (P.S. @Jeremy, read the article again, it says where to get the Palm emulator.)

  5. Another good way to test a site for suitability for handheld devices is to download the Opera 7.2x and try the SSR (Small Screen Rendering ) mode by clicking Shift-F11.

    What this does, is change the layout of the page and “fold” it into a format suitable for handheld devices, losing some layout, but making the content easily available. If there are stylesheets for @media handheld, Opera will use those styles and not SSR.

    This technology is available both in Opera’s desktop versions and on all the mobile versions that are currently being shipped with Nokia devices.

    Using this technique also shows a major shortcoming of the Slashdot redesign. Don’t get me wrong, I loved the article, but the redesign isn’t perfect yet. Which shortcoming am I talking about?

    SSR renders the page in order it encounters the content in the code. In the redesign, the code containing the actual content of the page, the articles, is at the end of the file. So when I turn on SSR, I first get a huge list of links, sections, logins etc. before I finally see the content. When using SSR on the normal /. page, the content is at the top.

    So for the redesign to be even better than it currently is, it should try to move the code around, putting the actual content more towards the top.

    Another tip for making pages more suitable for handheld devices, is to write a separate stylesheet for @media handheld, and to hide certain sections that are irrelevant to handheld users, like Poll, bookreviews, freshmeat etc. This can simply be done with display:none; in the handheld stylesheet.

  6. Hal brings up an interesting point. It seems many hand-held browsers try to fool the website into thinking they are “just another NS/IE variant”. My suggestion is to write to the authors of the applications to make sure they submit themselves as “hand-held” media

  7. operas support for @media handheld is somehow weird. including it with

    @import url(handheld.css) handheld;

    works; including it with

    @import url(handheld.css);

    and putting the @media handheld {…} inside the css file doesn’t work. it’s interesting that this second method works with all the other mediatypes, but not “handheld”. so from now on my htm file looks like this:

    othermedia.css looks like this:

    @media all {
    /* supported by IE, Mozilla, Opera */
    .class {
    }
    } /* end all */

    @media projection {
    /* supported by Opera */
    .class {
    }
    } /* end projection */

    @media handheld {
    /*
    not supported this way;
    please see handheld.css;
    supported by Opera
    */
    } /* end handheld */

    @media print {
    /* supported by IE, Mozilla, Opera */
    .class {
    }
    } /* end print */

    @media screen {
    /* supported by IE, Mozilla, Opera */
    .class {
    }
    } /* end screen */

  8. Thanks! This was definitely worthwhile.

    Take it for what it’s worth, but I know that Mark PIlgrim will always insist that navigation should be at the bottom for text-browser users, and that main content should be first (http://diveintoaccessibility.org/day_10_presenting_your_main_content_first.html).

    This is especially true, I should think, for a page with as much menu as Slashdot. If you look at the no-CSS example rendered, it takes me three screens at 800×600 to get to content. Frankly, I’m not going to be anywhere near as interested in the menu as in the content, if I’m reading Slashdot in Lynx.

    Someone mentioned this above in passing as a problem for small-screen devices, but it’s also a problem for screen readers and, frankly, NS4 and IE4 users, who do still exist.

  9. If you look at the CSS version, the first item to appear in both Small Screen Rendering in Opera 7.21, and in Lynx is a “Skip to Content” link.

    The whole idea was to show a Slashdot redesign without adjusting the content, thus the skip link to jump over the menu.

  10. just found out that i was using opera 7.11. a look at the changelog shows that they fixed that handheld-media bug with 7.20….

  11. I had this problem on my own site and had to add an anchor statement with a name attribute to skip to, otherwise the skip link does not work with the Handspring Blazer Browser on my PDA phone. I have this problem on this site and Jeffrey Zeldman’s site. I noticed this technique is mentioned in Jeffrey’s book “designing with web standards” and it just doesn’t work with the Blazer browser.

  12. I’d be interested in an article covering MsnTV’s rendering and a Part 3 of this series would be an excellent way to do this.

  13. As Tanny notes, the target for a skip link should aways be a named anchor, lest it will be broken in many browsers. From what I can tell, the reworked Slashdot uses a div id as a target (note that there is also a class with the same name). Our friends at the W3C have the following to say:

    Use id or name? Authors should consider the following issues when deciding whether to use id or name for an anchor name:

    * The id attribute can act as more than just an anchor name (e.g., style sheet selector, processing identifier, etc.).
    * Some older user agents don’t support anchors created with the id attribute.
    * The name attribute allows richer anchor names (with entities).

    On the topic of the ordering of navigation and content, in as high a regard as I hold Mark Pilgrim, I have to respectfully disagree with the notion that content should appear before navigation. http://diveintoaccessibility.org/day_10_presenting_your_main_content_first.html

    A well-constructed navigational system not only tells you where you can go, but also where you are. As such, it contextualises the context, something which can sometimes be at least as relevant as the content itself, and it would appear that being aware of such a context when reading a document is preferrable to realising it ex post facto.

    Of course, navigational information should always be preceded by a skip link, and should be described as such, both in markup and in natural language. It is important that navigational information stands out as such even outside the context of overall layout and without colour information and similar.

    With that in mind, “YRO Articles” (of course with YRO marked up with an abbr tag) might be a better heading for the right-hand-side list of YRO links, for example.

  14. Having an anchor that targets an id will break in old browsers, such as NS 4 and probably early versions of IE as well (guessing), this is true, but it is supported in most browsers since that. Even Lynx supports it. Handheld browsers are still largely up in the air I would imagine.

    The DTD for the Slashdot redesign is XHTML 1.0 Strict, so a name could have been used, but the skiplink anchor was created in the XHTML 1.1 style, where name was depricated. If you’ll notice, just by switching the DOCTYPE, and fixing the lang=’en’ to xml:lang=”en” (not sure why it wasn’t like that in the first place), it would validate XHTML 1.1. So, the anchor targets the div with an id of ‘content’, and the class content doesn’t affect it at all, though it probably should be renamed for clarity’s sake.

    So which should be used, the XHTML 1.1 way or the normal way? Good question. It seems to be the movement for many blogs to go with XHTML 1.1, and I would imagine this will be an increasing trend.

    We also did a little testing with a WebTV emulator today, and from our tests, WebTV didn’t pick up the TV media, but actually caught the handheld media, which seems odd. I’m also a little frustrated at the projector media type. Browsers don’t have any way of telling if it is displaying on a projector or not, so a normal stylesheet with a media of projector doesn’t make much sense. An alternate stylesheet with media of projector is the way to go for now.

    Oh, and I totally agree with the YRO Articles comment.

  15. flaimo:

    > including it with
    > @import url(handheld.css);
    > and putting the @media handheld {…} inside the css file doesn’t work.

    That’s by design. Opera in handheld mode avoids downloading files it doesn’t want (data transfer on a mobile phone is usually quite expensive). If it isn’t linked explicitly as a handheld stylesheet, it will be ignored.

  17. Daniel says:

    …the department name is, “the don’t-worry-they’ll-print-more-money dept.” That’s a 36-character word that is too big for the display! So that is actually a problem with the content,…

    But this is false. That 36-character “word” is 6 words, separated by hyphens, which are allowed to be used for line breaks. This is clearly the browser’s fault, and is just the tip of the iceberg in the problem.

    Some cell phones insert hyphens and break lines in arbitrary places, rather than at established positions in the english language. Very bad.

    And some PDA/cellphone emulators are not emulators in the true sense of the word, but instead use the rendering enginge from desktop browsers to format the screens. This method of creating an emulator renders the resulting tool mostly useless, because it can not demonstrate what the real-world device will do to your content.

  18. I found the article really interesting. But, one thing not covered was that slashdot is driven using the php-nuke portal code. To convert the generated HTML from what nuke currently generates to the xHTML suggested, is a pretty daunting task.

    I’d be interested to hear, more in depth if anyone has ever attempted this.. and how long it took, resources required etc.

  19. I’m in love with the CSS 2.1 and the media part. But I’ve noticed a problem. The newer browsers on PocketPC2003, Smartphone2003 and Palm5.1 accept CSS levels 1 and 2. So even if you use the @import or link types it will show on the newer palms, pocketpcs and smartphones. This is a pain in the ass because the last thing you want to do is download a large background image intended for a css driven site. Anyone else come across this?

  20. I’m in love with the CSS 2.1 and the media part. But I’ve noticed a problem. The newer browsers on PocketPC2003, Smartphone2003 and Palm5.1 accept CSS levels 1 and 2. So even if you use the @import or link types it will show on the newer palms, pocketpcs and smartphones. This is a pain in the ass because the last thing you want to do is download a large background image intended for a css driven site. Anyone else come across this?

  21. I’m in love with the CSS 2.1 and the media part. But I’ve noticed a problem. The newer browsers on PocketPC2003, Smartphone2003 and Palm5.1 accept CSS levels 1 and 2. So even if you use the @import or link types it will show on the newer palms, pocketpcs and smartphones. This is a pain in the ass because the last thing you want to do is download a large background image intended for a css driven site. Anyone else come across this?

  22. The article fails to note that Slashdot uses mod_gzip, so most of the data transmitted from the servers is compressed.

    So bandwidth savings aren’t nearly as large as the article implies.

    Just FYI.

  23. Robert:

    Mod_gzipped or not, if Slashdot cuts its page weight by retooling with web standards, then the gzipped weight of the page will be smaller.

    Factor in millions of users hitting Slashdot every day and the bandwidth savings are considerable.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

I am a creative.

by
A List Apart founder and web design OG Zeldman ponders the moments of inspiration, the hours of plodding, and the ultimate mystery at the heart of a creative career.
Career