5 ms·

Consider using basic/native HTML date and time pickers which are mostly supported by all major browsers besides desktop Safari instead of overengineering. http

Consider using basic/native HTML date and time pickers which are mostly supported by all major browsers besides desktop Safari instead of overengineering. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/time https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... https://caniuse.com/#search=time%20input https://caniuse.com/#search=time%20input

styfle 8y ago
How can Safari go this long without implementing this part of the HTML5 standard? Is there even a ticket to implement?
- Traubenfuchs 8y ago
  That's a good question. Why is the company that ranks 4. place in the Fortune 500 index unable to implement basic, boring but useful HTML 5 features in their desktop browser that were implemented by Opera nearly 10 years ago, while at the same time implementing them on their mobile browser? It looks like they just gave up: https://bugs.webkit.org/show_bug.cgi?id=78746 https://bugs.webkit.org/show_bug.cgi?id=78746 https://bugs.webkit.org/show_bug.cgi?id=88026 https://bugs.webkit.org/show_bug.cgi?id=88026
  - Sharlin 8y ago
    Are they unable? Of course not. Is desktop Safari in any way a priority to them? Not really, at this point.
- ballenf 8y ago
  A long-shot, but could they be waiting for convergence of desktop and mobile in MacOS? With the upcoming Mojave, they're taking a small step in that direction. Not an excuse for these delays dating back 5+ years, but maybe an interesting question.
  - mcphage 8y ago
    > could they be waiting for convergence of desktop and mobile in MacOS? Maybe, but... honestly, that's not really good enough.
- Sharlin 8y ago
  They probably care very little about desktop Safari. There are few persuasive business reasons to care about it at this point. macOS as a whole seems to be considerably deprioritized.
ifightcrime 8y ago
But then what do you do for desktop safari?
- megaman22 8y ago
  Depends on your market, but if you're in enterprise software, it's a small percentage of your typical userbase, and of those nearly all have access to a good browser like Chrome or Firefox available anyway, so the upside of going out of your way to support Safari is not high.
habitue 8y ago
It's a long article, but there's actually a section called "Where Does This Leave An OS’ Native Date Picker?" That links to exactly what you've linked here, and describes some considerations for when you might not want to use them: "The problem with native date pickers is that they are very limited in their design and functionality. For example, it’s impossible to add any details such as availability or pricing to a native date picker to avoid zero-results pages. It’s also impossible to select a date range and highlight the connection between two dates because it doesn’t provide a calendar overview." I think the title is a bit misleading, it sounds like they're going to design the perfect date-picker widget, but instead it's a giant catalog of design considerations that vary for different reasons for requiring date input. Basically, you probably don't want a one-size fits all picker, you'll want to adapt it to your particular problem domain
Numberwang 8y ago
It's too bad these can't pick up local preferences of input format.
- Traubenfuchs 8y ago
  I see the date input the German/European/sane way in Chrome, like this: "18.07.2018", unlike shown on the mozilla screenshots. Is that what you mean?
  - Numberwang 8y ago
    Yes that's what I mean. I'm Swedish and it does not follow the Swedish input standard which I much prefer to any other.
jitl 8y ago
I think the native date picker is okay for dashboards, internal tools, or similar cases where supporting 87% of users (based on browser) with an inconsistent experience is okay. On a revenue funnel, especially for consumers, you should pick out a component with wider bowser support and consistency: - Those desktop Safari users are more affluent, and probably represent a more significant opportunity then they do browser market share, especially in the US. - The inconsistent quality of the date pickers will skew your numbers between users on different browsers. Noticing 15% fewer customers buy when using Edge? Is it because you have an Edge-specific bug, or is it just the weird date picker?
saudioger 8y ago
Support is rather abysmal.
billysielu 8y ago
IMO, the easiest way is text boxes: [DD] [MM] [YYYY] [HH] [MM]. Old people just don't 'get' dropdowns and calendar controls. It can't be perfect unless everyone can use it. Native controls don't meet the criteria because people use browsers which don't support those controls.
- tabtab 8y ago
  Hey, I'm an "old people" by some standards ;-) How about just saying, "people who are still new to computers" or the like. Don't have to mention age. My rule of thumb is to be PC unless there's a good reason not to. Politeness should be the default. Experience tells me Dale Carnegie is right about effective groups far more often than Yosemite Sam's approach. (The President is a Sammer.)
  - billysielu 8y ago
    lol I take your point. I don't really mean people new to computers though, more those who continue to struggle over the long term. Typing into boxes is easier to figure out than all other field types.
    - TomK32 8y ago
      what do you mean with "lol"?
      - billysielu 8y ago
        I don't want to turn HN into Twitter, so I'll politely decline to get into it.
tabtab 8y ago
The native ones don't consistently/easily support "mm/dd/yyyy" formats, and many customers want that. One general design decision about date-pickers is if the target date range is large, such as birth-date, then one needs an easy & obvious way to select or scroll the year also, not just month-by-month.
Reedx 8y ago
Handy for internal tools, but unfortunately a pretty weak choice for most things public facing.
Zardoz84 8y ago
well, you can find that for some use cases, aren't very user friendly. Try to input a date of the XIX century.

