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

ISSUE-41: Creating a JavaScript DataGrid Widget

From: Tony Ross <tross@microsoft.com>
Date: Mon, 3 May 2010 17:40:55 +0000
To: "public-html@w3.org" <public-html@w3.org>
Message-ID: <0BE6C9F65034784C8E2852B6F303DA173B53A5F7@TK5EX14MBXC112.redmond.corp.microsoft.com>
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?

-Tony
Received on Monday, 3 May 2010 17:41:35 UTC

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