Re: PROPOSAL: Integrate ARIA attributes into the XHTML namespace

Yes, I put +1 because I read that it's the former.

However, I will reverse that if that was just my reading of the proposal. 

Shane, can you clarify whether proposal means that we can just use 
aria-foo properties directly in HTML?

- Aaron

"Charles McCathieNevile" <>
Richard Schwerdtfeger/Austin/IBM@IBMUS, "T.V Raman" <>
05/21/2008 12:46 PM
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 
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 

More below.



On Tue, 20 May 2008 17:06:20 +0200, Richard Schwerdtfeger 
<> 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 
>  >       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 
>  >       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", 
"" and 
"" 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 "", 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.



Charles McCathieNevile  Opera Software, Standards Group
     je parle franšais -- hablo espa˝ol -- jeg lŠrer norsk   Try Opera 9.5:

Received on Wednesday, 21 May 2008 11:08:44 UTC