W3C home > Mailing lists > Public > www-html@w3.org > April 2003

Re: more xhtml 2.0 comments

From: Mikko Rantalainen <mira@st.jyu.fi>
Date: Mon, 14 Apr 2003 16:18:32 +0300
Message-ID: <3E9AB528.2040100@st.jyu.fi>
To: "www-html@w3.org" <www-html@w3.org>
CC: Daniel Glazman <glazman@netscape.com>

Daniel Glazman wrote:
> 7. deprecating h1-h6 is a performance hit for web browsers. If the h element is
>     introduced with the section element, a default stylesheet for XHTML 2.0 will
>     need
> [...]
>     More generally, I am under the impression that browser performance has not
>     been taken under consideration for the design of XHTML 2.0.

Please, some dumb browser might receive a minor performance hit with 
section and h, but we need those if we're trying to describe the 
structure of the document instead of simply rendering. If the 
performance hit of "section > h" selector is too much then perhaps the 
browser should internally convert those elements to h1, h2 or whatever. 
I find it hard to believe that identifying all the headers in a document 
would be a major performance hit compared to all the other stuff one can 
do with CSS level 2 selectors.

> 20. I find the nl element useless.

How about an "nav" or "navigation" element. The point of that kind of 
element is to allow the user to remove page navigation with his user 
stylesheet. The nl element already does this but it cannot reasonably 
contain any navigation style but a list.

> 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)

May I suggest that the first direct descendant element h of root element 
html should replace the title element inside head? I'd also prefer 

<h>Title of the whole document (old title element)</h>
<h>title of the first section (old h1)</h>
<h>title of the first subsection (old h2)</h>
<h>Is this the new title for the rest of the document or what?</h>

> 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. If you really want to extract presentation from the markup
>     here, use a processing instruction <?line-break?> instead of <br>.

But there are things that are lines but can be displayed as separate 
lines. Lines of poems, post address or computer code are examples for 
this. All of those have some meaning in the line breaks but as for the 
presentation the line break might not be needed. On the other hand, the 
presentation could require the knowledge of both the start and the end 
of the logical line to display it correctly. A single <br> or 
<?line-break?> can represent only one end of the logical line. Document 
authors using wysiwyg editors should be made aware of the difference 
between a simple linebreak and a logical line.

I find it hard to come up with an example where the only semantics of a 
line break is a line break. I believe that a line break is simply a 
separator that one uses to display the break between two things that are 
bigger blocks in the document (for example logical lines).

Yes, making a wysiwyg editor can be a little harder but XHTML2 is 
supposed to describe semantics over presentation. A wysiwyg editor is 
about the worst thing to represent a semantic document to the editor 
while authoring the document, IMHO.

> 24. the address element should be improved, I agree. But not using the l
>     element has it has often been proposed. That's not enough.

I think the address element should go or at least it should be renamed 
unless it's supposed to contain generic contact information instead of 
simply page author information. I've seen that element misused probably 
more often than used correctly.

> 26. removing the hr element is counter-productive; renaming it is useless, keep
>     it simple and stupid.

There's no need for hr or any other similar element with different name. 
I feel that hr is just the same as br: it successfully represents only 
one end of an element and therefore it should go. A series of section or 
div element edges should be used instead to represent the locations the 
renderer should add pause.

> 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.

Again, the language shouldn't be modified just because the old editing 
method cannot easily comply with the spec. I feel that the problem is 
that the old method doesn't describe the semantics at all and all the 
changes required to make the new language compliant with the old editing 
method practically require removing of all sematics.

IMO, an enter key should always start a new paragraph (and close current 
one because paragraphs cannot be nested) and nothing else. Problem 
solved, now the user doens't need to guess what happens when he presses 
the enter key. If the user wants to see a line break he must define the 
meaning of the stuff before and/or after the line break position so that 
the sematics can be added. With a good user interface the user just adds 
different things to the document and line breaks are magically displayed 
in places where the user would have traditionally entered them by hand.

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

As long as one can rely that MathML is available they are purely 
presentational. If XHTML should be usable without MathML we need sub and 
sub to easily markup stuff like 2H2O.

> 34. the label element should be called title and should be allowed in ul/ol/dl.
>     I already said that I find nl useless.

Make it h instead of title. What's the difference between h and title?

> 37. just for the record, the lack of style attribute is a major error, recently
>     fixed by the HTML and the CSS WG jointly.

I still believe that style attribute is only needed for wysiwyg editors 
that use traditional editing method (presentation over semantics) and 
should be left away if XHTML2 is supposed to be about semantics. Also 
wysiwyg editors should copy headers and paragraphs, not bolded big text 
and roman small text.

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

IMO, it's not the job of page author to define where I want to read the 
link he's providing. My input device already has a separate button for 
links that I want to open in a new window.

> 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.

But there must be some reason to make those pieces of text bold, 
italiced or underlined, right? Failure to identify that reason is the 
problem, not the lack of purely presentational elements.

That being said, I think B, I and U could be saved but they should be 
defined as "these mean nothing but the default rendering is XXX unless 
changed *for any reason*". The suggested usage would be to use instead 
of span if the only other reasonable alternative is span. Rationale: if 
the only thing you can say about a piece of text is that it's usually 
rendered with italiced text (like some pieces of information in biology) 
then it should be allowed. A piece of text without meaning that is 
rendered italiced contains more information than a piece of text without 
meaning. I think I still prefer classed em elements instead.

Received on Monday, 14 April 2003 09:18:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:03 UTC