RE: State and Status of WAI-ARIA approach to host-language embedding

Michael,

A quick question (I hope) arising from are read of your summary.

Which ARIA embedding approach will the WG be recommending/encouraging to authors of XHTML (1.0, 1.x, 2)  authors?

Thx,

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

________________________________
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Michael Cooper
Sent: 02 April 2008 22:18
To: Al Gilman
Cc: Dan Connolly; Tim Berners-Lee; TAG List; Judy Brewer; W3C WAI-PFWG
Subject: Re: State and Status of WAI-ARIA approach to host-language embedding

As this discussion about ARIA implementation has progressed, it seems that not all people may have the same understanding of the premises behind the discussion. In attempt to clarify things, I have prepared a summary document, available at http://www.w3.org/2008/03/aria-implementation. This is an explanation of the concerns as the PFWG understand them, and an attempt to clarify its position with respect to them. I hope this serves as a useful input to further discussion.

Michael

Al Gilman wrote:


On 13 Mar 2008, at 1:19 PM, Dan Connolly wrote:


Al Gilman wrote:
[..]
     -- What is et problem with browsers handling a colon in an HTML
tag name?  Pointers?

The colon works in three mutually incompatible ways in
 1) text/html in IE
 2) text/html in Gecko/WebKit/Opera
 3) XML (including application/xhtml+xml in Gecko/WebKit/Opera)

Would you please elaborate? preferably in the form of test cases?
i.e. specific example documents?

Henri Sivonen and Simon Pieters contributed the discussion quoted
below, that I can't improve upon.

Note in particular that there are specification-based differences
in the behavior.  Yes, it's a difference built into the way the
Web works today, and yes, there is an implementation glitch or two here
and there that exacerbates the problem; but *even if the
implementation glitches weren't there,* there would still be a problem with
using colons in the attribute-names of the WAI-ARIA attributes.

So it's not just "a problem with the current implementations."  It's
a problem with the HTML and XML specifications requiring different things.

Al

--
    From:       simonp@opera.com<mailto:simonp@opera.com>
    Subject:     Re: test cases to demonstrate differences?
    Date:     March 19, 2008 7:32:05 PM EDT

On Tue, 18 Mar 2008 13:20:01 +0100, Henri Sivonen <hsivonen@iki.fi><mailto:hsivonen@iki.fi> wrote:


Here's what I would have sent on my own but didn't. Feel free to present my points as yours.


Thanks Henri for writing this email; I'll augment with some additional points below.
[...]
On Mar 18, 2008, at 04:02, Al Gilman wrote:

Begin forwarded message:

Al Gilman wrote:
[..]

    -- What is et problem with browsers handling a colon in an HTML
tag name?  Pointers?


The colon works in three mutually incompatible ways in
1) text/html in IE
2) text/html in Gecko/WebKit/Opera
3) XML (including application/xhtml+xml in Gecko/WebKit/Opera)


Would you please elaborate? preferably in the form of test cases?
i.e. specific example documents?
[...]

There's a demo of how different syntaxes behave with getters and selectors:
http://simon.html5.org/test/aria/colon-vs-dash/


Now also features setters.

Browsershots:
http://browsershots.org/http://simon.html5.org/test/aria/colon-vs-dash/


Requests 1 to 3 are of the old demo; request 4 is of the new demo.

Things to note:
  * IE6 doesn't support attribute selectors at all, so the test is moot in IE6.
  * The IE7 screenshot in group 1 has failed to load all the iframes, see group 3 instead.
  * The colon breaks attribute selectors in IE7. The dash does not.
  * The selector behavior with the colon is incompatible between HTML and XHTML in Gecko, Opera and WebKit.
  * Konqueror's XHTML processing has bug which makes the colon behave differently from Gecko, Opera and WebKit.
  * The dash works consistently in all the tested browsers that support attribute selectors. (All but IE6.)
  * In browsers that support both XHTML and HTML, the dash works consistently across XHTML and HTML.


  * setAttribute() with colon results in the HTML-style no-namespace
    attribute, while setAttributeNS() with colon results in the XML-style
    namespaced attribute. (Per spec, but probably confusing for authors.)

  * When using the dash, there no need to use namespaces in CSS or *NS
    methods in the DOM (which are not even implemented in IE). Just
    straightforward [aria-foo] and get/setAttribute().

In summary: The dash works consistently in all cases (except IE6 which doesn't support attribute selectors in either case). The colon causes various kinds of inconsistencies between browsers and within browsers between serializations.

I think we should also give spec citations for the cases where these
differences are required by specification.  You and Henri had to follow
up to teach me this, and the TAG could well be unclear on this point,
from the record we have of their latest telecon.


HTML 4.01 has no support for namespaces. The Namespaces in XML spec does not in any way affect HTML or text/html processing. Therefore, the colon has no magic attached to it in text/html. It's a bit hard to point to something that isn't there, but perhaps the non-existence can be demonstrated by inspection: HTML 4.01 and RFC 2854 don't mention the word "namespace":

   http://www.google.com/search?q=namespace+site%3Awww.w3.org%2FTR%2Fhtml4%2F
   http://www.google.com/search?q=namespace+site%3Ahttp%3A%2F%2Fwww.ietf.org%2Frfc%2Frfc2854.txt

...and the only mentions of "html" in the Namespaces in XML spec is in examples that use XHTML.

In DOM Level 2 Core, the *NS method variants have in their definition "HTML-only DOM implementations do not need to implement this method." Clearly, the writers of the spec thought that namespace processing is not relevant to HTML. Section "1.1.8. XML Namespaces" takes it for granted that namespaces apply to XML as in the section title and doesn't even mention HTML.
http://www.w3.org/TR/DOM-Level-2-Core/core.html

DOM Level 3 Core makes the non-support of namespaces in HTML explicit:
"NOT_SUPPORTED_ERR: May be raised if the implementation does not support the feature "XML" and the language exposed through the Document does not support XML Namespaces (such as [HTML 4.01]). "
http://www.w3.org/TR/DOM-Level-3-Core/core.html

<quote
cite="http://www.w3.org/2008/03/13-tagmem-minutes.html#item02"<http://www.w3.org/2008/03/13-tagmem-minutes.html#item02>>
is a problem with existing browser implementations
</quote>

The recent discussion in the HTML WG relating to namespaces is about enabling the creation of SVG and MathML DOM fragments by the HTML 5 parsing algorithm. In that case, the legacy is that SVG renderers expect the *element* nodes to be in the SVG namespace. ARIA is about attributes and has a very different DOM legacy landscape and very different time-to-market considerations.

Even if the SVG-in-text/html ever goes somewhere, it will be *at least* one major browser release cycle away. On the other hand, three out of the top four browsers are about to be updated with ARIA support with the dash syntax. That's a remarkably good situation from the Web accessibility point of view. It would be foolish to disrupt the situation because of a Namespaces in XML-related principle and delay accessibility features that are acutely needed.


--

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org<mailto:cooper@w3.org>
Information Page<http://www.w3.org/People/cooper/>