Unfortunately I don't have data on mobile-targeted sites. The number
'0.08% of input[type=date]' came from Google's web search repository. So
it is basically on desktop-targeted sites.
On Tue, Jan 22, 2013 at 5:54 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 22, 2013, at 12:32 AM,
The two mail threads bounce back and forth between Hixie's opinion and
yours. Was there a conclusion reached anywhere on what to do with datetime
and datetime-local?
We agreed that existing implementations of input[type=datetime] were wrong.
But we have no
conclusion of the type renaming and
On Jan 22, 2013, at 12:32 AM, TAMURA, Kent tk...@chromium.org wrote:
The two mail threads bounce back and forth between Hixie's opinion and
yours. Was there a conclusion reached anywhere on what to do with datetime
and datetime-local?
We agreed that existing implementations of
On Sun, Jan 20, 2013 at 9:55 PM, TAMURA, Kent tk...@chromium.org wrote:
Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.
We had some discussion in WHATWG [1] [2] and realized input type=datetime
UIs in iOS Safari and Android Chrome
On Jan 20, 2013, at 9:55 PM, TAMURA, Kent tk...@chromium.org wrote:
Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.
What do you recommend for products that have shipped it already?
- Maciej
Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.
What do you recommend for products that have shipped it already?
I recommend to disable it in the next release of the products. I'll
disable it for Android Chrome.
It's an
Please do not enable ENABLE_INPUT_TYPE_DATETIME to ship input
type=datetimeimplementation in your products.
We had some discussion in WHATWG [1] [2] and realized input type=datetime
UIs in iOS Safari and Android Chrome are wrong and harmful. The current
code for input type=datetime in WebCore
7 matches
Mail list logo
