- From: Daniel Glazman <glazou_2000@yahoo.fr>
- Date: 2002年12月18日 12:34:14 +0100 (CET)
- To: www-html@w3.org
- Message-ID: <20021218113414.88593.qmail@web20007.mail.yahoo.com>
Important disclaimers:
(a) The current message expresses my personal opinions ONLY, and
does NOT reflect the position of my employer.
(b) The current message is meant to be constructive; criticism is
always helpful when carefully used.
Comments:
1. I regret that a proprietary extension to HTML was not
standardized and added to XHTML : the contenteditable attribute. It
allows to make an element and its contents editable in a browser.
Simple, powerful, efficient and to be fair, very well done. This
attribute was proposed by Microsoft loooong time ago, is widely
used and I have always expressed admiration for this solution (I
mentioned that to Tantek ヌelik during the Cleveland CSS WG ftf
meeting).
2. I deeply regret that the style attribute was dropped. I would like
the XHTML WG to explain how can I copy an element (+contents +
style)
from one XHTML2 instance to another one if I can't modify
an external stylesheet nor create a new one (that's often the case
in
cooperative editing systems).
The best system for copy/paste seems to me the existence of the
style attribute, populated with all CSS properties having a computed
value different from their initial value.
Dropping the style attribute is my opinion a *major* error, a
counter-productive decision for the future of the Web. It is,
from my perspective, an important enough issue to make XHTML 2.0
an "harmful" proposal.
3. I am not any longer in favor of strict separation of content and
presentation FOR THE WEB. I know that if you search in the early
archives of the HTML ERB, you'll easily find messages where I
expressed the opposite opinion. Only stupid people never change of
mind, right ?-) So let me explain :
(a) I think that all presentational elements but three should be
forbidden in XHTML. The only allowed elements should be, because
of their super wide use and because NO, you don't always want to
add semantics to a piece of text you want to see in bold-italic,
B I and U.
These three elements could be in an XHTML Inline Elements module
or in the existing Presentation Module.
(b) I think that presentational attributes should be allowed in
XHTML
if and only if they have a NORMATIVE CSS definition for screen
media. For instance:
td[bgcolor] { background-color: attr(bgcolor); }
(b++) The spec should recommend that other visual media infer
default CSS styles from that default screen stylesheet.
(c) that way, we can add to XHTML all the stuff Web authors have
consistently asked for since 1998: bgcolor and bgimage attribute
on all elements, height attribute on table, ...
Doing so will also help a large number of documents available
TODAY on the web moving to conformance.
To be honest, I am very surprised that the HTML Writers
Guild, supposedly representing hundreds of thousands of web
authors,
supports XHTML 2 without advocating more for such a solution.
What's important here is the consistent and interoperable
definition
of presentational attributes. If they are NORMATIVELY DEFINED
using CSS, they definitely make sense.
4. I think that the lack of a default NORMATIVE stylesheet for XHTML 2
is an error that all HTML dialects have consistently made and that
XHTML 2 should fix. Without such a normative stylesheet, we will
have
rendering differences between browsers and that's not a price Web
authors should have to pay.
Please do not answer that this is the task of the CSS WG, I strongly
disagree with that. You are designing a language meant to be the new
Lingua Franca of the web, everything should be done by the HTML WG
to make sure XHTML is *really* a lingua franca. Without a normative
stylesheet for screen, it can't be a lingua franca.
In particular, the new elements XHTML 2.0 introduces like NL have no
historical record on the Web. Without a normative style definition,
I bet we'll have different renderings for them in different implems.
5. I find the removal of ins and del elements excellent. These elements
were EXTREMELY hard to implement because they could be inline-level
or block-level. The new edit attribute solve this problem and will
allow implementors to move forward and propose simple revision
control
in XHTML content editors. Thanks.
6. The hreflang attribute is mentioned in section 5.5 but is not
defined
in the spec.
7. The simplification of headings is hardly understandable when
different
list elements remain in XHTML 2. Why remove h1-h6 in favor of
heading
and keep ol-ul ? Let's be consistent here and remove ol-ul in favor
of a list element with one 'ordered' attribute with value
true|false.
This comment does not imply I am in favor of the heading element.
And in fact I am not.
Same thing about the dual usage of a element: named anchor, target
of
a link or source of a link. The name attribute of a SHOULD NOT be
meaningful for named anchors and only id should allow targeting of
fragment-identifiers.
8. Anchors (sources of a link) are still mono-target. This is a pity.
There should be an inline-level element containing a elements. Ex:
<link> <!-- I am using that name on purpose -->
<a href="http://www.w3.org/TR/xhtml">XHTML 2.0</a>
<a href="htttp://www.ercim.org/xhtml">XHTML 2.0
(Mirror at ERCIM)</a>
</link>
9. Link types should allow "icon" for rel/rev. That's proposed by
Mozilla
for page favicons.
10. section 12.1: "We should specify a minimal set of useful meta
properties". I disagree with that. The HTML WG should specify a
MAXIMAL set of useful meta properties. Web authors have consistently
requested extensions to the HTML 4 meta/name values and it would be
a serious error not to listen to these requests.
last-editor
last-edited
last-edited-by
creator
created
created-by (was generator ?)
...
11. I would like to see the fact that sub-elements in head can be
displayed/render as a conformance criterium
12. Section 14.3: "Many scripts (e.g., French) require...".
French is not a script, it's a language. The wording is here
inadequate.
14. Once again, the navigation through link elements remain the
poor parent of the spec. It is still impossible to dereference the
target of an anchor to the href of a link element. I would like to
see this behavior happen, proposed in my very old W3C Submission
"Navigation through LINK elements" that Amaya implemented: if the
target of an anchor is a link element contained in the document
containing the anchor, the href of the anchor is dereferenced to
the href of the targeted link element. Example:
<link id="tocLink" rel="contents" href="TOC.htm"/>
...
<a href="#tocLink">Click here to see the table of contents</a>
Conclusion:
As it is in its 2002年12月11日 WD, I think that XHTML 2.0 is far
away from both what the Web Authors are expecting and from what
could be done to "lead the Web to its full potential".
The current WD makes some strategic choices (style attribute
for instance) that seem to me harmful.
I see no incentive for a Web Author to ever move to XHTML 2 from
a simple XMLized version of the actual transitional HTML4 (call
that as you wish). XHTML 2.0 does not contain ANY new key feature
and seem to get totally rid of all Authors' requests between 1998
and today.
From my perspective, XHTML 2.0 as it is today is a failure and the
work of the HTML WG on this topic should be immediately and
totally reoriented.
Once again, the current message expresses ONLY my personal opinions.
Regards,
</Daniel>
___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran軋is !
Yahoo! Mail : http://fr.mail.yahoo.com
Received on Wednesday, 18 December 2002 06:41:26 UTC