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 <[email protected]>
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
>>
>>
>
>
