Re: State and Status of WAI-ARIA approach to host-language embedding

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

Simon Pieters writes:

> On Thu, 17 Apr 2008 15:33:57 +0200, Henry S. Thompson <ht@inf.ed.ac.uk>
> wrote:
>
>> Michael Cooper writes:
>>
>>> . . . I have prepared a summary document [0]
>>
>> I too have found this very helpful, thank you.
>>
>> I have spent some time exploring the test case helpfully provided by
>> Henri Sivonen [1].  I discovered that at least some of the apparent
>> failures of the :-based markup versions therein did not arise from the
>> material under test, but from accidental properties of the text
>> matrix.
>
> It's not really clear to me what it is that you discovered. It seems
> to me  that you have tried to work around the differences that the
> colon imposes  and thus demonstrated that different code paths is
> needed.

I did that as well, but what I was referring to was the "Script did
not run" reports against Firefox, which had nothing to do with :
vs. -.

>> More generally, it appeared to me that if a bit more effort were
>> expended, the cost of the :-based approach could be reduced, thus
>> perhaps shifting the outcome of what we all agree is a cost-benefit
>> tradeoff.
>>
>> Accordingly I produced a new version [2] of Henri's test, testing only
>> my more elaborate :-based approach, which produces better results
>> (live version [3]) (frozen snapshot w. low-res thumbnails if the live
>> version has expired [4]).
>
> Using the colon means that UAs and authors have to support two sets of
> ARIA attributes -- one set of namespaced attributes, and one set of
> no-namespace attributes with colons in their local names.

How so?  The whole point of my exploration is that a _single_ entry
point (in my examples, spelled 'getARIAttribute'), can be used in all
contexts.


> Having aliases is an indicator of bad design.

Exactly -- having aria-role and aria:role as aliases is bad design.
Seriously, we are stuck with a complex legacy, and _any_ resolution
has crufty aspects.  The question is, which cruft is preferable.

> Moreover, it will be seriously error prone for authors, since
> attributes from either set can appear on the same node in both HTML
> and XML documents:
>
> Case 1: HTML document:
>
>    <div a:foo='true'>
>
>    div.setAttributeNS('http://www.w3.org/2005/07/aaa', 'foo', 'false');
>
> Case 2: XHTML document:
>
>    <div a:foo='true'>
>
>    div.setAttribute('a:foo', 'false');
>
> Case 3: either HTML or XHTML document:
>
>    <div>
>
>    div.setAttributeNS('http://www.w3.org/2005/07/aaa', 'foo', 'true');
>    div.setAttribute('a:foo', 'false');

Sorry I didn't make clear in the original post that the cost of my
proposal is that you _don't_ use the standard accessors.  You _always_
write

    setARIAttribute(div,'foo','true')

>
>> The crucial observation about these results
>> is that in every case Javascript access to :-based ARIA attributes
>> succeeded, and in all but the Safari case (which I presume could be
>> fixed, I just couldn't get access to a Safari + debugger installation
>> in the time available) the Javascript setting of :-based ARIA
>> attributes succeeded.
>
> It fails in Safari because your "XML" check is actually bogus:

Do you mean there _is_ no test in Safari which will correctly
distinguish an HTML from an XML parse?  That _would_ be a problem. . 

> Per HTML 5, elements that are inserted in the document by the HTML
> parser  are put in the XHTML namespace, and hence, you get the "XML"
> codepath for  HTML documents in UAs that follow HTML 5.

Are you suggesting that Safari is already implementing HTML 5 rules?

> No matter how you try to spin it, even if you get the "XML" check
> right, a  node can have both attributes set at the same time

Not if you just use the uniform getter/setter.

> The right way to solve this is to only have one set of attributes

For sure.

> and that means not using the colon (given the constraints that we
> can't change the HTML parser, nor the XML parser, nor DOM Core, and
> that it should work the same in existing browsers).

Or using a setter/getter pair which use the appropriate single
attribute in each case.

>> CSS selection succeeded everywhere except IE,
>> where it failed across the board -- I presume this could be fixed for
>> IE8, given what I understand, but again I didn't have access to a
>> suitable IE8 installation.
>
>     p[a\:foo], p[a|foo] { background:lime }
>
> IE doesn't support namespaces in CSS, and so, the entire ruleset is
> dropped. However, even if you did:
>
>     p[a\:foo] { background:lime }
>     p[a|foo] { background:lime }
>
> ...IE7 wouldn't apply the first ruleset because attribute selectors
> with  colons don't work in IE7. (Attribute selectors without colon
> work fine in  IE7.) But, even if attribute selectors with colon did
> work in IE7, you'd  still have to duplicate all your ARIA rulesets in
> CSS, and that's bad  compared to not having to do so:
>
>     p[aria-foo] { background:lime }

Agreed.  But I doubt seriously that there will _be_ many aria/css
rulesets.  My understanding was that the ARIA use cases are primarily
AJAX-oriented, so the DOM access issues are the important ones.

> I think we can't come to useful conclusions from your script since it
> doesn't work correctly in UAs that implement HTML 5

Please clarify which browsers those are, and why it _can't_ work in
them.  I also note that HTML 5 is not baked yet. . .

> nor does it cover the case when an element has both attributes at
> the same time.

I addressed this point above.

> However, even ignoring that, 16 lines of code and the resulting
> indirection elsewhere in the code is bad compared to no additional
> 16 lines of code and no indirection elsewhere in the code.

For sure.  And using aria- in some documents and aria: in others is
compared to using aria: everywhere is bad too.  We're talking about
tradeoffs, not absolutes.

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)

iD8DBQFIB3TwkjnJixAXWBoRAivfAJ46Fycnzhicv8WkAy10eiiZdB8BGACdFwlH
L5GTFbZI1np+UHC8I+qa39k=
=sPil
-----END PGP SIGNATURE-----

Received on Thursday, 17 April 2008 16:05:11 UTC