[Bug 10916] Add a new <control> element to convey the common semantics of a script enabled UI control


--- Comment #3 from Shelley Powers <shelleyp@burningbird.net> 2010-10-01 13:17:23 UTC ---
I can't see the need for this control. And your use case, or example, doesn't
reflect what framework libraries use today. 

The div element is perfectly aligned for this type of use: it is a generic
element that is malleable. The very malleability you're defining for your
control element is something we already have with div. 

You mention about a consistent framework pattern: our use of the div element is
consistent. Don't take my word, look at how YUI, jQuery, and scriptaculous
implement a slider. In fact, if you take a look at how these three libraries
implement slider, you can also see that something like a singular control won't
work, because some of the libraries allow nested div elements to handle things
like a custom thumbnail image.

In addition, framework libraries rarely make use of data-* attributes. They
rarely need to because any attributes necessary are part of the API call that
maps the element to the custom UI. If they do, though, they do so
programmatically, not by adding them directly to the element. 

This approach doesn't eliminate the need for JavaScript, because this is not a
declarative element, with packaged behavior. It can't be accessible, not as is,
because again, there is no mapping between this blobby object, and the
appropriate API(s).

So we would still have to map JS functionality to the data, and we'd still have
to incorporate ARIA to make it accessible. But there could be a dangerous
implication, especially with accessibility, that it is one of the "new"
elements that doesn't require anything further in order to be accessible.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 1 October 2010 13:17:29 UTC