Charles,
Many thanks for your informative reply. You learn something every day! I had
always assumed because of...
<input type="text"/>
<input type="checkbox"/>
<input type="radio"/>
... that 'type' referred to the type of control. But as you point out with...
<input type="file"/>
<input type="number"/>
<input type="range"/>
...it is more about the type of the data. The HTML 5 spec seems quite
ambiguous. It says:
"The type attribute controls the data type (and associated control) of the
element"
...why is this? Why wouldn't we have...
<input type="boolean"/>
<input type="choice"/>
...instead of 'checkbox' and 'radio'? Then we could just call it the 'data
type' rather than 'data type (and associated control)'.
Regards,
Richard.
On 8/11/2011 3:00 PM, Charles Pritchard wrote:
> 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
>
>
