Re: Next steps for the ARIA syntax discussion

On 29 May 2008, at 8:51 AM, Henry S. Thompson wrote:

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

It impedes migration of applications from HTML to XHTML.
>
>> 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:*",...)

References, please?  In namespace-aware processors, why would
get/setAttributeNS not be used?

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

We're not talking about authors migrating from HTML to XML.

Authors will want to migrate from HTML to XHTML without thinking
that they are doing something new.

And namespaces is something new in that regard that has already
been around once unsuccessfully in terms of popular adoption.

The is the 'I have a hammer, it must be a nail' mentality.
Not reflective of author perceptions.

Once we have intergrated namespaces into the language of the Web
that *is* HTML, we can go about using it to blend in appliques
to the base language.  But WAI-ARIA shouldn't have to wait for
that, when there is a clear path that breaks nothing in the
namespace architecture.

As one of our leaders said "we just want to do something that
works."  Please stop stopping us.
>
>> 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.

Can't follow.  Do you mean that there would be a namespace declaration,
or that the pages would not be well-formed?

In any case, the markup breaks Namespaces by this evidence.  Why go  
there?

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

This is wrong.  They are not comparable.

aria:foo matches PrefixedName

aria-foo matches UnprefixedName

http://www.w3.org/TR/2006/REC-xml-names-20060816/#ns-qualnames

They are not peers in a world where Namespaces in XML has already been
defined.

'aria-' does not require a special agreement between script author
and page author, other than both follow the specification.

'aria:' requires a special escape from recognition as a PrefixedName
which could be put in a specification, but pollutes Namespaces practice
with unnecessary exceptions.  So it's not the same thing.

You persist in the misinterpretation that aria- is some sort
of namespace prefix.  It's not.  It's a shared substring of atomic
local-name tokens.  Compare with svg:fill-*

http://www.w3.org/TR/2003/REC-SVG11-20030114/attindex.html

WAI-ARIA could have ridden on namespaces, and *would have* if
namespaces were ready for prime time.  But they're not.

http://www.w3.org/2007/11/07-TechPlenAgenda#html

It's not a case of HTML vs. everything-X.
Anyone wanting to use XHTML wants it to be a lot like HTML.
Same old attributes, same old DOM programming model.

So at present we have HTML WG and XHTML2 WG grunting together
saying "we have opinions as to how it should work, but by
all means it should work the same."  Rarely are these two
groups in such synchrony.

And SVG is still too early to call, but it could well fall
in line and prefer 'no-namespace' status for aria-foo attributes.

That would leave all the W3C languages with root document
potential of any magnitude at all covered.

With the help of our browser-implementer participants, we have
found, through what you term "the  'aria-' approach," a way
to not need namespaces in the short term and not poison the
path for others using namespaces later.

'aria:' loses on both counts.  We need to refresh the browser
stock before our applications run.  That's a fatal, not a fungible
flaw. To boot, it poisons the path from Namespaces in XML as it stands
today to an evolved and truly pan-Web framework for extension and  
evolution.

Al

>> 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 19:26:09 UTC