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 12:53:10 UTC