The already infamous rant from Mark Pilgrim highlights a larger issue: when designing a markup language like XHTML 2.0, how does one decide what to include and what to leave out?
Listening to those who ultimately will use the technology is, of course, critical. The trouble is, that different users have different (and quite often contradictory) requests.
More is needed than just “listening”. There has to be a guiding princicple. The word ’semantics’ is often used in this context, but it has unfortunately become overused and hard to define. A better way to describe the principle is:
A markup language should describe the author’s intent.
This principle immediately clarifies countless cloudy issues. Daniel Glazman blogs about how he laments the <br> element, with this example:
<p>Combien sont ces six saucissions-ci ? Ces six saucissons-ci sont six sous.<br/>Si ces six saucissons-ci sont six sous c’est six sous trop cher!</p>
To analyze this, one needs to ask what the <br> element is
Another contentious area is around how to provide linking properties in a general way. Again, the answer is to let the author describe their intent in a general way, as I described in a skunkworks XML linking proposal.
A few more examples. Should there be a a <hr>-like element, perhaps called <separator>? Yes, because separating two different pieces of text is an intent, one that can be readily rendered on the screen, voice, or print. Similarly, proposals for an attribute named xml:id fit in with the idea of exprssing intent.
All in all, XHTML 2 is still growing and changing. The answer isn’t to push it aside, throw it away, nor even to rename it.
XHTML 2 hasn’t radically changed recently. The best way forward is to stay the course. XHTML 2 needs a better-defined goal (ideally a requirements document), and continuous, incremental movement towards the goal. -m
How do you express intent?
what does a voice browser do with...
What does a voice browser do with hr tags, frame tags, pre tags, or border attributes on img tags? Are these the questions that should guide the future of the web?
While voice browsers are useful for the impaired, they should not dictate the direction of HTML because the primary "intent" of web pages has always been for visual browsing. An author who inserts a br tag intends to put a break there. A voice browser could interpret that as a pause, ignore it, or what have you.
I support XHTML in principle and am sure I'll find a use for it someday, but it will not be truly valuable to the world at large until the majority of tools that produce web pages, and thence the majority of content on the web, support it. The sad truth is, that may be never. In the meantime, since it's still valid HTML you can take comfort in the fact that browsers will support it. It's only recently that a useful standard like CSS has enjoyed such a luxury.
what does a voice browser do with...
>What does a voice browser do with hr tags, frame tags, pre tags, or border attributes?
Those things put a voice browser in a sticky situation indeed. And in fact, all of those things (except pre) have been removed from XHTML 2.0.
The intent of using a pre element is that any whitespace content has special relevance. Even voice-only users still might need to know about that.
>voice browsers ... should not dictate the direction of HTML
Yes, looking *only* at voice browsers would be far to narrow. But it does provide a nice counterpoint for the typical visual-centric web developer.
-m