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

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

From: Richard Kennard <richard@kennardconsulting.com>
Date: Tue, 08 Nov 2011 15:21:13 +1100
Message-ID: <4EB8AE39.1020608@kennardconsulting.com>
To: Charles Pritchard <chuck@jumis.com>
CC: public-html-comments@w3.org

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)'.



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
Received on Tuesday, 8 November 2011 04:22:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC