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

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 the QA contact for the bug.

Received on Thursday, 30 September 2010 22:41:09 UTC