Re: Next steps for the ARIA syntax discussion

Hi Henry, can you please take a look at my experience converting an ARIA 
example to use the colon. It's an ARIA checkbox that was first built 
several years ago in order to test Mozilla's ARIA support. 

I was reading your analysis at 
http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html#analysis
It says that setAttribute("aria:checked") will work the same in html as in 
application/xhtml+xml. I read this in the Cost-benefits analysis table 
under benefits of the colon: "Consistency for page authors; Uniform DOM 
access (using Get/SetAttribute); Orthogonal in XML languages; consistent 
with namespace-based extensibility for XML (and for HTML5?1) "

I was surprised that it all sounded pretty simple so I set out to convert 
my checkbox example to use the colon, both in HTML and XHTML.
Test cases with hyphen (known to work):
ARIA checkbox in HTML with aria-checked: 
https://bugzilla.mozilla.org/attachment.cgi?id=321761
ARIA checkbox in XHTML with aria-checked:  
https://bugzilla.mozilla.org/attachment.cgi?id=321763

New test cases with colon:
ARIA checkbox in HTML with aria:checked: 
http://www.mozilla.org/access/dhtml/checkbox-colons.html
ARIA checkbox in XHTML with aria:checked: 
http://www.mozilla.org/access/dhtml/checkbox-colons.xhtml

Converting to the HTML version using colon was in fact simple except that 
it no longer worked in IE7 because \: doesn't work there. But, since 
attribute selectors don't work in IE6 anyway, it's possibly an acceptable 
loss. It means we will need to write extra code to change styles directly, 
but let's forget about that for now.

Converting to XHTML turned out to be a difficult struggle. Here's what 
happened:
I kept the script the same, apparently there was a silent error which I 
almost missed. By silent I mean that at first it appeared to work. There 
was no parsing error or JavaScript console warning. If I clicked on the 
checkbox a number of times it started toggling. No problem, I thought 
everything was the same. However, something seemed strange.  A subtle bug 
was introduced where the first click or space key press on the checkbox 
was ignored, and then toggling appeared to work after that.

I had forgotten that in XHTML the CSS should say aria|checked instead of 
aria\:checked. So it was my mistake, but one caused by an unexpected 
difference between HTML and XHTML. I fixed the CSS, and suddenly the 
checkbox shows up correctly checked initially. Cool! I clicked the 
checkbox and it appeared to work. But now I was suspicious, and kept 
testing. I discovered that the checkbox ignored any clicks after the first 
one.  Once it was unchecked I could no longer recheck it.

Here's what I learned about the colon after my debugging session:
1. Depending on whether I'm in HTML or XHTML, depending on whether I 
declare or set the ARIA property, or depending on whether I use 
setAttribute or setAttributeNS, the aria:checked attribute shows up 
differently in the DOM. 
2. setAttribute works differently from either getAttribute or 
removeAttribute with "foo:bar". Where namespaces are supported, 
setAttribute("foo:bar") doesn't use DOM namespaces, but the other methods 
do. If namespaces are ever added to HTML, either that inconsistency will 
need to remain or we'd instead be introducing a difference with how XHTML 
supports setAttribute().
3. Safari acted like Mozilla, but Opera didn't work with the new example 
at all.

This all confused me and I spent quite a lot of time puzzling out what was 
happening.  It took longer because it seemed so counterintuitive. My brain 
did not want to accept the same attribute in the DOM using different 
methodologies at different times.

The analysis document had told me that setAttribute("aria:checked") will 
just work the same in XHTML, but it did not turn out to be true. Believing 
that resulted in bugs which were very hard for me to discover, understand 
and fix. I grew tired and frustrated trying to understand how the two 
different uses of colons were intermixing in the DOM before I could fix 
them. My brain spun thinking about what happens if both kinds of 
attributes are set.

Let's say that authors just need to be smart and understand all of this, 
do the extra work to understand this and test it, and that they won't be 
put off by the inconsistencies. Let's say that current implementations 
will all be changed within a year or so and that users will all update 
their software. There is still a problem if we want to leave the 
possibility open for namespaces in text/html. Basically, unless the colon 
means something different from it is used in XHTML now, that will mean 
that depending on whether you declare an attribute, use setAttribute() or 
get/removeAttribute(), or use the blahAttributeNS() methods, DOM 
namespaces will be used or ignored. I can think of a lot of ways authors 
and implementations will get confused.

I'm very concerned that there is not a realistic view about how much this 
will hurt authors. I enjoy working with such bright W3C standards 
developers, but these are not your average developer. Very rarely do 
developers understand how colon acts differently in different places. If 
they're like me, they think they understand it one minute and then learn 
they were wrong when someone reports a bug. Many aspects are just bugs 
waiting to happen: poorly-documented, counter-intuitive suprises. To be 
honest I haven't found many developers interested in using up their brain 
cells to figure this out. I would not think that I'm alone in my confusion 
with the colon. Anyone who isn't confused either spent a lot of their 
careers understanding it or don't realize what they misunderstand. Most 
developers would rather spend their time working out real solutions for 
real users. I'm not sure I even understand what the issues are well enough 
myself, to update tutorials and docs that I've written or help developers 
who ask.

In general, I don't feel qualified to understand how colon works across 
browsers, mime types and uses, but I do feel qualified that the new use of 
colon has too many weird edges, and is too complicated for the intended 
audience of ARIA. Perhaps I'm not credible since I am obviously vested in 
Firefox 3 and Dojo's current ARIA implementations. However, I think 
reading this, other people that need to educate developers on ARIA will 
agree this is just too much to deal with. This really isn't about liking 
namespaces or not. I'm personally not qualified to say much about them.

While I am respectful of the general desire to not throw out W3C's 
namespace architecture after years of work, I think that recommending 
colon to support fake namespaces only hurts the real namespace cause. 
Let's keep the simple approach for ARIA properties, which works well now 
and is the same no matter where it's used. I'm sorry that it isn't the 
originally intended way to do these things, but that's not where the web 
is. ARIA is for solving accessibility problems in content today. We can 
reserve the colon for true, pure namespaces in text/html in case the 
community decides to pursue that.

- Aaron





From:
ht@inf.ed.ac.uk (Henry S. Thompson)
To:
Henri Sivonen <hsivonen@iki.fi>
Cc:
"www-tag@w3.org" <www-tag@w3.org>, "public-html@w3.org" 
<public-html@w3.org>, "public-xhtml2@w3.org" <public-xhtml2@w3.org>, 
"wai-xtech@w3.org" <wai-xtech@w3.org>
Date:
05/15/2008 03:14 PM
Subject:
Re: Next steps for the ARIA syntax discussion




-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henri Sivonen writes:

> First, the "Matches CSS Selector" result for SVG looks weird. I don't
> see which test case this result came from.

You're right, that's misleading.  Although SVG Tiny doesn't support
CSS from stylesheets at all, SVG 1.0 and 1.1 did, and SVG 1.2 will I
guess, so I should have tested that -- I had misread something which
made me thing SVG 1.0/1.1 didn't support attribute selectors at all.

ht
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of 
Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged 
spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFILDc7kjnJixAXWBoRAkh8AJ41PLOUR6M8OootgbgTCfTr8B4RBwCcDjUF
bgtHuUkitO5v4CXKxFVhINg=
=sZ/l
-----END PGP SIGNATURE-----