Re: Comments about the 2002-08-05 XHTML 2.0 WD

Henri Sivonen wrote:
 > The Draft specifies a new namespace. I think it would be nice to have
 > some rationale for this design decision in the spec.

I'm not sure it *is* a design decision; it is not infrequent for W3C
working drafts to have "temporary" namespaces that do not reflect the
namespace that will be used for the final Recommendation. For example,
XSLT working drafts had a working draft namespace, which was changed to
the final namespace when the document moved into the latter stages of
its development cycle.

As this working draft doesn't specify whether this is or is not the
final namespace, it is difficult to comment on this until it either does
so or a member of the working group steps forward to clarify the matter.

I personally would rather see XHTML2.0 use the same namespace as
XHTML1.0 and XHTML1.1.

 > The Draft doesn't say which media type should be used for labeling
 > the document instances when the transport used media type labeling.
 > I think making the media type labeling clear early on is crucial for
 > interoperability of implementations. It would also be good to include
 > an explicit "must not" against sending XHTML 2.0 as text/html.

I agree. The XHTML media type issue was a complete fiasco, which is
still having repercussions. It would be a good idea to avoid any such
issues by specifying the media type to be used.

 > The definition of entity reference implies that the DTD will declare
 > character entities in addition to the predefined ones. I think doing
 > so is unnecessary since XML allow the use of any Unicode character
 > directly as UTF-8.

Agreed. I've already stated that I wouldn't shed any tears if the named
character entities vanished; others have done the same. Even Masayasa
Ishikawa (key member of the working group) cautiously agrees, saying
"Personally I'd like to remove mandatory support for the fixed set of
character entities in XHTML 2."[1]

 > The Draft says 'Apple systems, one generally has to press the "cmd"
 > key in addition to the access key.' The command key is the
 > accelerator key for the keyboard shortcuts of the browser's own
 > functions on Mac, so another modifier key (eg. ctrl) would have to be
 > used in order to avoid conflicts.

I agree that conflicts can arise, but don't think it is an issue - which
key is used as the modifier is not a matter for the specification to
decide, but for the browser. There's no reason why it can't be exposed
as a configurable preference, either.

 > Since XHTML 2.0 defines a new namespace, there are no pre-existing
 > elements in the namespace. The deprecated elements are effectively
 > *created as deprecated*. I think creating elements as deprecated
 > doesn't make sense, since that would mean creating a burdensome
 > legacy where none would otherwise exist.

Agreed. Even if XHTML2.0 does end up using the XHTML1.0 namespace, I see
no reason to deprecate elements. After all, this is a major-revision
release that specifically states that backwards-compatibility is not an
priority; if this were XHTML1.2, then I could see the point in
deprecating elements. As it is, deprecating elements like this seems to
have the opposite effect of artificially extending their lifespan.

Again, many people have put forward this opinion. The official
explanation for deprecating these elements seems to be that it gives
browser manufacturers and document authors advance notice that the
elements are to be removed; personally, I think this is nonsense, since
surely removing them from the specification at the earliest opportunity
is perfectly adequate notice (after all, I would expect that XHTML2.0
will not become a final Recommendation for a minimum of another six
months, probably more like a year - isn't that notice enough?).

 > I like the <section> and <h> arrangement a lot. However, I think
 > including <h1> through <h6> unnecessarily complicates things. I'd
 > like to suggest including only one way of marking up headings (the
 > <h> and <section> way) instead of including two incompatible ways.

Half agree, half disagree. My view is that the *functionality* of <h1>
through <h6> is still useful, despite the new h/section mechanism, yet I
would prefer to see a "level" attribute on the h element. However,
Working Group members seemed opposed to such a change when I first
suggested it [2].

 > Like many others, I was surprised to find that the Draft uses a
 > linking method of its own instead of simple XLink. Isn't simple
 > XLinks supposed to be used in new specs exactly in the cases like
 > <a href="...">?

Again, this has been much discussed, and appears to be something of a
political minefield. My views have already been expressed several times
- I would like to see XLink used wherever possible in XHTML2.0. I don't
intend to expand upon my previous statements until the working group
make a definitive statement explaining their decision to ignore XLink.
If such a statement exists, I've never found it - I've seen vague
references to "architectural flaws", but little explanation of what
those flaws are nor how they undermine the desired functionality of
XHTML2.0.

 > "This element is unusual for XHTML in that they may serve as either
 > block-level or inline elements (but not both)." I think the dual
 > nature of ins and del is quite undesirable. The rule "The del element
 > must not contain block-level content when it is behaving as an inline
 > element." can't be enforced in validation. Also, if an element has a
 > dual inline/block nature, it is more difficult to handle the
 > presentation of the element in a user agent style sheet. I think it
 > would be more straight forward to have separate elements for block
 > and inline deletions and insertions (just like div and span are
 > separate).

As someone who wants quote and blockquote combined into a single
element, and has even (unsuccessfully) tried to argue the case for
combining div and span into a single element, I think we'll have to 
agree to disagree here :)

 > The definition of <link/> includes the old HTML 4 style sheet
 > linking. Since there is a general processing instruction for
 > associating style sheets with XML documents, I think requiring user
 > agents to support <link/> style sheets is unnecessary.

