[Bug 10916] 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

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |WONTFIX

--- Comment #8 from Ian 'Hixie' Hickson <ian@hixie.ch> 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:
   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.

-- 
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 Tuesday, 12 October 2010 07:26:15 UTC