- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 19 Oct 2007 13:41:49 +0300
- To: T.V Raman <raman@google.com>
- Cc: ian@hixie.ch, public-html@w3.org, www-svg@w3.org
On Oct 19, 2007, at 12:46, T.V Raman wrote: > I dont believe we need go down the ugliness of inventing a second > namespacing mechanism because some dont like the current one; I agree we shouldn't invent a second namespacing mechanism. I think we should do ARIA without a technical namespacing mechanism at all and only use a naming convention for spec organization without the parsing and DOM layers knowing anything about it. It's not about not liking the current XML namespacing mechanism. It's about the current XML one being unsupported in already shipped text/ html implementations. It follows that introducing it now to text/html would create a scripting discrepancy between legacy and new browsers. We don't want that, so we are stuck with no Namespaces in XML-style namespaces in HTML. We want DOM and scripting consistency between HTML and XHTML, so the legacy leaks to XHTML as well. We want browsers to be able to use the same DOM reading code for SVG, too, so the legacy leaks to SVG as well. The legacy is very powerful and I don't think there's a payoff from fighting legacy that would outweigh the cost of discrepancies with the legacy. > --- the current namespacing mechanism wont go away, and the world > will be left to contend with twice the ugliness that pervades at > present The Namespaces in XML processing layer can't be taken out from between the XML 1.0 layer and the DOM layer. It is too late for that. However, we can let the Namespaces in XML layer remain latent and avoid using it for new attributes. No actual technical doom or gloom in Web UAs will arise from putting the ARIA attributes in the per-element no-namespace partition of elements on the XML side. We know that XHTML and SVG don't have pre- existing attributes that start with "aria-", so there won't be actual collisions as far as Web languages are concerned. In theory, a non- Web language out there could collide with this scheme if you tried to use the "aria-" naming scheme on a theoretical non-Web language. However, since we are working on Web specs, I think we should optimized for actual Web language usage instead of theoretical non- Web language usage. (This is exactly where xml:id went wrong. The practical approach would have been declaring that the attribute id is always and ID and if someone out there had a non-Web problem with that, it would have been a non-Web problem. Now the fallout from xml:id is seen in Web specs and implementations.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 19 October 2007 10:42:10 UTC