Re: My thoughts on XHTML 2

Kelvin Chung wrote:
> After reading the latest XHTML 2.0 WD, I can say that XHTML is certainly on
> the right foot.  Firstly, there seems to be a lot less elements, which is
> indicative of a simpler, more compact design (although this simpler, more
> compact design still needs a Basic counterpart).
> 
> I especially applaud the following:
>  - allowing any element to be a hyperlink or object container
>  - the replacement of <br> with <l>
>  - <section> and <h> are how <h1> to <h6> should have been...
> 
> However, I seem to have some concerns:
> 
> 1. Is there any point to having <sub> or <sup>?  I cannot find any real
> semantic value in these two elements.

Neatly sidestepping the issue of semantic value, I will limit myself to 
saying that I greatly prefer the first of the following two examples:

	H<sub>2</sub>SO<sub>4</sub>
	H<span class="sub">2</span>SO<span class="sub">4</span>

> 2. Would <l/> (ie. An <l> element with no content) be the same as <br/> in
> the long run?

No more so than would e.g. <p />, <div /> and so on. This isn't how the 
elements are meant to be used, so the results aren't described in the 
spec. Basically, it depends on how CSS styling (yours or the UA's 
default) applies to empty elements.

> 3. Is there any point in keeping <a> or <object> now that any element can
> act as such?  Perhaps an accessibility objective...?

Although I agree that <a> is now entirely redundant, <object> is another 
matter. In fact, I'm puzzled by your statement - exactly how can "any 
element" be used to embed Flash into a page, or even just an image?

> 4. <nl>, the accesskey attribute, and the navindex attribute seems to be a
> bit media-specific, as it seems that non-screen media do not benefit much,
> if anything, from this.  Perhaps someone can enlighten me on what is going
> on?

In the case of <nl>, I find it easy to see uses for non-screen media. 
The default visual rendering of <nl> is that only the top-level <li>'s 
should be visible until one is activated, and so on down the hierarchy - 
which maps perfectly onto aural media, for example, since only the 
top-level <li>'s need to be *read out* until one is activated by 
whatever mechanism the user agent provides. If in doubt, think about how 
automated phone systems work - when I call my bank, the robot on the 
other end reads me my basic options, such as "balance information", 
"transfer funds" and so on. I then press the number corresponding to 
that option, and get a new list of suboptions.

> 5. Will there be a skeleton XSL stylesheet that transforms between XHTML 1.x
> Strict and XHTML 2.0?

I'm not sure such a conversion would be complex enough to warrant it 
being part of the specification.

> 6. With <section> and <h>, is there any point in keeping <h1> to <h6>?

A more careful reading of the spec would have shown that this is already 
listed as an issue [1].

> 7. I'm not sure on this, but is multiple instances of <title> permitted so
> that you can have titles in different languages?

No need for this at all - your document is only in one language, so your 
title only needs to be in one language. If you have provided alternative 
versions of the document in different languages, then there is already a 
mechanism for linking to them - there's an example[2] of this in the 
spec already, a modified version of which appears below:

<html xml:lang="en">
   <head>
     <title>The documentation in English</title>
     <link title="La documentation en Fran&ccedil;ais"
           rel="alternate"
           xml:lang="fr"
           href="http://example.com/manual/french.html"/>
   </head>
   ...
</html>


> 8. Will either the linking module or the meta module be deprecated/replaced
> (in favor of RDF/XLink)?

With regards the meta module: I doubt it, since RDF is rather complex. 
The meta module represents a clean, simple way of attaching basic 
metadata without diving into the complex world of RDF.

With regards the linking module: You must be one of the few people to be 
unaware of The Great XLink Debacle. Note that the XHTML 2.0 draft does 
say, under "Status of this Document", that "[t]his version also does not 
address the issues revolving around the use of XLINK by XHTML".

Use of XLink within XHTML is something of a political minefield. The TAG 
were of the "unanimous opinion"[3] that XHTML should use XLink, whereas 
the XHTML working group were strongly against the use of XLink, 
apparently believing that the XLink spec was broken and unsuitable for 
use in XHTML. This led to the development of the HLink specification[4]. 
Exactly what the current state of play is I don't know, since the 
argument seems to be largely taking place behind closed doors right now.

