5 ms·

Love the improvements but how about an html5 date picker? Surely that is not hard?

by pontjho 12y ago

sillysaurus3 12y ago
What do you mean? I'm having trouble understanding how an html5 date picker is related to firefox.
- daok 12y ago
  He means the implementation of the Html5's Calendar for FireFox.
- whitehat2k9 12y ago
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input https://developer.mozilla.org/en-US/docs/Web/HTML/Element/In... Because date is one of the valid types for HTML5 inputs.
- frewsxcv 12y ago
  <input type="date">
- dorward 12y ago
  It is a feature in HTML 5 that has been defined for a while but which Firefox hasn't implemented yet. https://bugzilla.mozilla.org/show_bug.cgi?id=825294 https://bugzilla.mozilla.org/show_bug.cgi?id=825294
maccard 12y ago
You could always do it?
paulojreis 12y ago
Wow. I had no idea that Firefox lacked support for <input type="date|datetime|datetime-local|time">. I was just assuming that it did, simply because "it's not IE". Thank you for pointing that out.
- robin_reala 12y ago
  Safari doesn’t support them either: http://caniuse.com/#feat=input-datetime http://caniuse.com/#feat=input-datetime
  - mbrubeck 12y ago
    Mobile Safari and mobile Firefox support type="date" inputs. Desktop Safari and desktop Firefox do not.
  - mh- 12y ago
    only desktop Safari doesn't, for some reason. iOS does.
IgorPartola 12y ago
I have come to realize that these more extended elements (things beyond <select>, and input types such as password, text, or email) are actually pretty evil. Let me make a small argument in favor of this view: 1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that. 2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future. 3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain. 4. There are better JS-based datepickers out there for the desktop. The only reason to use <input type="date"> IMO would be for a mobile-only site. iOS/Safari uses a stable native date implementation which is awesome. However, on the desktop, there is no standard datepicker widget to use the same way, so it just ends up looking weird. What I would actually love is an <input> type that lets me just type in a date (think a date of birth field) where the input is perfectly validated. That's right, in 2014 with out state of the art browsers, this is still nearly impossible. Sure you can use a regex, but have you tried putting together a regex that validates 2/29/2012 vs 2/29/2014 vs 2/29/1900? On top of that, the patter= attribute doesn't prevent you from typing/pasting, it only provides a place to put validation that's optional. A callback mechanism for as-you-type validation would be so much better.
- jimktrains2 12y ago
  > 1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that. In theory they'd be more consistent across the platform, just like text and select boxes; I'm not seeing the problem. You're site doesn't need to have it's style imposed on every single control. > 2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future. Why do you care what the UI looks like? As long as the API is stable. > 3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain. I count this as a plus, honestly. > 4. There are better JS-based datepickers out there for the desktop. Ugh. The less we rely on javascript for basic functionality the better. You're js, highly themed date picker probably isn't very accessible and probably doesn't function like the rest of the system does either. The more we can leverage the User Agent, the more we should. It's easier on developers. It's more accessible. It's more consistent across the user's platform.

Love the improvements but how about an html5 date picker? Surely that is not hard?

by pontjho 12y ago

Love the improvements but how about an html5 date picker? Surely that is not hard?

sillysaurus3 12y ago

What do you mean? I'm having trouble understanding how an html5 date picker is related to firefox.

daok 12y ago
He means the implementation of the Html5's Calendar for FireFox.
whitehat2k9 12y ago
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input https://developer.mozilla.org/en-US/docs/Web/HTML/Element/In... Because date is one of the valid types for HTML5 inputs.
frewsxcv 12y ago
<input type="date">
dorward 12y ago
It is a feature in HTML 5 that has been defined for a while but which Firefox hasn't implemented yet. https://bugzilla.mozilla.org/show_bug.cgi?id=825294 https://bugzilla.mozilla.org/show_bug.cgi?id=825294

maccard 12y ago

You could always do it?

paulojreis 12y ago

Wow. I had no idea that Firefox lacked support for <input type="date|datetime|datetime-local|time">. I was just assuming that it did, simply because "it's not IE". Thank you for pointing that out.

robin_reala 12y ago
Safari doesn’t support them either: http://caniuse.com/#feat=input-datetime http://caniuse.com/#feat=input-datetime
- mbrubeck 12y ago
  Mobile Safari and mobile Firefox support type="date" inputs. Desktop Safari and desktop Firefox do not.
- mh- 12y ago
  only desktop Safari doesn't, for some reason. iOS does.

IgorPartola 12y ago

I have come to realize that these more extended elements (things beyond <select>, and input types such as password, text, or email) are actually pretty evil. Let me make a small argument in favor of this view: 1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that. 2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future. 3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain. 4. There are better JS-based datepickers out there for the desktop. The only reason to use <input type="date"> IMO would be for a mobile-only site. iOS/Safari uses a stable native date implementation which is awesome. However, on the desktop, there is no standard datepicker widget to use the same way, so it just ends up looking weird. What I would actually love is an <input> type that lets me just type in a date (think a date of birth field) where the input is perfectly validated. That's right, in 2014 with out state of the art browsers, this is still nearly impossible. Sure you can use a regex, but have you tried putting together a regex that validates 2/29/2012 vs 2/29/2014 vs 2/29/1900? On top of that, the patter= attribute doesn't prevent you from typing/pasting, it only provides a place to put validation that's optional. A callback mechanism for as-you-type validation would be so much better.

jimktrains2 12y ago
> 1. They will provide different UI across different desktop browsers/OS's, etc. The theory was that the browser can decide what the datepicker should look like. The practice is that half of them are ugly or lack the UI you want and you can't do much to fix that. In theory they'd be more consistent across the platform, just like text and select boxes; I'm not seeing the problem. You're site doesn't need to have it's style imposed on every single control. > 2. What the UI looks like is still in flux and will likely remain in flux. This means that not only do you have to test/support all the currently provided UI, but you also have to be ready for unexpected changes in the future. Why do you care what the UI looks like? As long as the API is stable. > 3. Specifically because you cannot change what the (fairly complex) UI looks like, you cannot make it match your theme. This can be a huge pain. I count this as a plus, honestly. > 4. There are better JS-based datepickers out there for the desktop. Ugh. The less we rely on javascript for basic functionality the better. You're js, highly themed date picker probably isn't very accessible and probably doesn't function like the rest of the system does either. The more we can leverage the User Agent, the more we should. It's easier on developers. It's more accessible. It's more consistent across the user's platform.