Retooling Slashdot with Web Standards Part II
by Daniel M. Frommelt
- Published in: Browsers, CSS, HTML and XHTML, Accessibility |
{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.
Printer-Friendly Slashdot
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
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:
- Openwave Phone Simulator
- Palm OS Emulator (Note: You will need to register as a developer to download the Palm OS Emulator and web browser.)
Let’s take a look at what Slashdot’s website used to look on the Openwave Phone Simulator (figure 1).
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).
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).
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).
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).
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.
Learn More
Related Topics: Browsers, CSS, HTML and XHTML, Accessibility
Discuss
Was it good for you, too? Join the discussion »

Daniel M. Frommelt is the University World Wide Web Coordinator at the 
