- From: Charles McCathieNevile <chaals@opera.com>
- Date: Thu, 22 May 2008 09:03:35 +0200
- To: "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 Wed, 14 May 2008 18:22:26 +0200, Williams, Stuart (HP Labs, Bristol) <skw@hp.com> wrote: > At a relatively late stage in the development of the ARIA specification, > the TAG was invited to consider the question of the markup syntax for > ARIA states and properties, in particular the question of whether the > attributes encoding them in HTML- and XML-based languages should be > written 'aria-...' (hereafter "the dash approach") or 'aria:...' > (hereafter "the colon approach"). There seems to be some misconception here. The major problem I see is that the PF group proposed a non-null namespace for aria attributes except when they are used in HTML. The TAG's counterproposal is to use attributes with two names - in HTML the local name would include "aria:" which would not be the case in XML, and further proposed to constrain the allowed namespace prefix in XML (to be "aria"). I have an action item to calrify the PF proposal, so that the null namespace is always used, with aria- used as a grouping prefix to further disambiguate these attributes within the null namespace. I believe that actually meets the TAG's goal of preserving the namespace architecture, the implementors' goal of preserving the namespace architecture, authors' desire for some simple syntax they can generate with a low risk of error, and everybody's desire that ARIA works easily in HTML, SVG, XHTML, and anywhere else we think it would be useful. There are no other attributes I know of whose *local* name includes a colon, for the very good reason that this character introduces collisions with the namespaces spec. There are plenty of attributes whose local name includes a hypen, with SVG specifying about 70 including a number with two hypens in their names. SVG uses "font-" as a groupng prefix for about a dozen attributes (some of which have the same name but different meaning in different contexts) and various other grouping prefixes (fill-, stroke-) with no apparent ill effects. In both cases we are talking about attributes whose namespace is null. As in <foo xmlns:aria="" aria:aria-describedBy="#baz"> or createAttribute(null,'some-attribute') This is the same namespace that all the attributes in HTML have, and almost all the attributes in SVG (some linking and generic xml things are in a seperate namespace). In order to work with HTML, which is not namespace-aware, as well as XHTML, SVG, MathML and anywhere else we can see this being used, the null namespace is actually the only viable option. The alternatives involve either constraining the prefixes allowed (often suggested but there seems no clear justification for it here) or doing some serious magic to guess when we have real namespaces and when we have pretend namespaces. Both the alternatives create scenarios where copying between HTML and XML seems likely to introduce frequent errors that are difficult to trap. Given that these attributes all have a namespace, but that it is one which is already rather crowded, it made sense to introduce some mechanism to *further* disambiguate the attributes *within* their namespace. The "aria-" prefix for the attribute names is that mechanism. This seems like a reasonable design pattern. Anything that has to work with HTML and XML has to use the null namespace for attributes to preserve compatibility, but should try to avoid clashing with the myriad attributes already there. Some identifying prefix (anything legitimate in the names of attributes) seems like a good idea. (A hypen, given its use in ECMAScript to signify subtraction, may not be the best choice in an ideal world, but it is something that seems to come naturally at least to english speakers and there is precedent within DOM Styles for dealing with it in a simple enough way). (As a corollary, anyone developing an XML attribute not intended to be mixed with HTML should be advised to give their attributes a non-null namespace) > Based in part on a re-examination of the facts on the ground as regards > existing browser implementations, and in part on consideration of the > more general issue of language extensibility in the long term, (both > reported in _Syntax for ARIA: Cost-benefit analysis" [1]), the TAG has > arrived at the working hypothesis that the colon approach is both > technically feasible and strategically preferable. ... > Accordingly, we would like to invite you to consider three questions: > > 1) Are the facts about the current state of play with respect to how > current implementations work as set out in [1] reasonably > accurate; Reasonably. > 2) Is the cost-benefit analysis in [1] missing any substantive > considerations, particularly as regards the cost of changing > implementations given testing timeframes, product release cycles, > etc.; Yes. Several current implementations (including ours) are ready for shipping, and removing this now would throw schedules and planning, so it would need to be demonstrated that there was a major problem in the way this is implemented (as opposed to the specification). > 3) The TAG's working hypothesis is that "aria:" is both technically > feasible and strategically preferable, on the grounds that the long- > term benefits of a consistent approach to extensibility across all > the Web languages outweighs the short-term costs of making the > change at this time: > > (to the WAI PF WG): Would you consider specifying 'aria:' in the > next WD of ARIA; I am hopeful that the PFWG will have, later today when I get the work done, a proposal that clarifies that the namespace associated with the aria attributes is the empty string, in all cases, and that no local names have colons in them ever. I guess that is a no, from my part... > (to the implementers): Could you see your way to changing your > implementation/spec. to comply? We would only reluctantly do this if other implementors did it first, in order to preserve compatibility. We consider it a serious architectural mistake to introduce a colon into an attribute's local name, and we believe that using these attributes in the null namespace in fact carefully preserves the namespace mechanism as a whole. In short: We could in theory be dragged kicking and screaming to do this thing we regard as unbridled lunacy, but we're not in a hurry and it would cause some real damage to make this change. cheers Chaals > We would be happy to work with you to move forward quickly to a final > resolution on this question. > > Stuart Williams (co-chair) > for and on behalf of the W3C Technical Architecture Group (TAG) > > [1] http://www.w3.org/QA/2008/05/syntax_for_aria_costbenefit_an.html > -- > Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks > RG12 1HN > Registered No: 690597 England > > -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Received on Thursday, 22 May 2008 07:04:25 UTC