Daniel Glazman:
>
> 0. the lack of DTD is a very big problem. The HTML WG should not release
>    other XHTML WD without DTD.

AFAIK it's not even sure that there'll be a normative DTD. /Some/ machine
readable format soon would be nice, though.

> 1. the head element should not exist any more. It's a useless container
>    for metadata.
> 2. the body element should not exist any more. It's a useless container
>    for data since we already have the root of the document.

I'm not sure, they're useless. After all "head {display: none}" is
convenient and the removal would probably allow 'meta', 'link' etc. appear
anywhere in the document, making it probably harder to parse.

> 4. the link element and the src attribute on the style element are
>    conflicting

I wouldn't call it conflicting, redundant maybe.

> 5. metadata meta elements are only allowed at document's level but
>    can't be scoped on a per-element basis

Yes, I also wondered if it was desirable to them elsewhere. I came to the
conclusion, that not.

> 6. stylesheets can't be scoped on a per-element basis

It's good this way, IMHO.

> 8. I do not understand how the DTD will reflect the modularization

As far as I understand it, that's the major reason for some people to want
to drop DTDs completely.

> 10. the title attribute has a special meaning for the link element

It also has for 'abbr', something I dislike.

> 11. the notion of linguistic root of a word added as a note here
>     seems to me completely crazy.

For HTML, yes.

> 20. I find the nl element useless.

You're probably the first one.

> 21. the duplication of the title element is a closed issue if the head
>     and body elements are removed (see items 1 and 2 above)

I've always thought it should be an attribute of the root element, though.

> 22. I am still completely opposed to the l element.
>     The manipulation of this element in wysiwyg editors will
>     be too hard in comparison with the existing <br> in HTML4.

OTOH the manipulation via DOM and CSS is much easier. What's more important?

> 26. removing the hr element is counter-productive;

'hr' is for block level, what is 'br' for inline level. Either keep both or
drop both.
What if "<section/>" and "<l/>" provided the same default optical results as
"<hr>" and "<br>", as originally intended, respectively? Maybe a CSS
pseudo-class like :empty would be needed, though.

> 23. don't introduce the nr element, reuse MathML if that's
>     really needed.

MathML would be as much overkill as CML for 'sup' and 'sub', or a
hypothetical BibML for 'cite'.

> 25. the cite element is not needed, it is redundant with an anchor
>     having something like rel=cite (for instance).

It's not perfect as it is, but if you think <cite> equals <a rel="cite">,
then you probably also want <list type="ordered|unordered|definition">. I
miss the possibility to mark up names like the author's in addition to the
title of his work, or names in general.

> 27. the modification of the model of the paragraph p element will
>     drastically impact editing environements.

I definitely hope so.

> 29. if an element carries both the href attribute and the cite
>     attribute, how can the link to the cite URI be activated?

That's not something the specification should specify.

> 30. an h element child of the body is redundant with a title element
>     child of body as in item 21.

Likewise 'label' for 'nl' (and probably the other list types also) could be
replaced by 'h'. See your 34th point.

> 32. the a element is useless since any element can carry an href
>     attribute.

Yes, drop 'span' in favor of 'a' and maybe make the id attribute mandatory.
Then it'd be an anchor again.

> 35. the lack of the value and start attributes on ol and li elements
>     are a major mistake extensively discussed in www-style@w....

Not quite: a mechanism to connect or continue lists and/or to specify
explicit "counter" values is missed by many people. 'value' and 'start' are
just one possibility.

> 37. just for the record, the lack of style attribute is a major error,

JFTR: No. IMNSHO.

> 38. the style and link elements still lack a disabled attribute.

I don't think that's useful at mark-up level. One would just delete or
comment out unwanted elements.

> 39. the removal of the "_blank" value for the target attribute
>     seems to me an error.

To keep the target attribute seems to me an error, as I said before.

> 40. why isn't XFrames merged with XHTML 2.0 ?

Because it's a concept independent of XHTML. Also not a good concept IMHO,
but less worse than HTML frames.

> 41. I still think that the removal of B, I and U is a major error
>     for the Web.

A discomfort for some authors maybe, but not for the Web, IMHO.

Christoph Päper