W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Forms-related feedback

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 16 Jan 2013 03:01:14 -0800
Message-ID: <CAAWBYDAfj0y_SJ8+va_LOoDP7tgkeW3BGoajA7yxHrb77K2zOw@mail.gmail.com>
To: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Cc: WHATWG <whatwg@lists.whatwg.org>
On Wed, Jan 16, 2013 at 1:03 AM, Bronislav Klučka
<Bronislav.Klucka@bauglir.com> wrote:
> On 16.1.2013 8:23, Jukka K. Korpela wrote:
>> Since the use cases are rare, is it better to force browser vendors to
>> develop code to implement it, in their own ways, than to let various
>> software developers set up libraries for it? Since the browser
>> implementations would, with practical certainty, lack adequate
>> localizability (according to page language) and customizability, the HTML
>> construct would not be used much.
>>
>> Authors, or their employers and clients, don't want just "a date and time
>> picker" for example. They want a picker that suits their overall design. I
>> don't think this will change anytime soon. Pages now use a wide variety of
>> date pickers. While <input type=date> might be useful for testing and quick
>> prototyping, and might be used by functionality-oriented authors who don't
>> care much about look and feel, <input type=datetime> would rarely be used
>> even for such purposes, so it would be an undue burden on browsers
>
> You are wrong here, while you may be right in case of web pages, for web
> apps native components makes more sense (for me at least). minimalistic,
> functional design without buch of libraries solving 1, 2 issues each of
> them. In such case native controls are/maybe preferable. There is a lot of
> authors application code, why download another code for datepicker, time
> picker, datetime picker, slider (range), etc.

Strongly agree.  I think any arguments that sites will refuse to use
the native controls because they don't match the site's theme are
countered by the observation that most sites using JS-library
equivalents today still don't theme them very well, or at all.  I
usually just see a very plain mostly-white calendar, using whatever
the default color scheme is for the given library.

It also ignores the fact that us devs are mostly lazy, and love being
able to write a simple element instead of piping in a library just to
do a crappy calendar.  ^_^

~TJ
Received on Wednesday, 16 January 2013 11:02:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT