W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

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

From: Michael Cooper <cooper@w3.org>
Date: Thu, 03 Apr 2008 11:23:49 -0400
Message-ID: <47F4F685.9070201@w3.org>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Cc: Al Gilman <Alfred.S.Gilman@IEEE.org>, 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>
Hi Stuart -

(Thanks to Al for the bulk of the response here)

In general, if sending content to the browser, authors should use the 
no-namespaces approach (typically with HTML or XHTML 1.0). This is the 
form browsers will expect. However, if processing through middleware, we 
recommend using the with-namespaces approach (typically in XHTML 1.1 or 
2.0).

We won't be pushing authors strongly in this regard. What we will be 
telling them has to do with what we feel will most often meet their 
needs best.

Note that the deciding factor is not root format but destination. The 
advice to authors, such as it is, does not break down cleanly along 
"root document format" lines. The most obvious dividing line has to do 
with the next stop for the document.

If the document is ready as a file to be delivered over the retail web 
to a browser, then the "no namespaces" embedding approach would be best 
suited.  This will be
true of HTML documents and many XHTML 1.0 documents wishing to be 
processable, without noticeable degradation, in compatibility mode.

If the document is expected to be processed through middleware enroute 
to the browser, then the advantages of XML may outweigh the factors 
favoring the 'no namespaces' approach and the "with namespaces" 
embedding approach may be more attractive to authors. This will likely 
include all XHTML 2.0 documents and most XHTML 1.1 documents. At the 
final stage of processing, just before sending to the browser, content 
should be transformed to the "no namespaces" form.

A stronger indicator in favor of the "with namespaces" approach is that 
if the content management architecture that the author is working in 
wants to take advantage of Namespaces or other XML-peculiar features 
then they will want to use the "with namespaces" approach, and select 
XHTML 1.1 or 2.0 for use in the CMS / middleware environment.

Michael

Williams, Stuart (HP Labs, Bristol) wrote:
> 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
>>         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 <mailto:cooper@w3.org>
>     Information Page <http://www.w3.org/People/cooper/>
>

-- 

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/>
Received on Thursday, 3 April 2008 15:24:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:55 GMT