Higher level of abstraction for 'input type='

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Higher level of abstraction for 'input type='

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

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

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?

Regards,

Richard.


Reply | Threaded
Open this post in threaded view
|

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

Charles Pritchard-2
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

Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

Charles Pritchard-2
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 <[hidden email]> 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
>>
>>
>
>