Re: ISSUE-41: Creating a JavaScript DataGrid Widget

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