styfle 8y ago

How can Safari go this long without implementing this part of the HTML5 standard? Is there even a ticket to implement?

Traubenfuchs 8y ago
That's a good question. Why is the company that ranks 4. place in the Fortune 500 index unable to implement basic, boring but useful HTML 5 features in their desktop browser that were implemented by Opera nearly 10 years ago, while at the same time implementing them on their mobile browser? It looks like they just gave up: https://bugs.webkit.org/show_bug.cgi?id=78746 https://bugs.webkit.org/show_bug.cgi?id=78746 https://bugs.webkit.org/show_bug.cgi?id=88026 https://bugs.webkit.org/show_bug.cgi?id=88026
- Sharlin 8y ago
  Are they unable? Of course not. Is desktop Safari in any way a priority to them? Not really, at this point.
ballenf 8y ago
A long-shot, but could they be waiting for convergence of desktop and mobile in MacOS? With the upcoming Mojave, they're taking a small step in that direction. Not an excuse for these delays dating back 5+ years, but maybe an interesting question.
- mcphage 8y ago
  > could they be waiting for convergence of desktop and mobile in MacOS? Maybe, but... honestly, that's not really good enough.
Sharlin 8y ago
They probably care very little about desktop Safari. There are few persuasive business reasons to care about it at this point. macOS as a whole seems to be considerably deprioritized.

ifightcrime 8y ago

But then what do you do for desktop safari?

megaman22 8y ago
Depends on your market, but if you're in enterprise software, it's a small percentage of your typical userbase, and of those nearly all have access to a good browser like Chrome or Firefox available anyway, so the upside of going out of your way to support Safari is not high.

habitue 8y ago

It's a long article, but there's actually a section called "Where Does This Leave An OS’ Native Date Picker?" That links to exactly what you've linked here, and describes some considerations for when you might not want to use them: "The problem with native date pickers is that they are very limited in their design and functionality. For example, it’s impossible to add any details such as availability or pricing to a native date picker to avoid zero-results pages. It’s also impossible to select a date range and highlight the connection between two dates because it doesn’t provide a calendar overview." I think the title is a bit misleading, it sounds like they're going to design the perfect date-picker widget, but instead it's a giant catalog of design considerations that vary for different reasons for requiring date input. Basically, you probably don't want a one-size fits all picker, you'll want to adapt it to your particular problem domain

Numberwang 8y ago

It's too bad these can't pick up local preferences of input format.

Traubenfuchs 8y ago
I see the date input the German/European/sane way in Chrome, like this: "18.07.2018", unlike shown on the mozilla screenshots. Is that what you mean?
- Numberwang 8y ago
  Yes that's what I mean. I'm Swedish and it does not follow the Swedish input standard which I much prefer to any other.

jitl 8y ago

I think the native date picker is okay for dashboards, internal tools, or similar cases where supporting 87% of users (based on browser) with an inconsistent experience is okay. On a revenue funnel, especially for consumers, you should pick out a component with wider bowser support and consistency: - Those desktop Safari users are more affluent, and probably represent a more significant opportunity then they do browser market share, especially in the US. - The inconsistent quality of the date pickers will skew your numbers between users on different browsers. Noticing 15% fewer customers buy when using Edge? Is it because you have an Edge-specific bug, or is it just the weird date picker?

saudioger 8y ago

Support is rather abysmal.

billysielu 8y ago

IMO, the easiest way is text boxes: [DD] [MM] [YYYY] [HH] [MM]. Old people just don't 'get' dropdowns and calendar controls. It can't be perfect unless everyone can use it. Native controls don't meet the criteria because people use browsers which don't support those controls.

tabtab 8y ago
Hey, I'm an "old people" by some standards ;-) How about just saying, "people who are still new to computers" or the like. Don't have to mention age. My rule of thumb is to be PC unless there's a good reason not to. Politeness should be the default. Experience tells me Dale Carnegie is right about effective groups far more often than Yosemite Sam's approach. (The President is a Sammer.)
- billysielu 8y ago
  lol I take your point. I don't really mean people new to computers though, more those who continue to struggle over the long term. Typing into boxes is easier to figure out than all other field types.
  - TomK32 8y ago
    what do you mean with "lol"?
    - billysielu 8y ago
      I don't want to turn HN into Twitter, so I'll politely decline to get into it.

tabtab 8y ago

The native ones don't consistently/easily support "mm/dd/yyyy" formats, and many customers want that. One general design decision about date-pickers is if the target date range is large, such as birth-date, then one needs an easy & obvious way to select or scroll the year also, not just month-by-month.

Reedx 8y ago

Handy for internal tools, but unfortunately a pretty weak choice for most things public facing.

Zardoz84 8y ago

well, you can find that for some use cases, aren't very user friendly. Try to input a date of the XIX century.