RE: ISSUE-41: Creating a JavaScript DataGrid Widget

On Monday, May 03, 2010 3:36 PM, Jonas Sicking wrote: 
> On Mon, May 3, 2010 at 3:26 PM, Tony Ross <> 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.

> > 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.

> > 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.

The comparison is to "data-" as opposed to other proposed solutions to ISSUE-41. 
For example, with "data-" I can easily get the following to validate:

	<th data-sort="desc">

But now I haven't provided a prefix to distinguish my attributes from other libraries.
This is also tempting to do since it helps obtain a shorter attribute name.

> > > 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.


Received on Monday, 3 May 2010 23:20:50 UTC