Re: Next steps for the ARIA syntax discussion

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

Aaron M Leventhal writes:

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

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

And depending on (which version of) which browser you're using.

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

I think it's slightly trickier than that -- at least in Firefox
setAttribute("foo:bar") behaves differently wrt an XML DOM depending
on whether or not there was a foo:bar attribute in the input.  If
there was, it sets its value.  If there wasn't, it creates a new
attribute, but not with the same properties.  See discussion below at **.

In other words, what we might call the "setAttributeValue" aspect of
setAttribute works differently/more flexibly compared to its
"createAttribute" aspect.

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

See below at *.

> 3. Safari acted like Mozilla, but Opera didn't work with the new example 
> at all.

Opera has what I believe is a clear problem with DOM Level 2
compliance in this area.  Again, see below at **.

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

My intention was to say that set/getAttribute("aria:checked") would
work with each other, and would play nice together with CSS _provided_
you used e.g.

  [aria\:checked], [aria|checked]

in your stylesheets.  Looking at your example I think it was the CSS
selector which actually tripped you up.  That is, if I take your aria-
XHTML example, add namespace declarations and replace aria- with aria:
in the markup and the script, and aria- with aria\: _and_ aria| in the
stylesheet, it works out of the box.  I attach a patch which will make
exactly those changes for you to confirm.  See also pointer to example
given below.

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

I'm sorry I didn't include step-by-step instructions in the comparison
document, I was trying to keep the tables concise enough to be
comprehensible.  Those instructions followed a few messages later [1],
and the story there does not I think require deep understanding of DOM
details to execute.

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

*My view, as suggested in [1], is that if we go with aria: we will have
two phases:

 1) Only get/setAttribute will work cleanly and across the board, and
    CSS selectors will have to be duplicated (i.e. both \: and | will
    have to be used).  Documents written this way will work whether
    parsed as HTML or as XHTML, see e.g.
     http://www.w3.org/XML/2008/04/ARIA-Testing/leventhal_colon_html.html
     http://www.w3.org/XML/2008/04/ARIA-Testing/leventhal_colon_xhtml.html
    which are the _same_ file, served as text/html and
    application/xhtml+xml respectively.  These both work in Firefox 2
    and 3 and Safari 3.1.1 -- only the HTML version works in Opera 9.
    I have another example, based on one from iCITA, which I'm waiting
    for permission from the original copyright holder to publish,
    which works in all four browser families.

    Since for scripting that's exactly what would be used for aria-,
    and the CSS selector duplication is trivial to learn and execute,
    I don't see this as much of a challenge for users.

 2) If some form of namespace support for HTML is agreed going forward
    then we get phase 2, when, once such support is widely deployed,
    those who wish to can upgrade to using get/setAttributeNS and only
    aria|, and can even use different prefixes if they choose.  Pages
    using the strategy given in (1) above will still work.

Of course, if we never get namespace support in HTML, the (1) approach
will persist forever.  And also, people who work _entirely_ in the XML
world (that is, they don't care that some browsers will ignore their
application/xhtml+xml media type and treat their documents as HTML and
their pages won't render/behave properly) can adopt approach (2) from
the beginning.

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

ht

[1] http://lists.w3.org/Archives/Public/www-tag/2008May/0046.html

** I'm working on a detailed tabulation of DOM behaviour wrt attribute
manipulation across browsers, may get it out today, maybe not until
tomorrow.  But as noted above, with the exception of the real bug in
Opera, I don't think any of this actually _matters_ very much to the
design decision we have to take.
- -- 
 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)

iD8DBQFINZNPkjnJixAXWBoRAjHZAJ44bFnthWLmqjDD8lzDMFR+7WmL3gCfc0sQ
sKMF7hMWgxslvFmpMKtbsRA=
=B3uQ
-----END PGP SIGNATURE-----

Received on Thursday, 22 May 2008 15:42:37 UTC