> 9. Will there be an XFrame module?
>
> 10. I can see how advertisers can abuse the "universal link" by placing a
> href attribute in one of the main structural tags.  Is this of anyone's
> concern at W3C?

I don't see how <body href="http://foo.com">...</body> is any more open 
to abuse than <body><a href="http://foo.com">...</a></body> was in the past.

> I'd also like to make some suggestions, although they may have been debated
> to death:
> 
> 1. <hr> - although it possesses some semantic meaning, it's in the
> "presentation" module.  If <hr> is "purely presentational" as its position
> implies, wouldn't something like the skeleton example below suffice?
> 
> <l src="hr.gif">* * *</l>
> 
> Thus, <hr> either needs to be retooled so as to make its semantic meaning
> clear, or be removed completely.

This is an issue that has been debated quite extensively, but with 
no-one able to come up with the "killer argument" to conclusively 
save/condemn it. I'm mostly ambivalent, since I do use <hr/> 
occasionally and yet wouldn't consider it earth-shattering if it were 
removed.

> 2. Although this is somewhat controversial and perhaps out of personal
> preference, what about removing <script> and <style>?  From a "structural
> purist" perspective, style sheets and scripts should be kept separate from
> the XHTML document at all times.  (This argument might be invalidated if you
> consider putting XML from multiple namespaces together)

That just isn't practical. Imagine that I want to style one particular 
instance of an element within my document. I (probably) no longer have 
the use of the style attribute, since Ian seems to have roundly defeated 
us on this issue[5], so my only option is to give the element an ID and 
attach a CSS rule to it via that ID. This seems to me for more suited to 
an internal rather than external stylesheet, since the style rule 
applies to *this document only*. The alternatives are simply too 
horrible to contemplate - either I'd have to allocate IDs on a site-wide 
rather than document-wide basis (ensuring either that id="myID" occurs 
only once on the entire site, or only when I'm certain that I want both 
elements to be styled identically), or I should start maintaining 
separate external stylesheets for each document. Neither are pretty.

> 3. ismap="ismap" (as an example) seems to be a bit too much.  I think
> something similar like ismap="yes" or ismap="true" should be used instead.

I see where you're coming from (my personal bugbear here is <cite 
cite="">), but I wouldn't be at all surprised if you ran into arguments 
about backwards-compatibility.

> 4. Could a limited subset of SVG be used instead of the shape and coords
> attributes?
> 
> 5. And now for something a bit stupid: how about a "XSemantic" set of
> elements?  For example, if you want to markup a URI, you could mark it up in
> something like <xs:uri>.  This "extra" set could address large numbers of
> semantic element requests while keeping XHTML slim and not bloated...

People have suggested a set of extension elements before... the problem 
is that there are an awful lot of people with an awful lot of ideas for 
what elements should be part of these extensions. You're probably best 
off either writing your own set, or finding someone who happens to have 
written a set that covers your needs - but I can't see the W3C ever 
reaching consensus on what should be included when it's difficult enough 
just to get an XHTML spec out of the door.

> 6. The difference between <section> and <div> should be made more clear.  I
> have a hard time determining the difference, and I fear that people may not
> care about the difference, seeing that <div> elements currently do what
> <section> would do anyways.

I think you're in a minority here. Personally, the introduction of 
<section> is something that I am incredibly happy with - I've long lost 
count of the number of documents in which I've used <div class="section> 
extensively. If there's any redundancy here, I would say it's with 
regards <div> and <span>. But now I'm the one in the minority ;-)


- Chris Mannall.


[1]http://www.w3.org/TR/2002/WD-xhtml2-20021218/mod-text.html#s_textmodule_issue_4
[2]http://www.w3.org/TR/2002/WD-xhtml2-20021218/mod-link.html#s_linkmodule
[3]http://lists.w3.org/Archives/Public/www-tag/2002Sep/0183.html
[4]http://www.w3.org/TR/hlink/
[5]http://lists.w3.org/Archives/Public/www-html/2003Jan/0277.html

Received on Tuesday, 21 January 2003 05:33:02 UTC