Material-design-lite: Support for input type date as a textfield with floating label

[jgoux]

Hello,
when using a input of type date with the textfield, the input floating label and the date pattern are mixed. And the input label doesn't float on focus.
Here is a screenshot :

[surma]

For now, text fields are exactly that: _text_ fields. Date pickers are also very hard (if not impossible) to style, so we can’t really do much with the browser’s native implementation. That said, a proper MD date picker seems to have a very high demand so I’m sure we’ll try to come up with something soon.

As an interim solution, I’d recommend you either use the unstyled browser implementation or use a text field with an appropriate pattern attribute.

[Garbee]

Watch issue #782 for time/date picker support. (+1's aren't necessary, we get it, people want them and the spec defines them.)

[nicolasgarnier]

Thanks for your repport @jgoux,

I'm closing this in favor of #782 because this is out of the scope of text fields (who only support text input). We'll work on a date picker instead.

[jgoux]

Thanks for the replies.
I was suggesting that because in term of accessibility, these kind of html5 inputs (number, email, date...) have custom keyboards on mobile and tablet, so it would be interesting to support them.
Of course the date picker component will be best for the input type date, but what about the input type number, or the input type email ?
As a regular user of angular-material, where they are supported, I find them really useful. You can for example see the "submission date (date)" or the "hourly rate (number)" input here: https://material.angularjs.org/latest/#/demo/material.components.input

[surma]

This is an obvious enhancement, esp. regarding a11n. It will most likely be on the road map for the next feature release.

[Garbee]

Email is normal text. Number, honestly most of the time you should use a normal text input with the appropriate pattern you need. The number type leads to pretty strict output (i.e. no leading zeros) which can lead to "It should work, but because of edgecases in data it doesn't." If you use the right pattern setup, mobile keyboards will respond well to number patterns.

The angular stuff linked to, while it supports the native stuff (good on Android 5.0+ where the pickers are MD), it isn't adhering to Material Design for most browsers and OSes. We should be able to implement something that will support the browsers our JS supports and adhere to the specification.

[surma]

Email is normal text. Number, honestly most of the time you should use a normal text input with the appropriate pattern you need.

@Garbee In terms of a11n, that is _wrong_. Esp. on mobile they are different keyboards for both numbers and email. We should support that.

[Garbee]

I meant type=email will work with the textfield just fine as it is. Not that is was purely "just text" (even though technically it is, just with validation and browsers/OSes show a specific keyboard for the type.)

Numbers, at least positive with the pattern [0-9] opens up the right keyboard on some mobile OSes iirc. It is once you start doing floats or negatives things mess up. We could just hide the number spinners on desktop so the number type would work fine and adhere to MD.

[nicolasgarnier]

afaik you can specify the type of keyboard Android will display using some HTML syntax.. I have to look that up though...

[nicolasgarnier]

Well it seems it's by using:

<input type="number" />
<input type="tel" />

As per: http://stackoverflow.com/questions/3372380/how-to-force-keyboard-with-numbers-in-mobile-website-in-android

[surma]

@nicolasgarnier That’s what we are basically talking about. @Garbee is right that any input[type="XXX"] that looks like a regular text field should work with MDL right now. Everything else like type="date" or type="number" will need to be handled separately.

[Garbee]

I'm opening a specific ticket for getting number working.

Date/time/color are the problem children.

[oleg-codaio]

As a workaround, you can hide the placeholder text when the date field is empty. This still forces you to use the browser's date picker, but at least you don't get the placeholder overlapping with the label:

::-webkit-datetime-edit-year-field:not([aria-valuenow]),
::-webkit-datetime-edit-month-field:not([aria-valuenow]),
::-webkit-datetime-edit-day-field:not([aria-valuenow]),
:invalid::-webkit-datetime-edit-text {
    color: transparent;
}

Beware that this only works with CSS3 and probably not with IE.