W3C home > Mailing lists > Public > public-html@w3.org > May 2008

Re: Next steps for the ARIA syntax discussion

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 29 May 2008 15:04:43 +0200
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
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>
Message-ID: <op.ubw2l5vv64w2qv@annevk-t60.oslo.opera.com>

On Thu, 29 May 2008 14:51:19 +0200, Henry S. Thompson <ht@inf.ed.ac.uk>  
>> 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  

Anne van Kesteren
Received on Thursday, 29 May 2008 13:05:05 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:31 UTC