RE: Next steps for the ARIA syntax discussion

Forgive me for chiming in.
Two or three years have gone into ARIA-related discussion and development.
Everyone had a chance to contribute to the spec.
Why do we need to go back in time right now when IE8, Firefox, Safari and
Opera seem to have agreed on incorporating existing ARIA syntax into their
browsers?
V


-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf
Of Henry S. Thompson
Sent: Thursday, May 29, 2008 5:51 AM
To: Anne van Kesteren
Cc: www-tag@w3.org; public-html@w3.org; public-xhtml2@w3.org;
wai-xtech@w3.org
Subject: Re: Next steps for the ARIA syntax discussion


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

Anne van Kesteren writes:

> On Wed, 14 May 2008 18:22:26 +0200, Williams, Stuart (HP Labs,
> Bristol)  <skw@hp.com> wrote:
>>   3) The TAG's working hypothesis is that "aria:" is both technically
>>      feasible and strategically preferable, ...
>
> aria:* creates an inconsistency between HTML and XHTML that we don't 
> have  with aria-*:
>
> 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.

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

> 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:*",...)

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

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

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

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

> 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:...")

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

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

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

ht

[This reply in response to the request in
http://lists.w3.org/Archives/Public/www-tag/2008May/0180.html]
- --
 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)

iD8DBQFIPqbHkjnJixAXWBoRAmJrAJ9XOQdurVevBxhXt8WQFfrcLGmNtQCeNeSR
FJiRaYAPv7TmTSgtnYYML2Y=
=c28F
-----END PGP SIGNATURE-----

Received on Thursday, 29 May 2008 17:14:20 UTC