Comments on XHTML 2.0 Working Draft

XHTML 2.0 Working Draft Comments
================================

4 The XHTML 2.0 Document Type
-----------------------------
The listing for the Server-side Image Map Module says "Attribute ismap 
on img" - the img element doesn't exist any more, this should read 
"Attribute ismap on object". There are also other references to "img" 
under section 12 and section 19.

6.1 Core Attribute Collection
-----------------------------

The example given for the class attribute is invalid - judging from the 
surrounding text, the (unclosed) span element needs to removed and its 
class attribute moved to the enclosing p element.

8.6 The cite element
--------------------

At a purely aesthetic level, <cite cite=""></cite> gnaws at my 
sensibilities. Is there a better name for that attribute? "reference" 
maybe? Or even use the href attribute imported as part of the hypertext 
attribute group?

8.11 The heading elements
-------------------------

Is it necessary to have two forms of heading? Bearing in mind that the 
combination of h and section is recommended over the traditional hX 
elements, I don't see why both are required. Can the hX elements not be 
deprecated?

If it's really necessary to retain the functionality of the hX elements, 
could we not instead have something like this?:

	<h level="1">Equivalent of h1</h>
	<h level="2">Equivalent of h2</h>
	<h level="3">Equivalent of h3</h>
	etc.

8.9 The div element and 8.19 The span element
-------------------     ---------------------

Reading the descriptions of these elements, I have to wonder why both 
are necessary. Since the descriptions of both state that "this element 
imposes no presentational idioms on the content", the only difference 
between the two is that one is defined as "inline" content and one is 
defined as "flow" content. One could argue that this distinction is 
mostly presentational anyway... there's no reason why a single element 
could not be used for both purposes, for example:

	<div>
		<p>The enclosing div is a "block" element.</p>
		<p>Whereas <div>this one</div> is a flow element.</p>
	</div>

The intended difference in presentation here is easily handled using CSS 
mechanisms:

	div { display:block; }
	p > div { display:inline; }

8.13 The line element
---------------------

    "The line element represents a sub-paragraph."

I really dislike this description. The line element clearly represents a 
line! If there were such a notion as a "sub-paragraph" (which I must say 
I've never come across before), what is wrong with nested p elements?

Also, it may be worth noting that, without any stylesheet rules to the 
contrary, the example would be rendered with only a single character of 
whitespace at the start of the third line.

8.14 The p element
------------------

    "In comparison with earlier versions of HTML, where a paragraph
    could only contain inline text, XHTML2's paragraphs represent the
    conceptual idea of a paragraph, and so may contain lists,
    blockquotes, pre's and tables as well as inline text."

Could I ask what the working group's reasons are for this change? 
Although I have not yet sat down to come up with a concrete argument 
against, my gut
instinct is to strongly dislike this change. I can understand the idea 
of a paragraph containing a list (and in fact I used to do this in my 
pre-valid
markup days), but a table inside a paragraph? A blockquote inside a 
paragraph? Neither of these last two "feel" correct to me.

8.16 The quote element and 8.4 The blockquote element
----------------------     --------------------------

Based on the fact that blockquotes are now allowable inside a p element, 
is it really necessary to have two elements? It seems to me that once 
again the only difference between these two is that one is "inline", one 
is "flow"... which strikes me as a presentational difference that should 
be left to stylesheets:

	quote { display: block; }
	p quote { display: inline; }

9 XHTML Hypertext Module
------------------------

May I ask why XHTML 2.0 isn't using the generic mechanisms described in 
XLink? I find it strange that XLink - a W3C Recommendation with some 
implementations (albeit generally limited ones), is not being used or 
even mentioned, whereas XForms - which is still only a W3C Working Draft 
- is a requirement for an XHTML2.0 implementation.

9.1 The a element
-----------------

    "Authors may also create an a element that specifies no anchors,
    i.e., that doesn't specify href, or id."

Why are anchors without the href attribute required at all? There is no 
need for so-called "named anchors" anymore, since the id attribute of 
any element can be used for this purpose. The example given of having an 
a element with neither href or id attributes is particularly dubious - I 
can't think of any circumstances where one would want to wait until 
scripting runtime to assign these attributes.

18.1 The noscript element
-------------------------

Is this element necessary? Shouldn't the onus be on document authors and 
script authors to ensure that documents function appropriately whether 
scripts are executed or not? The functionality of noscript (only 
rendering certain content when scripts are unavailable) is easily 
duplicated by approaching the problem from the other direction:

    <div id="noscript">
       <p>Only displayed when the script below can't run.</p>
    </div>
    <script type="text/javascript">
       document.getElementById("noscript").style.display="none";
    </script>

18.2 The script element
-----------------------

Is there any chance that we can start the process of renaming "src" 
attributes to "href" attributes (or vice versa)? The distinction is both 
unnecessary and unclear - someone once made the argument to me that src 
is used when the resource is to be included directly included into the 
document, and href when the resource is something being pointed to as 
some form of relation, but examination of HTML and XHTML specs doesn't 
agree with this argument. If this were the case, then I suppose I could 
tolerate the difference between the two... without this semantic 
difference, I can see no reason whatsoever to have two different attributes.

It may also be worth highlighting the fact that scripts may need to be 
wrapped in <![CDATA[ and ]]> declarations if those scripts contain 
operators conflicting with certain aspects of XML (e.g. <, > operators). 
The same is true of inline stylesheets.

21.3.3 Sample table
-------------------

The graphic at the end of this section does not match the example code.

Conclusion
==========

Overall, although I have seen some welcome developments in this working 
draft, on the whole I must admit to being somewhat disappointed. 
Despitethe disclaimer that XHTML2.0 is not intended as being 
backwards-compatible with previous version of HTML and XHTML, the only 
thing that jumped out of me as causing this is the move to XForms.

Consider that (for about the past year to my recollection) the HTML 
Working Group's roadmap has contained the following note about the 
intended direction of XHTML 2.0:

    "The objective of these changes is to ensure that XHTML 2.0
    can be readily supported by XML browsers that have no arcane
    knowledge of XHTML semantics such as linking, image maps,
    forms, etc."

Unfortunately, the working draft I have just read doesn't even come 
close to reaching this objective. Granted, the move to XForms is a step 
forward in this regard, but "arcane knowledge" is still very much the 
order of the day since linking, images (via the object element) and 
image maps are still an intrinsic part of XHTML itself rather than being 
farmed-out to XLink.



Chris Mannall.

Received on Tuesday, 6 August 2002 10:14:43 UTC