W3C home > Mailing lists > Public > public-html-comments@w3.org > November 2011

Re: Higher level of abstraction for 'input type='

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 07 Nov 2011 20:00:40 -0800
Message-ID: <4EB8A968.1080208@jumis.com>
To: Richard Kennard <richard@kennardconsulting.com>
CC: public-html-comments@w3.org
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
Received on Tuesday, 8 November 2011 04:01:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 November 2011 04:01:16 GMT