Re: ISSUE-41: Creating a JavaScript DataGrid Widget

On Mon, May 3, 2010 at 4:20 PM, Tony Ross <tross@microsoft.com> wrote:
> On Monday, May 03, 2010 3:36 PM, Jonas Sicking wrote:
>> 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-"...
>
> I agree with not wanting to overhaul the language.
> Really I'm just looking to let something like the following validate:
>
>        <th asp-sort="desc">
>
> This should require zero changes to the parsing algorithm and resulting DOM.
> Unless I misunderstood, this is what Rob's proposal Y enables.

I guess I was a bit over dramatic with "overhaul the language" :). It
doesn't mean any changes to implementations, but it does change a lot
of other aspects. It does change what is "valid HTML" (though the
usefulness of that term is debatable), and it does change logistics in
that now HTML is run through a registry in addition to a working
group. And it also creates the problem you mentioned earlier of people
rushing to register short prefixes, not to mention that we'll probably
end up loosing good names to defunct projects and companies.

>> > 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?
>
> The distinction is between attributes defined by a library author and attributes defined by the page author.

Though arguably the data-foo-bar vs. data-bar distinction does that
already. At least if people play nice. And if people don't play nice
there is nothing preventing page authors using attributes named
asp-backgroundcolor.

>> > > 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.
>>
>
> Great. Does anyone disagree with this?
> If not, I think this point would be good to include in Rob's proposal Y.

I think we should do this apart from any of the decentralized
extensibility issue entirely. The spec already recommends libraries on
how they should use data attributes. Seems like it could go in as part
of that.

/ Jonas

Received on Monday, 3 May 2010 23:43:45 UTC