The Intentional Web

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:

To analyze this, one needs to ask what the <br> element is inteded to accomplish. If the answer is 'I inded for a line break to appear there!', there's a good indication that you're addressing the wrong level. What would, for example, a voice browser expect to do with the <br>? At too specific a level, one ends up with presentation instead of intent.

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.

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?

2 Comments

mentata
2003-01-16 07:42:17

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.

mdubinko
2003-01-17 22:32:24

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

Sign up today to receive special discounts, product alerts, and news from O'Reilly.