This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10916 - Add a new <control> element to convey the common semantics of a script enabled UI control
Summary: Add a new <control> element to convey the common semantics of a script enable...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y
Depends on:
Reported: 2010-09-30 22:41 UTC by Adrian Bateman [MSFT]
Modified: 2011-01-25 16:22 UTC (History)
14 users (show)

See Also:


Description Adrian Bateman [MSFT] 2010-09-30 22:41:07 UTC

HTML5 introduces new elements for common semantics such as header, footer and
nav that allow content to be tooled more effectively. As we investigate how to
provide tools to help developers build the next generation of application, one
of the common scenarios we run into is the use of script frameworks to build
more sophisticated controls than the intrinsic form elements that are part of
the base language.

Many of the common script frameworks allow script based functionality to be
attached to arbitrary elements and <div> is commonly used. There is no
standardised way for editing UAs to identify these controls. The proposal here
is to introduce a new element, say <control>, that conveys the semantics of
a script defined control on a page. Development tools can provide see this
mark-up and provide a context specific editing experience.

The new element needs have no new behaviour in browsers, which should treat it
as a HTMLElement. It could potentially allow arbitrary attributes that dont
belong in the global attributes set, that are effectively ignored by the
browser but can be processed by scripts as part of the application markup.


data-* attributes provide in-band data to scripts and this allows framework
authors to leverage this while building HTML application frameworks. A
example of such a declaration is:

  <div data-control="framework.slider" 

There are a few issues with this approach:
 * The intent to create a control is diluted by use of a generic div element.
   This makes it hard for tools to detect that this is a control without having
   implicit knowledge of the specific script-based control framework.
 * The markup is verbose and without the help of tooling, is a lot to write and 
   difficult to read.
 * The attribute names are prone to collision with other utility providers.  
   This can be solved by adding a disambiguating prefix (e.g., jquery-, dojo-), 
   but that only makes the markup even more verbose.
 * Different controls may apply to different elements and the authors would 
   have to know what elements are applicable to the control they want to use 
   (e.g., in the JQueryUI framework, the Button control  applies to either the 
   button or input element as opposed to the Slider control  that applies to 
   the div element).

By making the control element that can include any arbitrary attribute as part 
of the standard, we can get a similar mechanism of providing data to scripts 
and that can be ignored by the browsers.  The example markup, using this 
proposal would look like:

  <control type="framework.slider"

In this example, we use the type attribute to identify the UI control and the 
set of attributes that are applicable to the element in this particular 

 * The intent to add a slider control is captured precisely.
 * The markup is concise and easy to author.
 * The element is intended for use by frameworks to declare controls and as 
   such collision with other utility providers will be rare.
 * This pattern encourages all framework control declarations to use the 
   control element consistently and hence there would be no question as to 
   which element is applicable for a given control.

In addition, tooling for parsing and generating declarative controls becomes 
simpler because control declarations wouldnt collide with preexisting elements 
and their usage patterns.

An alternative approach, which conforms to existing attribute standards is to 
use the data-* attributes on the control element.  But note that this has some
of the verbosity and duplication drawbacks of the original approach.

  <control data-type="framework.slider"

Browser support:

The major released/pre-release browsers already treat unknown HTML elements in 
a very consistent fashion and a framework could already leverage this behavior 
to build the proposed solution.  However, such HTML documents dont pass 
validation and arent guaranteed to work in the future.  In effect, acceptance 
of the proposal makes the usage of the control element future proof.


 1. Under section 2.2.2 Extensibility, add a new item as.
    * Authors can use the control element to declare framework controls that 
      can then be processed by client-side scripts or server-side site-wide 
      scripts.  Any data for these controls can be supplied via attributes that 
      dont collide with the global attribute set.  These attributes are 
      guaranteed to be ignored by the browsers.

 2. Under section 4 The elements of HTML, add a new subsection to include the 
    control element of type HTMLElement.  

      The control element represents a UI control that is usually processed by 
      a script belonging to a framework.  This element is treated as a regular 
      HTMLElement by browsers, but any attribute other than the ones in the 
      global attribute set are considered valid and ignored by the browser.


1. Positive Effects
 * Provides a consistent pattern for declaring framework controls in an HTML 
 * Captures the authors intent to declare a control much more clearly than 
   the data-* attribute method.
 * The resulting markup is concise and easier to author and read, compared to 
   the data-* attribute method.
 * Tooling for parsing and generating declarative markup with interactive 
   controls is simpler to implement.

