Re: Next steps for the ARIA syntax discussion

On Thu, 29 May 2008 14:51:19 +0200, Henry S. Thompson <ht@inf.ed.ac.uk>  
wrote:
>> 1) For HTML we would need to introduce a number of "aria:*" attributes
>> in  the null namespace and for XHTML and SVG we would need to
>> introduce a  number of "*" attributes in the ARIA namespace.
>
> Assuming by 'we' you mean the HTML WG, _you_ don't have to introduce
> anything, you just have to acknowledge that xxx: is a general-purpose
> extension mechanism.

I meant that for this solution to work we end up with two sets of  
attributes. One set for HTML and one set for XML.


>> 2) For styling authors would need to use [aria\:*] in HTML and
>> @namespace  x "ARIA namespace"; [x|*] in XHTML and SVG
>
> Yes, and what's wrong with that?

It puts specification purity before authors and hinders adoption of XHTML.  
That's turning priority of constituencies around which is not a good idea.


>> 3) For scripting authors would need to use getAttribute("aria:*") /
>> setAttribute("aria:*", ...) in HTML and getAttributeNS("ARIA
>> namespace",  "*") / setAttributeNS("ARIA namespace", "*", ...) in
>> XHTML and SVG.
>
> No, as subsequent correspondence shows, _everyone_ uses  
> get/set/removeAttribute("aria:*",...)

No, that's wrong. If the XML markup uses xx:* with xx bound to the ARIA  
namespace, scripts written using get/setAttribute would fail horribly.  
Basing things on tagName instead of localName + namespaceURI is a very bad  
idea. I can't believe that the TAG is advocating such an approach.


>> The cost here is not on implementors, but authors. The design the TAG
>> advocates will make transitioning towards XML even more complicated
>> than  it already is. In the HTML WG we drafted a design principle
>> called "DOM  Consistency" which is basically guiding us in ensuring
>> that the above does  not happen.
>
> Curious - I see using aria: as self-evidently being the easiest
> possible way for authors to move from HTML to XML, because it's
> supported by XML already (see e.g. the SVG spec. about foo:
> attributes).

It's unclear to me what you mean by supported. Needing to transition to a  
different syntax for XHTML has been proven to be a very high cost. DOM  
consistency is trying to minimize that cost, you're trying to increase it  
for no clear gain.


>> 1) It simply says to use [aria|*] for CSS in the XML case but that
>> would  not actually work. It also requires an @namespace at rule.
>
> Of course you're right, I assumed that went without saying, what's the
> big deal?

You're hiding complexity tax on authors of your proposal. (This does not  
go for "our" proposal.)


>> 2) In a similar way it suggests that you can simply use aria:* in XML
>> but  that would also not actually work. It would give you a namespace
>> well-formedness violation as you have not declared xmlns:aria
>> somewhere in  scope.
>
> Ditto.

Again, you're hiding complexity tax on authors of your propposal. (This  
does not go for "our" proposal.)


>> 3) It says getAttribute() will function properly in the XML case but
>> that  would only work if the author of the page had an agreement with
>> the script  author about what prefix will be used which is something
>> you should not  rely upon.
>
> aria: is an alternative proposal to aria-, which relies on agreement
> between script author and page author.  So no difference between the
> two on this account.

aria- does not rely on that agreement actually, because aria- is the only  
thing that will work. If you're saying that in your proposal aria: is the  
only thing that will work you have not gained _anything_ at all other than  
making things more complex and breaking with the XML architecture pretty  
badly. Again, I can't believe the TAG is suggesting such a thing.


>> It does not mention setting the attribute
>> which is something  that's very important for ARIA (the whole idea is
>> that dynamic changes are  exposed to AT).
>
> Sure it does, it says use setAttribute("aria:...")

See above, that wouldn't work.


>> 4) It has a column "XHTML (as if HTML)" which is something that only
>> exists in some legacy specification theory and is not actually
>> implemented  as such by the four leading browser vendors.
>
> Sorry if that was a misleading label, but it was meant to describe
> what e.g. all the IE family do, and I think the surrounding text made
> that clear.

IE has no XHTML support at all, so again, it is misleading.


>> 5) It has the implicit suggestion there will be a million more
>> vocabularies that browsers will have to add support for in similar
>> fashion  as they have to support HTML, SVG, MathML, and ARIA. Given
>> the Web's  history so far it seems unwise to add so much complexity
>> for something  that might happen. Once it does happen, we can then
>> look at the  requirements and see how to solve it. Just like we do
>> with ARIA now.
>
> Clean separation of vocabularies is fundamental good design practice.
> Not making sensible provision for extensibility is a common flaw among
> naive system designers, but we can do better.

You've not proven that we indeed get the growth we expect. Given that  
aria- is only for a limited set of vocabularies anyway I think your  
statement rather misses the point.


>> 6) It suggests that SVG would not have to be changed if used the magic
>> of  namespaces. That seems higly unlikely because even then you will
>> have to  define the interaction with the semantics of various SVG
>> elements.
>
> That's an empirical assertion, which at least in the ARIA case appears
> to be false.  But the point about clean separation remains: when you _do_
> have a semantically transparent extension, namespaces give you an
> already-allowed means of deploying it.

It is not false in the ARIA case. ARIA should have no semantics for <desc>  
or <title> for instance. It would make no sense to turn <title> into a  
checkbox or even allow that.

It's also not a semantically transparent extension, so I think you're  
wrong.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 29 May 2008 13:05:05 UTC