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

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.

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

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 19 October 2007 13:48:33 UTC