- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 3 May 2010 11:50:33 -0700
- To: Tony Ross <tross@microsoft.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Mon, May 3, 2010 at 10:40 AM, Tony Ross <tross@microsoft.com> wrote: > I want to share a JavaScript framework oriented scenario for ISSUE-41 that I received from the ASP.NET team at Microsoft. They've been investigating how they can define HTML5-friendly controls that are both easy to use and will validate. > > ---------- > > Use Case - Creating a JavaScript DataGrid Widget > > Goals: > * Support Progressive Enhancement - Start with a normal HTML table and use custom attributes and a JavaScript library to make the table sortable. > * Support applying multiple widgets to the same table - Avoid colliding with custom attribute names used by another widget (created by someone else). > * Terse Syntax - Avoid repeated typing of long, custom attribute names. > > For example, you might start with an HTML table that looks like this: > > <table id="productOrders"> > <thead> > <tr> > <th > data-myajaxlibrary-sort="desc" > data-myajaxlibrary-datatype="currency" > data-myajaxlibrary-hidden="false">Name</th> > </tr> > ... > > And then use JavaScript like the following to create the DataGrid: > > var dataGrid = new DataGrid("#productOrders"); > > The trouble with using an attribute like "data-myajaxlibrary-datatype" is: > > 1) The attribute name requires a lot of typing (realize that you need to repeat these attributes for each table column). > 2) There is no guarantee that there won't be a conflict with attribute names used by another widget. For example, multiple JavaScript frameworks would be tempted to use the attribute names like data-datagrid or data-widget-datagrid. > > ---------- > > Given their goals, they currently believe something along the lines of Rob's proposal Y (http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple) could work for them. > > However, they have some feedback there as well: > > 1) What process determines who gets a particular registered prefix? > - If this is simply first-come-first serve, desirable prefixes may be registered without an intent to actually use them. > - This could lead to a rush to register all potentially desirable prefixes, especially the short ones. > > 2) What's the guidance for resolving collisions? > - 3rd-party extensions (built on top of the core framework) are the primary concern, especially as they try to pick short prefixes. > - Supporting loading multiple versions of the same library also presents a challenge. > > Thoughts? 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. So far I haven't heard of any good bullet proof namespacing mechanisms. Either you end up with a registry where everyone fights over the good names and you end up problems like unregistered uses and x-not-so-temporary names. Or you end up with collision proof names which are way too long and end up with painful mechanisms to try to shorten them (xmlns, CURIE). 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. Or worst worst case, in the very unlikely event that a web developer is *forced* to work with two stubborn libraries that use the same prefix, *and* that refuse to either change prefix or make it configurable, the developer can always modify the JS code in those libraries. But it seems extremely unlikely to get to that point. / Jonas
Received on Monday, 3 May 2010 18:51:27 UTC