This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
SUMMARY 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. RATIONALE 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" data-maxvalue="100" data-minvalue="0" data-smallchange="1" data-largechange="10" data-onchange="sliderValueChanged"> </div> 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" maxvalue="100" minvalue="0" smallchange="1" largechange="10" onchange="sliderValueChanged"> </control> 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 framework. * 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" data-maxvalue="100" data-minvalue="0" data-smallchange="1" data-largechange="10" data-onchange="sliderValueChanged"> </control> 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. DETAILS 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. Description 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. IMPACT 1. Positive Effects * Provides a consistent pattern for declaring framework controls in an HTML application. * 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.
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.
how is expected that the semantics of these widgets and their states & properties are to be exposed to accessibility APIs?
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.
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?
Same question also for a AT HTML consumer such as a screen reader.
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>.
(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).
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: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: 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.
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.