“H1/H2/etc. header tags look absolutely wretched on the tiny screen of a Palm Pilot [....] semantic markup such as code, kbd, samp, and var [....] are simply unsupported”
Well, headers look fine, and some of these semantic tags are supported, with the tools that I use to read web content on my Palm (sitescooper, iSilo, my own code…). I can’t tell what you mean here: do you mean that these things are unsupported by the current state of tools with which you happen to be familiar? Why does this concern you? How do you know what people are using to process html before putting it on their handheld devices, and which readers they’re using to browse it there? Why not just use reasonable semantic markup and not worry about what crazy things people do with it?
Yes, as I said, there is a wide range of mobile devices and services. I based my statements off the AvantGo developer documentation which I linked, plus my own testing with Opera 7, plus my own testing with Plucker reader and the Palm Pilot. Specifically these tools, because several of my readers mentioned that they were using these tools to read my site (and my access logs confirm this).
If we’re going to get all apathetic and snooty, why even bother with semantic markup at all? The latest and greatest (the P800, running Opera “Small Screen” edition) makes short work of even the crappiest mobile-unfriendly markup. Million-dollar code instead of million-dollar markup, as it were. Long-term, this is the only workable solution. Any specific “mobile edition” (even using the phantasmagorical XHTML Basic) is just a short-term solution until enough people have upgraded to smarter clients.
— Mark 
“And semantic markup such as code, kbd, samp, and var (which have all been around since the very first proposal drafts of HTML, from 1993) are simply unsupported.”
Aren’t UserAgents allowed to make presentational decisions like whether or not to use a monospaced font as the visual representation of a piece of semantic mark-up? I don’t see how not displaying those tags in the traditional way means anything. It would be no different than if a browser’s default presentation of hypertext was to use a dotted underline rather than a solid underline or green text instead of blue.
Just my two cents.
— MikeyC
Well, for desktop browsers, I reinforce the default presentation of semantic tags like code with stylesheets (see http://diveintomark.org/css/mu.css where I set code to font-family: monospace, even though this is the default in all major browsers). But given that stylesheets are completely unsupported by my target devices, the default presentation of my markup actually matters. If a code tag by itself doesn’t output a monospaced font, I need to transform it into something that does. It’s not like the mobile browser is giving any other indication that such-and-such is computer code; it just ignores the tag altogether.
Frankly, I’m not sure which is worse — these low-end browsers that only understand bastardized markup, or the mid-range browsers (cough Hip Top cough) that think they understand CSS but get it all wrong. (To their credit, they got significantly better after their first disastrous release.)
I’m sure there are a wide variety of other mobile browsers that all have their own special problems that I don’t even know about yet. Word from the WaSP mailing list is that the entire field is a complete mess. This is only a small taste of it.
— Mark
“Frankly, I’m not sure which is worse — these low-end browsers that only understand bastardized markup, or the mid-range browsers that think they understand CSS but get it all wrong.”
CSS-hiding tricks are such an ugly annoyance, that I would rather a browser completely ignore CSS than do it incorrectly. Its absolutely no contest in my book.
— Anonymous
Mark, just curious, is the site redesign complete, or have you just taken a long break? When you first announced the public redesign, there seemed to be constant activity on a minute to minute basis… and then nothing. The only change in the last little while has been that you dropped the circle symbol from the background.
— Anonymous
Here’s an improvement of the abbr and acronym macros, which will, given a title attribute, and Mr Choate’s plugin MTRegex (at http://www.bradchoate.com/past/mtregex.php ofcourse), put in in paranthesis following the acronym/abbr.
() ()
I also agree with the previous anonymous poster… The design with the colored masthead and the centered button was better than this I think, even if the current one is not bad either.
— Jesper
Surely by creating a specific, less semantic edition, your are moving in a contrary direction? Is it not the goal of the Web Standards Project (and also the W3C) to try to get authors to write semantic markup that is separated from the way it is displayed? It seems to me that by creating a bespoke version of your blog, you are slowing down the forward progress of these device manufacturers and encouraging them to continue to create tools that use proprietary methods.
WaSP was very good at lobbying browser manufacturers to support web standards. Perhaps it is necessary for it to retain that element of itself, but direct the energy towards handheld/mobile device manufacturers. Maybe in the future, special mobile editions will no longer be necessary.
Just so that you know where I’m coming from, I’m the kind of guy who uses abbr and acronym correctly, despite the lack of support in the world’s most popular browser. However, I give in to necessity when I deliver my XHTML as text/html so Hixie probably thinks I’m the scourge of the Earth.
It gets worse when you factor in devices like the Danger Hiptop, which not only ignores handheld media types in stylesheets, but also interprets some styles literally, like padding and margin. So, while 150px of padding may look fine on a CSS-driven site, it will cause the content to be written into a thin column on a Hiptop.
I’ve written about this more, here: http://www.radicalbender.com/blog/archives/000077.php if anyone’s interested.
— Ben Dyer
Well, I can’t force Hiptop users into my mobile edition, but I can keep it from screwing up my CSS.
RewriteCond %{HTTP_USER_AGENT} hiptop
RewriteRule css/ – [F,L]
That is, until I can find an emulator or a Hiptop user to test my design. I have the infrastructure in place to serve it a different secondary stylesheet to undo the havoc it no doubt wrecks with the primary one.
http://diveintomark.org/archives/2003/01/16/the_one_ive_never_tried.html
— Mark
Whoops. Seems my awardwinning markup got stripped. Here it is again then, correctly escaped.
<MTMacroDefine name=”abbr” ctag=”abbr”><MTMacroContent><MTIfMatches expr=”[MTMacroAttr name='title']“> (<MTMacroAttr name=”title”>)</MTIfMatches></MTMacroDefine><MTMacroDefine name=”acronym” ctag=”acronym”><MTMacroContent><MTIfMatches expr=”[MTMacroAttr name='title']“> (<MTMacroAttr name=”title”>)</MTIfMatches></MTMacroDefine>
— Jesper
i use the avantgo client on my clie. when i first got it, i looked into creating my own channel for avantgo but more or less stopped when i read that the client supports a limited set of HTML 3.2. seems like they could have supported something a little more recent or at least have changed the client to account for the new versions of HTML.
http://www.avantgo.com/doc/developer/styleguide/styleguide.html
i think it’s great that WaSP is looking at mobile devices. as the months go by, newer and more powerful devices come out. manufacturers should know that standards are important for these devices, too.
and, thanks for the mobile edition, mark. it’s fun to read on my bus ride to work.
— travis
Just to be clear, when I write on this site, I don’t speak for the WaSP. I have posting rights on webstandards.org; if I want to say something official, I’ll say it over there.
That said, I hope the WaSP does move in this direction. From everything I read and hear, it’s a complete rat’s nest. Various vendors pushing their own bastardized markup, others who claim to support standards but do it so poorly you wish they wouldn’t even try, etc. It’s 1997 all over again.
— Mark
"It’s 1997 all over again."
Not quite. The WaSP didn’t even exist in 1997, and has a lot of credibility now. Although many handhelds have pre-installed browsers now, the upgrade cycle for handheld hardware/os is shorter than for desktop computers, and as far as user-installed software is concerned, the upgrade cycle more closely resembles browsers in 1995-96, rather than 1997.
I remember vividly how much the whole industry shifted after the 4.0 browsers came out (although it didn’t happen all at once). An equivalent milestone in handheld browsing has not yet been reached, and WaSP can still have a huge impact before updrag starts becoming a problem.
I think I have come to the conclusion that the only practical method of dealing with such a wide variety of devices that either obey or ignore media types as well as browsers that do such a horrible job with CSS (like Netscape 4) is to only provide alternate stylesheets. That is to say, all stylesheets would be off by default, and the user could enable them if they felt the need to (and, of course, if they have a browser which allows them to). I would not provide a JavaScript styleswitcher as they also break in some browsers, and really don’t work at all in handhelds.
Considering that CSS is only meant to provide “style hints” to the UserAgent, I think this is probably the best approach, the feelings of control-freak designers notwithstanding.
So what I am advocating is this: clean, semantic mark-up with absolutely no styling by default. If you want to write a stylesheet it would best be provided as an alternate stylesheet. This way, its not really viewed as an integral part of the site or “site experience” and if the user wants to use it, that’s fine, if not (or if it breaks in their UA), that’s also fine.
I think this has been referred to in the past as being an “HTML Nazi” as opposed to being a “Pixel-Weenie”. Frankly, the days of being a “Pixel-Weenie” can’t last forever, handheld devices and the introduction of Safari have shown us that.
— MikeyC
Mobile XHTML (Basic) support is actually becoming available. The new handsets from Nokia, SonyEricsson and Siemens all suppport XHTML Basic and CSS Mobile Profile. All of them have color screens with resolutions of up to 320×480.
Sites such as zeldman.com look fine on a Nokia 3650/7650 or the SonyEricsson P800. These handsets are becoming mainstream now because of the cheap MMS and GPRS services.
I don’t think it’s a good idea to quit writing correct markup because some device has a bad implementation. You’ll break the good ones.
— Anonymous
I’ve seen “dive into mark” (normal edition) on a P800, the day before Opera “Small Screen” edition came out. It was readable — just like reading it in Netscape 4 actually (good structure, no stylesheets). So score one for web standards — it was all readable and not utterly impossible to navigate.
But the P800 is an ultra-high-end mobile device with a live Internet connection and what must be called a medium-sized screen. That’s a far cry from the design center for this “mobile edition”, which is more geared towards lower-end clients and services with smaller screens and different usage patterns. Also, now that Opera “Small Screen” edition is out, P800 users can surf pretty much anything — I have been told that Opera is *that good* at transforming unfriendly markup and desktop-oriented pages. (Somebody correct me if I’m wrong here.) So there’s no real need for special “mobile” markup at all, XHTML Basic or anything else.
That just leaves the rest of the world, I suppose.
— Mark
It should be noted that the “mobile edition” is not really meant to be a replacement for the rest of the site. It’s really a replacement for my RSS feed, since (I’m told) there are no good RSS readers for mobile phones. (Someone correct me if I’m wrong here.) Perhaps a better long-term solution would be to write (or find) an RSS reader for the various mobile platforms, or integrate RSS support into Plucker/SiteScooper/etc.
— Mark
http://insom.me.uk/Gfx/xmosaic.jpg
The above is how your site looks in a copy of XMosaic 1.2 I just resurrected. I had to cheat by wget-ing, because that version of XMosaic certainly didn’t send a ‘Host’ header, and confused your webhost somewhat.
All in all, apart from an import at the top, and an nbsp at the bottom, your site looks flawless in the earliest browser I could find.
If wireless browsers aren’t up to where NCSA was in 1993, then really why bother?
Aaron
Mark, it seems to me that you’re upset that your (excellent) XHTML is not being properly rendered on browsers which do not support it. Thus you are forced to reformat your code into a less syntatically pleasing file for them.
But I think you’re upset about the wrong thing. The lack of support for proper XHTML, or even XHTML Basic is to be lameted but is not worthy of fretting over too much. If you had your files stored at XML (although XHTML is nearly as sufficient for this purpose) you could build your own translator mechanism or make use of XSL(T) to transform the document as necessary for the end user. Thus your unsupported tags could be rendered appropriately without relying on macros and non-standard items, and you gain futher flexibility by having a maleable source.
Just a thought.
— Lou Brothers
It’s quite possible he’s already doing this, Lou.
The lament is that the write-once, run-anywhere that failed for Java, is also failing for the web.
Deciding where to go from here is the tough part. How do we get things better? Good enough, even?
— Jeremy Dunck
Two things:
1. I’m using HTML, not XHTML
2. Have you looked at the actual syntax of the macros I’m using? Here is the macro to map CODE to TT:
<MTMacroDefine name=”code” ctag=”code”>
<tt><MTMacroContent></tt>
</MTMacroDefine>
Please explain how this is worse than XSLT:
<xsl:template match=”code”>
<tt><xsl:apply-templates/></tt>
</xsl:template>
Anyone who thinks that HTML isn’t a malleable source isn’t using the right tools.
— Mark
While there is room for improvement, I thought PeekAndPick (a mobile RSS application) was quite novel and illustrates the potential use of RSS in mobile. More here: http://www.mplode.com/tima/archives/000125.html
I just wanted to say thanks for this article and the MT templates for a mobile version :) also the dive into acessability site rocks dOOd!
No chance of
— Anonymous
No chance of ? Yeah, I know nobody supports it, probably, but would it not just complete the whole thing. (I hope this comes out.)
— mr snippers
okay, that didn’t work: what I think you should do is have LINK tag with media=”handheld”, title=”Mobile edition”, type=”text/html” and rel=”alternate”. You stripped it from the last post.
— snippers
Re: RSS parsers for Palm
I agree absolutely that the better solution is to have an RSS parser for the Palm platform. This mildly “smarter client” makes it much easier on everyone on the web who is serving RSS to provide “mobile editions” without serving seperate content.
It will also allow us users to have a much easier time getting the information we need to our memory-crunched, small-screen devices. For example, C|Net offers free RSS feeds of their content but will charge you $2.95 a month for their “mobile edition.” An RSS reader for the Palm will allow me to circumvent dumb business models like this.
After the last conversation about this, I submitted a bug to the Plucker group to create an RSS reader (Login Anonymously at http://bugs.plkr.org/ and view bug #507) and they seem to be doing some real work on it. There’s also a rumor afoot (see comments at http://www.readyourpalm.com/mt/archives/000025.html#000025) that you can use JPluck to apply XSLT to the RSS feeds and generate Plucker documents. Not the ideal solution, but it looks like we’re getting somewhere…
— Ken