No thanks. I don't want to be forced to use the processing instruction
for XHTML. There are historical reasons for it's existence - basically,
a mechanism for attaching stylesheets to generic XML was required,
within a very short timeframe, and processing instructions were seen as
a "quick fix" for this problem [3]. They're not something I'd like to
see become more widespread.

 > I'd like to suggest disallowing the use of document.write() with
 > XHTML 2.0 and with XML-based languages in general.

Not an XHTML issue; I suggest taking it up with the DOM working group.
To my knowledge, though, document.write() is only standardised in the
HTML module of the DOM, and thus doesn't apply to generic XML anyway
(unless individual XML DOM implementors choose to add it).

 > This would simplify the implementation of user agents in other ways as
 > well: When there is no document.write() there is no need to allow script
 > elements to occur as descendants of the body element and there is no
 > need to begin the execution of scripts before the entire document has
 > been parsed and the corresponding DOM tree fully created.

There are still uses for having script elements inside the body, with
or without document.write(). For example, some server-side technologies
allow document fragments to be included dynamically on the server-side;
it is useful to be able to bring in the entire fragment in one piece,
rather than having to remember both to bring in a script and bring in
the document fragment. For example, if I have a heavily-scripted menu
system that occurs on multiple pages, I may store this as a separate
server-side component that I reference on those pages. For example, in
ASP.NET:

   <body>
     <myCustomControls:Menu runat="server" />
   </body>

At server-side runtime, the Menu element is replaced with the contents
of the Menu control - which can include scripts. Being able to include
both the structure and the script at the same time is highly convenient,
and indeed there are even those who would argue that the style element
should be usable in such a way (although I'm not one of them).

 > Many Web pages include some kind of footer after the main content.
 > The footer tends to contain the address of the author, a copyright
 > notice, the date of update, a couple of works about the author and
 > things like that. In HTML, one could write:
 > <hr>
 > <div class="footer">
 >  <p>There author will be on vacation next week, so there won't be a
 >     new column next week. Last updated: 2002-08-17.</p>
 > </div>
 >
 > The use of footers is so common that I think footers would deserve an
 > element of their own:
 > <!-- no hr needed -->
 > <footer>
 > <p>There author will be on vacation next week, so there won't be a
 > new column next week. Last updated: 2002-08-17.</p>
 > </footer>

I can accept that many webpages contain footers; what I am uncertain
about is what use could be made for a footer element if one were added.

Think about it - if you had such an element, what would you do with it?
What benefit would be gained? Granted, you could style it in some way;
but you can do that with <div class="footer">. I don't see any other
tangible benefit. Some element suggestions I can sympathise with since
they provide tangible benefits, such as <summary> - user agents would be
able to take a number of documents and extract their summaries, search
engines could take the summaries into account when indexing documents,
etc. I'm afraid I don't see any such use cases for a footer element.

 > Another thing that I've noticed is that (X)HTML doesn't provide any
 > semantic markup for indicating which part of the page are main
 > content and which parts are navigation.

In the past, maybe; now there is the nl element [4] (navigation list, or
"menu" in other words). If this is insufficient for your needs in
some way, I suggest you let the working group know.


- Chris Mannall


[1] http://lists.w3.org/Archives/Public/www-html/2002Aug/0136.html
[2] http://lists.w3.org/Archives/Public/www-html/2002Aug/0023.html
[3] http://lists.w3.org/Archives/Public/www-html/2002Aug/0114.html
[4] http://www.w3.org/TR/2002/WD-xhtml2-20020805/mod-list.html#sec_10.2.

Received on Wednesday, 21 August 2002 06:01:11 UTC