[whatwg] Controlling the UI on <input type=date>

[Scott González]

The only thing I've seen in a spec was CSS3 System Appearance, but it had
poor support and was ultimately removed.

2 years ago, I contacted people from Mozilla, Google, Microsoft, and Opera
about this, but I haven't seen any real progress. A few weeks ago, support
for <input type="week/month"> landed in Chrome Canary and this fiddle was
provided to show how to prevent the calendar from showing up:
http://jsfiddle.net/PPpUu/ This is clunky and doesn't even fully solve the
problem.

Here's one of the emails I sent after getting a response about device
vendors wanting to provide consistent UI/UX throughout the device (tying
their native calendar into controls like <input type="date">):

The problem is that no matter how consistent the UI/UX is, I want to
> opt-out because it will never be good enough. I want to customize the UI to
> look like my app, layer on additional functionality, etc. All of this is
> possible today without the new input types. However, once the new input
> types are used, this becomes more difficult. For example, enhancing a text
> field into a datepicker is really common, but you can't do this with a date
> field because of the new UI. I really don't think that JS implementations
> of these input types are ever going to die, no matter how good the native
> implementations work. There's just too much functionality that users will
> want that won't be possible because the APIs would be too large to spec.
> Falling all the way back to text fields works, but then we lose all the
> other benefits, such as the new attributes/methods, built-in validation,
> type-specific virtual keyboards, etc.
> So the end goal is still to have consistent UI/UX cross-browser, but not
> necessarily cross-site.


We get a lot of requests for jQuery UI widgets to work on the new input
types. However, as things are right now, all we can do is say no.


On Thu, Dec 6, 2012 at 3:46 PM, brenton strine <whatwg at gmail.com> wrote:

> It is currently difficult to control the visibility of the UI (e.g. little
> arrows, spinners, etc) on new input types like datetime, number, range,
> color, etc.
>
> It seems that many developers want to use the semantic attributes, but need
> to be able to hide the little arrows for various reasons, and so they are
> sticking with type=text (e.g. http://stackoverflow.com/q/11418289/925897
>
> ).
>
> Reasons developers might want to control the visibility of the UI:
> - developer has built their own datepicker/numberfinder/colorpicker/etc
> - developer wants to display just the values (as if it were type=text) upon
> printing, or when readonly, or when not active
>
> As browsers add support, there will likely be ways to control this using
> vendor-specific CSS, but not only will this vary from browser to browser,
> it will vary among the different input types. For example, in Chrome it is
> currently possible to hide the slider arrows on the number input:
>
> input[type="number"]::-webkit-inner-spin-button{
>     -webkit-appearance: none;
> }
>
> This kind of code is clearly going to be very difficult to maintain and
> keep up to date. I don't think a CSS solution is going to work. Has there
> been discussion here on an input attribute that controls the UI? Perhaps
> something like this:
>
> <input type="date" ui="false">
>