Re: Next steps for the ARIA syntax discussion

> > HST wrote:
> >> AML wrote:
> >> > I'm very concerned that there is not a realistic view about how
> >> > much this will hurt authors.
> >> 
> >> I agree that if things were as bad as you thought they were, that
> >> would be a problem.  But I hope I've shown above that they are _not_
> >> as bad as you thought.
> >
> > You don't think the fact that I got 2 different DOMs for the same 
> > attribute in my XHTML is a problem? That happens when your 
instructions 
> > are followed correct[ly]?
> 
> Not a problem for most users, no, because as long as they stick to
> doing set/get/removeAttribute("aria:...") they will never notice that
> (in Firefox) the DOM sometimes starts out one way and changes to
> another.

I want to ensure that everyone understands the proposal clearly:
HT is advocating that the DOM starts out one way and changes to another, 
for the same property value combination.

> What's crucial is that in both states the relevant attribute
> has the _same_ nodeName, that is, "aria:checked". 
> That means it's not
> a problem for browser/assistive API interface implementors either.

Some code will notice the difference. This is just good old Murphy's law 
and a daily reality for people building architectures on the web. . It is 
impossible to guarantee that 2 different representations will not end up 
being processed differently, without examining every usage.

Your proposal recommends that authors create the external, visual 
appearance that the model is the same, by using two CSS selector rules. 
This is already an indication that the two representations are not 
actually processed the same way everywhere. 

Any time a software architecture represents the identical semantics in 2 
ways, the processing of that markup must be forked somewhere else.  A good 
model should represent the same semantic in one way. A dual representation 
is a predictable source of bugs. This is a fundamental principle of 
computer science. 

The dual method of property representation are bound to introduce 
additional bugs into ARIA attribute processors -- browsers, ATs, testing 
tools, scripts or whatever.  These bugs will generally be silent errors, 
and therefore many of them will fail to be found. When they are actually 
found, the author will be forced to meticulously understand the 
excruciatingly minute differences in the representation, and where and why 
those differences occur. They will have to comb their code for ARIA 
attribute processing, test, make modifications, and test again. This will 
actually hurt potential namespace adoption and slow down ARIA's momentum, 
which should not be underestimated. It is not as common as it should e for 
a standard to get such broad adoption.

I hope the TAG respects the browser vendors' united request that we stick 
with solid architectural principles, and maintain only one representation 
for each ARIA property in the DOM. It is impossibly optimistic to hope 
that having 2 different representations for the same property, even within 
same runtime for a single page, will not create weird issues distributed 
across the complex ecosystem of web software. I am not optimistic that the 
sneaky, complex approach style work on the web. The proposal appears to 
underestimate the complexity and fragility of web architecture. 
Regressions on the web are simple to introduce, but difficult to track 
down. There are just too many diverse environments to support, and the 
technologies mix in unexpected ways. Representing the same semantic in two 
ways in a runtime, is exactly the kind of trip-wire that developers are 
trained to avoid.  In general, the risky, complex approach is not the 
right one for the web.

Two representations in one runtime is fundamentally wrong and predictably 
buggy.

Strong -1 on the proposal to use colon for fake namespaces.

- Aaron