W3C home > Mailing lists > Public > public-html@w3.org > May 2010

Re: ISSUE-41: Creating a JavaScript DataGrid Widget

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 3 May 2010 15:35:36 -0700
Message-ID: <y2u63df84f1005031535ra246063crc0b6c5811f50d92b@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:02 UTC