- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Sep 2010 22:41:07 +0000
- To: public-html@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10916
Summary: Add a new <control> element to convey the common
semantics of a script enabled UI control
Product: HTML WG
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: HTML5 spec (editor: Ian Hickson)
AssignedTo: ian@hixie.ch
ReportedBy: adrianba@microsoft.com
QAContact: public-html-bugzilla@w3.org
CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
public-html@w3.org
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 don’t
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 wouldn’t 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 don’t pass
validation and aren’t 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
don’t 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 author’s 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.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 30 September 2010 22:41:09 UTC