Re: PROPOSAL: Integrate ARIA attributes into the XHTML namespace

Do you all mean the null namespace that HTML and most SVG attributes are  
in already, or do you mean the namespace http://www.w3.org/1999/xhtml  
which is not used for a lot of attributes right now?

The former makes sense. The latter doesn't, because it leads us down the  
path of major divergence between ARIA in HTML and ARIA in everything else,  
which is something we are working strenuously to avoid.

So a strong plus or minus one, depending on the answer to the first  
question.

More below.

Cheers

Chaals

On Tue, 20 May 2008 17:06:20 +0200, Richard Schwerdtfeger  
<schwer@us.ibm.com> wrote:

> This should also appease the TAG.

If the tag want a namespace-based solution that actually works, then the  
namespace used is pretty much required to be the null namespace.

>             "T.V Raman"
> a loud 1+ on this.
>
> Shane McCarron writes:

>  > In the spirit of that, I tried to think outside the box a little bit -
>  > just as we did at the f2f meeting in Venice when considering how to  
> deal
>  > with ARIA-defined values for @role.  Consequently, I propose the
> following:
>  >
>  >    1. Eliminate the private "aria" namespace.
>  >    2. Incorporate the 'aria-*' attributes into the XHTML namespace.
>  >    3. Define the attributes in an XHTML M12N-conforming module so that
>  >       they can be easily incorporated into XHTML Family markup
>  >       languages.
>  >    4. Make that module "chameleon", just like XHTML Role, so that  
>  >       other languages can easily incorporate the attributes into their
>  >       own namespace if they choose.
>  >    5. Ensure that such a definition does not preclude the use in  
>  >       non-XML grammars such as HTML 5.

If I understand the proposal correctly, then it means that there would be  
ARIA attributes running around in a bunch of different namespaces. That  
doesn't seem like a win. If we simply use the null namespace (analagous to  
what has been done in W3C specs for events) then everything works nicely.  
Of course the null namespace is already a bit messy, so using some  
*further* marker like "aria-" helps to clarify how it works.

the fully-qualified attributes "nullaria-something",  
"http://www.w3.org/1999/xhtmlaria-something" and  
"http://www.w3.org/2000/svgaria-something" are different. But because of  
quirks in existing implementation, the first one is readily included in  
almost any relevant case today, at least by implementations, and it isn't  
terribly difficult to add it to specs. There remains the question of what  
happens when ARIA attributes are in conflict with non-aria attributes that  
serve the same purpose, but it is orthogonal to the matter at hand.

An attribute called "nullaria:something" is not the same as an attribute  
called "http://www.w3.org/xhtmlsomething", and this proposal means that  
the names of aria attributes need to be checked carefully to ensure they  
don't clash with existing attribute names in HTML, whereas using aria- as  
a further disambiguator solves that problem.

So a simpler solution is to have the attributes in the null namespace  
(which is a real and widely used namespace), start their local name with  
aria- and let the implementations continue to behave properly in both HTML  
and XML, allowing ARIA to be used in a variety of current languages in a  
variety of current browsers following current advice.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Wednesday, 21 May 2008 10:47:04 UTC