Re: Next steps for the ARIA syntax discussion

ht@inf.ed.ac.uk (Henry S. Thompson) wrote on 05/23/2008 12:54:32 PM:
> >> > 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.
> 
> Please be careful when you put words in my mouth. Not advocating,
> simply observing that this happens in some (quite limited, actually)
> circumstances.  The observed change happens _only_ if you introduce an
> aria: attribute into an XML DOM by parsing a document with such an
> attribute present, _remove_ the resulting attr node programmatically
> using removeAttribute, and then add it back using setAttribute.  This
> has got to be a pretty unusual sequence of events: by far the more
> common pattern is to use setAttribute only to change the value, and
> that does _not_ provoke the change we're talking about.

This admits the problem and dances around it at the same time. Let's be 
clear: you are most certainly advocating for this proposal, and not just 
observing where it would go wrong.

How unusual can the bug be if it happened in the very first example I 
tried? Come on, you know that a checkbox is not unusual :) Before trying 
it, I really wasn't sure how easy or hard the conversion to the fake 
namespace proposal would actually be. The proposal made me believe that 
mixing with real namespaces might actually go smoothly. Unfortunately it 
just turned out to be a quagmire.

But, I'm actually glad the bugs in your proposal would happen in the most 
basic of places! It's even worse when bugs are rare, because they sneak up 
on you. The rarely seen bug is less likely to be accounted for ahead of 
time and missed. Fortunately this bug would occur in the common checkbox. 
But unfortunately it will still be missed because it does not produce 
console or JS errors.

Bugs and complexities in the foundation of an architectural design will 
ripple outward into the software ecosystem that is built on top. Setting a 
property is at the very foundation of what makes ARIA work. 

I think W3C really needs to figure out what is in its DNA at this point. 
Contributors that want credibility need to provide implementors with 
proposals that will actually work, not theories that will break the web as 
it exists today. We're spending too much time debugging proposals asking 
us to change what already works.

While I realize it's not the way people do things around here, I think it 
would be leadership by example to just withdraw this proposal because of 
the proven bugs. Let's not try to whitewash problems and pretend they 
don't matter because they're rare. Admittedly, I have often made mistakes 
in my own proposals. I promise to do by best to keep them clear of obvious 
problems before recommending them. I will listen to the community and try 
to keep the path clear so everyone can keep improving the web through 
standards.

- Aaron