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

Tim, thanks for giving us this chance to clear up what is
actually going on.

We look forward to further discussion with the TAG at their
convenience should this be required.

Tim Berners-Lee wrote:

> Very much in summary, some of the feedback from th TAG has been along
> the following lines
>
> - The idea of effectively using aria- s a sort namespace prefix in has
> issues
>      -- it is reinvention of the namespace system
>

It is not a reinvention of *the* namespace *system*. Namespaces in  
XML defines a namespace mechanism the affects generic *processing* in  
the XML parser and in DOM Core.

The leading objective of WAI-ARIA markup is to get the state of  
scripted behaviors captured in document content for sharing with  
assistive technologies through the established accessibility APIs.   
Hence, it centers on how the scripts interact with a document through  
the DOM.  To do this in multiple host languages,  the aria-* naming  
scheme had been chosen to allow *cooperating W3C groups* to partition  
the space of possible attribute names for the purpose of dividing  
work among specs and working groups.  This, fortunately, is  
accomplished *without* making the parser and the DOM Core layer  
perform any generic processing related to this partitioning.  As far  
as the DOM is concerned, the aria-* attributes are in *no namespace*  
in the Namespaces in XML sense.


>      -- the NS WG decided to use ':' among all eht various name chars
> to select
>

Namespaces in XML causes namespace-aware processing on the generic  
XML level. This processing is not available in text/html -- neither  
as implemented today in Gecko, WebKit and Opera and nor as specified  
in the HTML 5 draft. The processing implemented in IE for text/html  
differs from what DOM Core XML specifies for XML.

':' isn't used, because the same processing of it isn't available on  
all the platforms that ARIA needs to work on. In this case, text/html  
and XML are spec platforms with different ':' treatment, and IE on  
one hand and Gecko, WebKit and Opera on the other hand are software  
platforms with different ':' treatment.


>      -- Users will find it very confusing to use sometimes aria- and
> sometimes aria:
>

Agreed. Since aria:* cannot work consistently (in terms of syntax and  
DOM representation) everywhere but aria-* can, aria-* was chosen.


> We wondered why the following was rejected:
>
> -   Use aria:foo elements in the HTML version too.  get HTML to allow
> these in a non-ns-aware HTML scearipo, with a an *implicit* prefix
> declaration
>

There is *no* way of introducing a colon-based syntax to text/html  
without creating a scripting discrepancy *somewhere*. This is simply  
because shipped IE and shipped Gecko/WebKit/Opera do different things  
with the colon, so even if new browsers changed their behavior,  
there'd have to be a discrepancy with either shipped IE or shipped  
Gecko/WebKit/Opera (or both).

Using the IE precedent would mean that the exact behavior of what IE  
does with the colon would have to be discovered, specified and  
implemented in the Firefox 3 and Opera 9.5 timeframe. This is  
seriously not feasible. Moreover, it would cause a DOM discrepancy  
with past Firefox and Opera releases which is still relevant for ARIA- 
based CSS styling even if past releases wouldn't hook accessibility  
processing to aria-*. Even if that problem was overlooked, it would  
create a scripting/DOM discrepancy between the text/html  
serialization of HTML5 and the application/xhtml+xml serialization  
of  HTML5, because the way IE represents colon-based namespaces in  
the HTML DOM is different from how Namespaces in XML are represented  
in DOM Level 2 Core.

OTOH, if IE were required to change their stuff to match DOM Level 2  
Core, the result wouldn't reuse the IE precedent but it would be  
something new and *incompatible*.

The reasonable practical course of action that allows for consistent  
scripting across browsers and serializations is to steer away from  
the colon.


> - Maybe have a list of implicit NS prefixes fro the text/html MIME
> type stored in a file linked from the MIME type declaration  -- could
> this b a general way of mapping non-XML to namespaced XML?
>

That would be a discrepancy with both the way IE works today *and*  
the way Gecko/WebKit/Opera work today. ARIA needs to work on top of  
the existing DOM and parsing infrastructure in these browsers in  
order to achieve expedient time to market. (The whole point of ARIA  
is to allow legacy to be retrofitted with annotations soon. For the  
long term, there's the possibility of refining the built-in semantics  
of the base vocabularies and creating custom widgets with XBL2.)


>      -- 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)

There are two reasons why it is desirable to get syntax that works  
the same way in all three cases:

  1) Script authors should be able to use the same (existing) DOM  
method in all the three cases (possible with aria-* but not with  
aria:*). This allows for portable scripts. Even though scripting is  
sometimes frowned upon when it comes to Architecture, scripting  
matters a great deal in this case, because script-based manipulation  
is the whole point of having ARIA states in an interactive rich Web  
application.

  2) The *software architecture* in Gecko, WebKit and Opera (and some  
non-browser tools) aims for code reuse between text/html and  
application/xhtml+xml processing. That is, ideally even from the  
point of view of browser internals, the code that queries the DOM  
shouldn't have to care whether the DOM was parsed from text/html or  
application/xhtml+xml. The design of HTML 5 supports this kind of  
software architecture that was induced by the design of XHTML 1.0 as  
a mere reformulation of HTML 4.01. It would be bad for ARIA in (X) 
HTML5 to be a special case.

Finally, it is desirable to make ARIA usage in SVG consistent with  
the usage in HTML and XHTML 1.x/5 both in terms of syntax and the DOM  
API.

-- 

Al

Received on Friday, 7 March 2008 14:54:45 UTC