- 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>
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:04 UTC