- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 May 2010 15:35:36 -0700
- To: Tony Ross <tross@microsoft.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Mon, May 3, 2010 at 3:26 PM, Tony Ross <tross@microsoft.com> wrote: > On Monday, May 03, 2010 11:51 AM, Jonas Sicking wrote: >> It sounds to me like the problems you are bringing up are exactly the same >> ones as there are with data-*. I.e. it doesn't seem like moving to the Y >> proposal solves or adds any problems, it just moves the same ones around. >> The only difference is that with Robs proposal you've removed the "data-" >> prefix, but all other problems remain. > > I should have been more clear. There are a few improvements the ASP.NET team liked: > 1) Shorter attribute names (5 fewer characters per attribute) I do feel the pain here, though it doesn't seem like enough of a problem to overhaul the language the way that many (all?) of the "distributed extensibility" proposals do. I suppose it's too late to change "data-" to "d-"... > 2) Clear separation between extended attributes and custom attributes added by the page author I'm not sure I understand the distinction. Is the distinction attributes defined by the UA vendor, vs. attributes defined by the page author? Or between attributes defined by a library author and attributes defined by the page author? Or something else? > 3) Requirement to use some sort of a prefix so libraries don't compete for un-prefixed attribute names Again, I'm not sure I understand this. It seems like basically all proposals use some sort of prefix. Some shorter and registry protected, some longer and uses collapsing mechanism (xmlns, CURIE) to turn them to a shorter prefix. >> What I prefer is a best effort solution. I.e. libraries and people do their best >> to avoid collisions. When collisions happen they will rarely end up being used >> at the same set of pages. And in the cases when they do end up in the same >> set of pages, people can deal. For example if two JS libraries become popular >> but started out using the same prefix, one of them can change. Or they can >> make the prefix configurable. > > I'm fine with putting the burden of conflict-resolution on the library itself. > Perhaps we can add text encouraging libraries to make their prefixes configurable. That sounds like a good idea to me. / Jonas
Received on Monday, 3 May 2010 22:36:33 UTC