2. Negative Effects
 * Introduces one more tag/element for browsers and validator to recognize

3. Conformance Classes Changes
 * Allow usage of control element to be conforming
 * Allow usage of arbitrary attributes outside of the global attributes set,
   on the control element to be conforming.
Comment 1 Jeremy Keith 2010-10-01 09:18:08 UTC
While I understand the use cases and the rationale, I don't think the desired functionality needs to necessarily be provided by an *element*. ARIA roles seem to be an existing mechanism for fulfilling the use cases outlined here.
Comment 2 steve faulkner 2010-10-01 09:50:05 UTC
how is expected that the semantics of these widgets and their states & properties are to be exposed to accessibility APIs?
Comment 3 Shelley Powers 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.
Comment 4 Maciej Stachowiak 2010-10-02 05:31:18 UTC
Would browsers or any other HTML consumer (e.g. search engines) do anything in particular on encountering a <control> element rather than a <div>? If so, what would be the effect?
Comment 5 Jonas Sicking (Not reading bugmail) 2010-10-02 05:40:47 UTC
Same question also for a AT HTML consumer such as a screen reader.
Comment 6 Adrian Bateman [MSFT] 2010-10-04 17:36:29 UTC
The main use case is for editing tools. Browsers wouldn't be expected to do anything with the element - on the contrary they should be discouraged from doing anything special with the element.

We expect that script libraries would provide the functionality and accessibility concerns are addressed in the same way they are today with a <div> that happens to turn into a control. There is no change there.

The main problem we have found is that it is impossible for development tools to identify elements that are intended to have the semantics of a control. We think it's important to be able to provide this kind of functionality in a conforming document that validates. Two levels of functionality are possible: a generic experience without any knowledge of the library and a more sophisticated experience when the tool understands the controls available in a given library. Having an element allows to solve for both.

One option used today is to have JavaScript wire up the behaviour by having a function call where the element ID and other parameters are passed. This is hard to tool even in the case where the user agent understands the available controls. It requires parsing the JavaScript and recognising the appropriate method calls. Having a declarative approach for defining the parameters significantly reduces the complexity of creating an editing experience for the control values.

Since the latest beta/release of the main browsers are interoperable for generic elements, adding a new element in this way should be compatible with current behaviour.

It is possible search engines might choose to draw inferences from pages with <control> compared to the same content in <div> or <span>.
Comment 7 Maciej Stachowiak 2010-10-04 17:58:48 UTC
(In reply to comment #6)
> The main use case is for editing tools. Browsers wouldn't be expected to do
> anything with the element - on the contrary they should be discouraged from
> doing anything special with the element.

What are some specific things an editing tool could do with the knowledge that an element is a control, but without knowing anything more specific about its behavior or semantics (since those are presumably still specific to individual scripting libraries)?

Or, if this is meant to be used with a specific scripting library known to the editing tool, rather than generic to any scripting library, it seems like the scripting library and editing tool could come to a private arrangement on how to convey this info (e.g. with data-* attributes or specific use of class names).
Comment 8 Ian 'Hixie' Hickson 2010-10-12 07:26:12 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Rejected
Change Description: no spec change

It seems that there are two basic approaches for this already specified, which should already be usable for the given use case of a development environment being careful not to break pages during editing:

 * ARIA: Tools should never fiddle with elements that specify ARIA roles and states, _especially_ control-related roles.

 * XBL: The long-term solution for this is for pages to use regular HTML form control elements like <input>, using whatever the closest element is to what they are trying to do, and then to use XBL to replace the behaviour and rendering of the control with the custom look and feel desired (with ARIA in the shadow tree, if ATs expose the shadow tree rather than just exposing the original control).

In addition, I would add that any development tool that removes or indeed fiddles in any way with elements that have data-* attributes specified or event handler attribute specified is really asking for trouble. This is naturally a per-vendor decision, and thus out of the scope of the spec, but I really would be disappointed in editing tools that change _any_ of the markup except what the user actually said to change. There's really no reason an editor can't round-trip all the data in the page. After all, there's no way to know what's truly important, especially if the page is one that includes hand-authored components, scripts, or components inserted by other tools.
Comment 9 Marco Ranon 2011-01-25 16:22:52 UTC
The Accessibility Bug Triage Team don't think that this is a task force priority and neet the a11ytf keyword, because we agree that ARIA is sufficient.