comments on 2002-12-12 XHTML 2.0 WD

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çais !
Yahoo! Mail : http://fr.mail.yahoo.com

Received on Wednesday, 18 December 2002 06:41:26 UTC