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

I always get fuzzy here but, element.type != element.getAttribute('type') when the type has no implemented associated control.





On Nov 7, 2011, at 8:21 PM, Richard Kennard <richard@kennardconsulting.com> wrote:

> 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
>> 
>> 
> 
>

Received on Tuesday, 8 November 2011 04:48:23 UTC