On Wed, Jan 16, 2013 at 1:03 AM, Bronislav Klučka <bronislav.klu...@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