Re: more xhtml 2.0 comments

Daniel Glazman wrote to <mailto:www-html@w3.org> on 14 April 2003 in "more
xhtml 2.0 comments" (<mid:3E9A73B6.4040708@netscape.com>):

> the lack of DTD is a very big problem.

The production of a DTD seems to at least as big a problem, if I understand
Masayasu Ishikawa correctly.

> 1. the head element should not exist any more. It's a useless container for
> metadata.

Do you mean that the metadata is useless? Or is it just that grouping the
metadata in an element is useless?

I don't consider either the metadata or the container useless. A 'head'
element is a convenient vehicle for styling, like with the CSS

head { display: none; }

in both aural and visual renderings. If future versions of XHTML add
metadata element types, having elements of those types scattered throughout
the document will make distinguishing them difficult for XHTML 2 user
agents. A 'head' element is simple.

> 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. It's also conflicting
> with the root document from a rendering point of view

A 'body' element conflicts with its 'html' parent exactly as much as a 'div'
element conflicts with its 'body' parent. CSS, if not all style languages
for ordered hierarchies of content objects, has clear rules on how to handle
nested elements.

> 3. the xml-stylesheet PI and the link element are conflicting

I agree. I prefer the processing instruction. A processing instruction is
easily identified as dependent on environment or type of processing, whereas
an element seems to be inherent content. Style is not inherent, or at least
should not be inherent.

> 7. deprecating h1-h6 is a performance hit for web browsers.
[...]
> that's _considerably_ slower

Well, how much slower is it? Is it worth cluttering the language to cater to
today's software?

I'm expecting XHTML 2 to remain a language of common use for about five
years after it reaches Recommendation. I'm expecting XHTML legacy documents
to remain available, useful, and accessed for between ten and thirty years.
It might be more. Hopefully hardware and software will advance to a level
where plain 'h' elements in 'section' elements are not a noticeable problem.

So we have this tension between the present and the future. How do we strike
the right balance?

> 10. the title attribute has a special meaning for the link element and
> therefore cannot serve as an extra advisory information. Title and alternate
> style set should be independent.

I agree but I note that if we get rid of the 'link' element style sheet
mechanism, this is irrelevant.

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

I do not understand. Do you really find existence of etymological
relationships crazy? Or do you consider the specification of such
relationships in XHTML a bad idea?

> 18. the navindex attribute seems to me the worst choice of all for that
> feature. Having this defined by an integer is a design mistake in a
> structured XML-based world. This should be defined by ID and an IDREF:

I agree.

> 20. I find the nl element useless.

I find the 'nl' element type too restrictive but far from useless. I'd like
a navigation element type that does not impose a list structure.

A navigational element can work in various ways in various media. An aural
browser could offer to skip navigation. A graphical windowing browser could
display navigation content in a sidebar. A search engine could ignore
navigation elements or, on the contrary, give them high priority.

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

I agree, vigorously.

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

What you propose, if I understand, requires a URI for every citation, which
may not be possible. And a 'cite' element can reasonably contain author
names, publication dates, publisher names, and other information besides
names of works. The natural anchor for a link, however, would be just the
name of a work.

> 26. removing the hr element is counter-productive

I find the removal of the 'hr' element type a firm step in the right
direction. I see two possibilities. A given 'hr' element is either
presentational or intended to imply semantics. If the element is
presentational, its role is best covered by style sheets. If the element is
intended to imply semantics, the content before it should be grouped in a
containing element and the content after it should be grouped in a second
containing element; the 'hr' element itself then becomes unnecessary and
should disappear.

> 27. the modification of the model of the paragraph p element will drastically
> impact editing environements. Most editors rely on the inline/block
> discrimination to handle user input, in particular when the user presses the
> Enter key. I see this change as a nice structural change, unfortunately
> totally overkill for vendors. You can't say at the same time "XHTML 2.0 will
> be edited by tools and not by hand" and complexify that way the language so
> that editors will hardly handle it.

I appreciate your concern. We all seem to agree that the new 'p' content
model is good in terms of structure and semantics. So we should leave things
as they are through Candidate Recommendation phase. Let's please give the
vendors a chance to show what can be done, and what cannot.

> 28. in the spirit of XHTML 2.0, the pre element should not exist.

I agree. The 'pre' element type is presentational.

> The non-collapsable spaces should be &nbsp;

I disagree. A space should be a space (U+0020). That it is important to
preserve the space rather than following XML defaults and collapsing it does
not change the character. Authors and user agents should use the 'xml:space'
attribute to avoid the collapsing of spaces.

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

There are many ways; I will describe one. A graphical browser could allow
link activation by a click on the rendition of the element. If two or more
targets exist for that element, the user agent could render a menu with
entries like "General" and "Citation". On selection of a menu item, the user
agent follows the link to the chosen target.

> 31. sub and sup elements are purely presentational and do not carry any
> semantics

I agree strongly.

> 34. the label element should be called title and should be allowed in
> ul/ol/dl.

If you change the name and usage of an element type, is it still the same
type? It is not. You are proposing a new element type.

The name 'title' already has two meanings in XHTML. Please don't add
another. I think that an 'h' or 'caption' element type would be best for
list headings.

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

The re-introduction of 'value' and 'start' attrbibutes is a major mistake
discussed extensively here on www-html.

What's that? The discussion failed to lead to consensus? Oh, I see...

> 41. I still think that the removal of B, I and U is a major error for the Web.
> One may want to annotate visually a document without adding any semantic.

If the intent is not to add semantics, why include the markup in the
document? A style sheet would be the cleaner solution. If people really want
presentational markup, let me suggest that XHTML 2 is not the language for
them. Better fits include "text/enriched" documents, PostScript, Portable
Document Format (PDF), and TeX.

I genuinely do not understand. You argued against the 'sub' and 'sup'
element types on the grounds that they are presentational. Here you argue
for element types on the grounds that they are presentational. How do you
reconcile these tendencies?

-- 
Etan Wexler, dressed in silk and flavored milk.
 <mailto:ewexler@stickdog.com>

Received on Thursday, 17 April 2003 04:48:00 UTC