Re: Meeting with SVG, XHTML, WAI people to move forward on ARIA as a cross cutting technology

Hi Henri and everyone,

Just a thought... (please see below)

Henri Sivonen wrote:
> 
> On Oct 19, 2007, at 16:04, Mark Birbeck wrote:
> 
>> On 19/10/2007, Henri Sivonen <hsivonen@iki.fi> wrote:
>>>
>>> On Oct 19, 2007, at 12:46, T.V Raman wrote:
>>>
>>>> I dont believe we need go down the ugliness of inventing a second
>>>> namespacing mechanism because some dont like the current one;
>>>
>>> I agree we shouldn't invent a second namespacing mechanism. I think
>>> we should do ARIA without a technical namespacing mechanism at all
>>> and only use a naming convention for spec organization without the
>>> parsing and DOM layers knowing anything about it.
>>
>> I know this is controversial, but I'm not sure I agree. Or perhaps
>> 'namespacing mechanism' is the the wrong phrase to use for what I
>> would like to see. Whatever it is, I would like to see something
>> 'consistent' documented.
> 
> When I said 'namespacing mechanism', I meant something that the parser 
> is aware of and the the DOM API is aware of (like Namespaces in XML). 
> When I said 'naming convention', I meant something that helps us 
> organize speccing but that the parser and the DOM API are not aware of 
> (that is, components of the name that humans see are just one opaque 
> string as far as the DOM is concerned).
> 
>> A good parallel example is in the world of XForms; there are new CSS
>> pseudo-classes and psuedo-elements that support some of the new
>> features of XForms. However, they have never been implemented in any
>> of the browsers. No surprise there, but the interesting thing is that
>> nearly all of the XForms processors out there use ordinary class
>> values to achieve the same purpose.
>>
>> For example, we (i.e., formsPlayer) used to support .disabled and
>> .enabled in order to provide ::enabled and ::disabled. But then we
>> changed it to .pc-disabled, etc., so as to convey they idea that this
>> was a pseudo-class. Similarly, elements like xf:help acquired a class
>> of .xf-help, in order to make them easier to style.
> 
> I guess that offends my CSS sense of aesthetics and language design the 
> similarly to the way the aria-* proposal offends the sense of XML 
> aesthetics of some people. I assume that you had a technical or 
> time-to-market constraint that prevented you from using the real CSS 
> pseudo-class syntax. If so, I hope you can sympathize with the technical 
> and schedule considerations that have lead to the proposal of not 
> putting the ARIA attributes in a namespace in the Namespaces in XML 
> sense of the word.
> 

I've been thinking about the whole problem for a while now - trying 
think of solutions that integrates well with all the specs and meets 
everyones requirements. Is it possible to have this as a solution with ARIA:
"aaa:aria-*"?

So in HTML we'd have:
<html>
   <ul role="checkbox" aria-checked="true">
     <li>ROFL
   </ul>
</html>

And in SVG/XMl we'd have:
<svg version="1.1"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:xhtml="http://www.w3.org/1999/xhtml"
   xmlns:aaa="http://www.w3.org/2005/07/aaa">

   <g xhtml:role="checkbox" aaa:aria-checked="true">
     <!-- Comment of randomness -->
   </g>
</svg>

It gives ARIA a naming convention - tick for HTML
It gives ARIA a name space - tick for SVG/XML
It is pretty, easy to use and intuitive - tick for Authors

I suspect I may be missing something here because I'm not sure why this 
hasn't been brought up yet. Does this require changes to ARIA or another 
spec? If so what would they be?

Any thoughts or comments would be greatly appreciated.

>> Other implementers have done something similar, perhaps using a
>> slightly different naming convention.
>>
>> As you can see, you quickly start to create 'namespaces' in the
>> ordinary, computer science sense of the term. Obviously no 'mechanism'
>> has been added here, but it certainly wouldn't hurt to have some short
>> document that indicates that 'xf-', 'pc-', 'aria-', and
>> 'whateverelse-' are being created in order to solve the same problem.
> 
> I wouldn't mind documenting this pattern. However, the expectation is to 
> get the ARIA solution into Firefox 3 and Opera 9.5, so I don't think it 
> would be reasonable to wait for a Note or other such official 
> documentation to be published before the implementations get checked in 
> and shipped.
> 
>>> No actual technical doom or gloom in Web UAs will arise from putting
>>> the ARIA attributes in the per-element no-namespace partition of
>>> elements on the XML side. We know that XHTML and SVG don't have pre-
>>> existing attributes that start with "aria-", so there won't be actual
>>> collisions as far as Web languages are concerned. In theory, a non-
>>> Web language out there could collide with this scheme if you tried to
>>> use the "aria-" naming scheme on a theoretical non-Web language.
>>> However, since we are working on Web specs, I think we should
>>> optimized for actual Web language usage instead of theoretical non-
>>> Web language usage.
>>
>> Right. But this is where I think we need to be thinking of a different
>> way of creating documentation. Take the @role documentation; all we
>> need to do there is document what it does, and the concepts it
>> represents,
> 
> Yes, we need such a document for ARIA.
> 
> [...]
>> The point is in the specification of @role, to not
>> get bogged down in how the attribute is used at a syntactic level.
> 
> The concrete syntax needs to be decided on in order for it to be 
> interoperably implementable.
> 
>> So to recap; you might not call this a new 'namespace mechanism', but
>> certainly some kind of consistent way at arriving at a self-contained
>> group of new CSS class names, style properties, attributes and
>> elements would be really useful when creating dynamic web
>> applications.
> 
> I'd call it a naming convention or a design pattern in order to avoid 
> confusion with Namespaces in XML namespace-sensitive parsing and DOM 
> processing.
> 
>> (The validation question can be solved in various ways, and is not 
>> really relevant to this.)
> 
> Agreed. Validation considerations are entirely secondary to browser 
> implementation needs.
> 


Thanks,

Anthony

Received on Monday, 22 October 2007 05:09:38 UTC