On 11/7/11 5:31 PM, Richard Kennard wrote:
Hello everyone,
Based on my experiences developing a UI library over the past few years, I have
blogged an idea for HTML:
http://blog.kennardconsulting.com/2011/11/should-htmlnext-have-higher-level-of.html
In summary: could we introduce a higher level abstraction over 'input type='
such that the developer specifies the *data* type, not the widget type, and
the device renders the most appropriate widget? This would stop the current
proliferation of JavaScript-based widget libraries that are all duplicating
each other's effort.
This is the current practice. input type= and ARIA role="input" are the
high level abstractions
and vendors are free to create OS and UA implementations of various
types at their leisure.
This does not stop authors from creating their own widgets. Authors may
have various reasons to author a widget, presentation being one of them.
Webkit and Mozilla include various CSS pseudo-selectors to help authors
re-use native widgets with some presentational flexibility. That
experiment is also quite difficult. The Component model discussions on
Web Apps are an extension of that exploration.
I understand HTML 5 is introducing a date picker. But this is the thin end of
the wedge. There are always going to be many more possible widgets than the
HTML specification can support (e.g. spinners, sliders, color pickers etc).
<input type="[anything]"> falls back to <input type="text">, the default
style of <input>.
ARIA role="input" simply signals an input, nothing more.
Example:
role="color input" will fall back to "input", as type="color" will fall
back to "text".
Neither require "color" to be included in a specification.
What if we could leave this choice to the browser? So that browsers could
compete offering the best widget implementations to suit their target device,
accessibility requirements etc?
I'd prefer to leave the choice to the participants, whether it's a user
and author, or two speakers in conversation.
After they make their choice, then it's a great thing to have browsers
offer an alternative.
My best (current) example is <input type="file">. It's the best because
it's non-controversial, unlike input type="text".
With input type="file" it is now accepted practice to hide the input
field altogether and simply forward click events into the element.
That's what I want to see for all <input> types. The author and user can
decide how things are presented, and the DOM includes some usable
reference about those decisions.
It's great to have UA involvement in this, and to have native UA widgets
as a support mechanism
input type="range" role="slider" is a good area to watch the dynamic in
play. <audio controls> is another.
-Charles
