Retooling Slashdot with Web Standards Part II

by Daniel M. Frommelt

23 Reader Comments

Back to the Article
  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.
    Copy & paste the code below to embed this comment.
  2. What I really want to know is where to get those Palm Emulators.
    Copy & paste the code below to embed this comment.
  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.)
    Copy & paste the code below to embed this comment.
  4. In the <link> tag, most of the attributes use double quotes, why does media=‘print’ use single?
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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
    Copy & paste the code below to embed this comment.
  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: <style type=“text/css”>
    <!—
    @import url(handheld.css) handheld;
    @import url(othermedia.css);
    —>
    </style> 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 */
    Copy & paste the code below to embed this comment.
  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 800x600 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.
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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….
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this 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.
    Copy & paste the code below to embed this comment.
  16. Every screenshot graphic is a jpeg with obvious artefacts.
    Why wasn’t png used?
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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?
    Copy & paste the code below to embed this comment.
  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?
    Copy & paste the code below to embed this comment.
  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?
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.
  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.
    Copy & paste the code below to embed this comment.