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

Re: [whatwg] Forms-related feedback

From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
Date: Wed, 16 Jan 2013 10:03:06 +0100
Message-ID: <50F66CCA.1060508@bauglir.com>
To: whatwg@lists.whatwg.org

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

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.

I can see datetime-local implemented in Chrome nightly and I'm glad I 
can stop using 2 separate controls (date, time).

Overall design can be solved using pseudoclasses for browsers native 

Received on Wednesday, 16 January 2013 09:03:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:52 UTC