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

On Fri, 18 Apr 2008 10:13:53 +0200, Henry S. Thompson <ht@inf.ed.ac.uk>  
wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Anne van Kesteren writes:
>
>> Your solution also doesn't solve any of the problems:
>>
>>  * Authors cannot use setAttribute() and getAttribute(). Instead they
>> have  to write a set of custom methods. This gives increased authoring
>> cost.
>
> I have said several times there is a cost.  It's a small cost.

The dash is implemented in Opera 9.5, Firefox 3 and IE8, and it is used by  
several JS libraries. Changing to the colon now would be a non-trivial  
cost considering that those browsers are about to ship. I also don't see  
what the benefit would be.


> The
> proposed aria- alternative has a cost for authors too.  I think it's a
> high cost, and it affects _all_ ARIA users, not just those writing
> script.

What's the cost of using the dash?


>>  * Authors cannot style these attributes properly accross clients.
>
> Is there any styling requirement for these attributes?

Yes, for instance in order to have different styling for checked and  
unchecked checkboxes.


> Suppose IE8
> supported [aria\:...] selectors, would that make a difference to you?

IE7 already supports [aria-...]. Moreover, even if IE8 supported  
[aria\:...] and working in IE7 was not a requirement, it would still  
require authors to duplicate their rulesets and use namespaces in CSS in  
order to work in both HTML and XHTML.


>>  * If at some point in the future we want to give meaning to the colon
>> in  HTML5 we couldn't do it because this solution for ARIA would be
>> broken by  such a decision.
>
> Not at all -- it's a forward-compatible solution.

Suppose authors would use the colon in text/html documents and their style  
sheets and scripts expect no-namespace attributes. If the HTML parser is  
changed to make special treatment to the colon (like in XML) then those  
pages would stop working in UAs that implement the new HTML parsing rules.


>>  * This solution introduces two different sets of attributes rather
>> than  one. I don't think that's architecturally sound and I think it
>> will be  confusing for authors trying to switch from HTML to XHTML. (I
>> don't expect  people to use the abstract methods they have to make
>> themselves.)
>
> I don't understand -- it specifically introduces _one_ set of
> attributes, namely aria:...,

No, it introduces two sets:

   1. localName: "a:foo", namespaceURI: null
   2. localName: "foo", namespaceURI: "http://www.w3.org/2005/07/aaa"

You'd get an attribute in the former set from parsing text/html or using  
setAttribute. You'd get an attribute in the latter set from parsing XML or  
using setAttributeNS.


> instead of two, i.e. aria-... and aria:...

Opera 9.5, Firefox 3 and IE8 only support aria-.


>>  * This solution would violate several HTML design principles[1] as
>> well.  Most importantly "DOM Consistency",

The colon would indeed violate DOM Consistency.


> [...]

(I think it's more useful use of my time to focus on the DOM Consistency  
principle, since that's the core problem with the colon.)


>> and "Avoid Needless Complexity".
>
> Two sets of attributes, with complex "when to use which" rules, are
> simpler than one?

There are no "when to use which" rules; just always use aria-.

-- 
Simon Pieters
Opera Software

Received on Friday, 18 April 2008 12:39:12 UTC