In response to the various posts saying that handheld style sheets are not worth it:
If you code your HTML cleanly and with proper semantics, your page will display just fine in a handheld browser. It will know how to interpret the markup and can display the content in a way that reflects those semantics. This is why standards-compliant sites render better: they’re marked up properly.
Most pages out there are designed for desktops only and/or still use tag-soup coding methods. (Think table layouts with spacer gifs and text marked up with only <font> tags and
.) Opera has special modes like SSR (“Small Screen Rendering”) that use heuristics to make sense of the tag soup and display something reasonable. This involves collapsing columns, shrinking images, dropping images, overriding font sizes and colors, ignoring fixed widths and heights, and using other tricks to adapt screen-targetted web page designs for a handheld device. It’s a good educational tool: you can compare SSR’s version to your own work and see what makes a design easy to read on a handheld. However, although Opera’s SSR usually does a good job of making the page comfortable to read, it won’t preserve the original page design elements. As a designer, you can leave the job of doing the small-screen adaptation to the handheld browser, which is often sufficient to make it browsable—or you can take control yourself by writing a handheld style sheet.
Opera’s site has a some tips on coding for web designers who don’t want to spend the effort to design a handheld style sheet. (Much of that advice is just common sense for ALA’s readers.) Instead, we thought it would be more interesting for this audience to include tips on how to design a good handheld style sheet. If you want to put in the extra effort to make a handheld style sheet, this article explains how to do it right. If you don’t, you can skip the sections on CSS and take a few pointers on other things.
The CSS rule to linearize layout tables is a good one but,what about complex data tables? Using that rule would be disastrous for comprehension of the table.
The CSS rule in the article would indeed be inappropriate to use straight out of the text; it should be adapted to select only the table elements used in layout tables.
That post is inaccurate. The ‘name’ attribute can also be used on anchor elements that have no ‘href’ attribute and thus are not links. (The ‘A’ in the element name stands for “anchor”, not “hyperlink”.) This is how HTML defined target anchors before ‘id’ was introduced or well-supported,
and it is still common practice. ( See Tantek’s post “Anorexic Anchors” for notes on good practice: http://tantek.com/log/2002/11.html#L20021128t1352 )
Furthermore, the ‘name’ attribute is defined only on a handful of HTML elements, and only as a link target on <a>. <div name=“foo” id=“foo”> is no less invalid in HTML than in XHTML. The id+name trick Zeldman was probably trying to explain to is to place the two attributes on an <a> element, not a <div>. It’s somewhat redundant to do both, though, so I’d just stick with ‘name’ only.
Rather than process the text into HTML, just serve it as it is to handhelds.
The problem with that is you lose all the semantic information and interactive behavior coded in the HTML. Think of headings (especially on a voice browser), hyperlinks, form controls, etc. If it’s coded right, HTML is an excellent format for handhelds. You may want to drop any non-critical navigational and decorative content if you’re serving a separate handheld version, but don’t drop the markup.
I had brought a few screenshots with me, but I can’t find the disk atm… I’ll ask Jorunn to take a few more if it seems I’ve lost them them. Give it a shot with Opera 7 in Small Screen mode meanwhile. (It’s under the View menu.)