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

Michael:

Speaking as an individual TAG member, I find this very, very helpful. 
Thank you for all the hard work you put into it.  I hope that other TAG 
members will find the time to read [1] in detail before the discussion of 
Aria on tomorrow's weekly TAG teleconference.  Thank you.

Noah

[1]  http://www.w3.org/2008/03/aria-implementation

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Michael Cooper <cooper@w3.org>
Sent by: www-tag-request@w3.org
04/02/2008 05:18 PM
 
        To:     Al Gilman <Alfred.S.Gilman@IEEE.org>
        cc:     Dan Connolly <connolly@w3.org>, Tim Berners-Lee 
<timbl@w3.org>, TAG List <www-tag@w3.org>, Judy Brewer <jbrewer@w3.org>, 
W3C WAI-PFWG <w3c-wai-pf@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        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 
    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> 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"> 
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
Information Page

Received on Wednesday, 2 April 2008 21:45:10 UTC