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
controls.
BK.
