It took me a few seconds to parse the calendar view, but my first guess about where to tap was correct. And I expected the month and year rollers to move separately, which the article says is counterintuitive. But I don't own any devices that run Safari, so maybe it's inconsistent with the usual expectations of the interface?
I disagree about them needing to be separate. Once you have that panel open (and knowing how to open it is the problem), you see the two high level selectors that you need. If you only need one, then the other is harmless and will not confuse you; you will just not touch it.
Of course it's better to have them moving separately, otherwise somebody would move 12*n times the month to move n times the year, before discovering that the year also moves, if they'll ever discover it. However a better solution would be to show only the month and only the year in two separate screens. No surprises, no chances of using the UI inefficiently.
And for 12 months, you can show all of them together on the screen. Same for the years, you can show more than one at the same time and scroll many of them together.
I think you're talking about slightly different things.
The issue (which I agree with) is that the month and date "share" a continuous grey background which makes them seem connected.
They can be visible at the same time, but it would make sense to me to separate the backgrounds as to indicate that they can be scrolled separately before touching them.
Ok, I see. Yes I do agree that having some visual indication of independence of month from year would be better than none.
Although in this case since the only thing you can do is try to touch and move something, it only takes one "not sure what this does-touch" action to discover that they are independent; and then you know how to operate it. Not ideal, but low on the pain scale.
Popping them up at the same time is really good for "pipelining". I know that the year picker is next and I know where it is while I am entering the month.
If you hide it on a different screen I need to react to it when it appears.
Not to mention that you now need a "Next" button and a "Back" button in case I made a mistake (or just want to double-check what I inputted)
I guessed correctly as well due to the blue arrow next to the date indicating further interaction was possible. I have decades of computer use experience though. I'm not sure if it's intuitive for every demographic or what an appropriate interface would be for our elders.
Another anti-pattern this UI and most modern UI has is a dramatic reduction in the number of visual cues that identify interactivity. This is a system widget, and blue indicates interactivity... but that's almost it. The shape is often used for other purposes, such as for a breadcrumb, and actually the positioning makes it look more like a breadcrumb. Furthermore, it's going to be used from a website, and thus you can't rely on the fact that the rest of the site's colors will be consistent with this particular shade of blue on an icon indicating interactivity.
It's all rather minimalist - and if a user catches it, that's fine, but if they don't, there aren't any fallbacks or additional hints as to what to do. Additionally, the icon seems fairly small from the screenshot - though on an actual device that may not be an issue. It may be too small to function as a good UX element.
They're getting tons of customer service calls though. Objective data always beats subjective, and the objective data here is that a bunch of customers are confused and unable to use the website.
I have no doubt that 9/10s of people reading HN would be able to figure this out if not more. But what is the figure like out in the normal/non-IT world? I miss when Microsoft had their accessibility research lab that tested stuff like this scientifically and released tons of great papers. We need more of that, I'd love for Apple to invest in stuff like that.
> They're getting tons of customer service calls though. Objective data always beats subjective, and the objective data here is that a bunch of customers are confused and unable to use the website.
The problem is whether they're getting calls because the UI is objectively worse, or because there's an upstream selection issue: there are comments on the gist showing the UIs on other browsers are not fundamentally different, the biggest difference is that Firefox desktop makes it much clearer that the month/year is an active control, and the three desktop variants clearly allow textual input.
They also indicate that their population is:
> As such, most of our customers are in their 60s or older.
So sounds to me the issue is not that Safari is worse than the rest (although it's no better either), but elderly generally get (or get offered) iPads for pretty obvious reasons, and so there's a huge selection bias.
date pickers are great for selecting recent dates such as this month or next month. this works very well for hotels and stuff like that where you select multiple dates. i would rather date picker than type it in
It depends on the use case. For something like birthday, ID expiration date, etc., just being able to type in the correct values is the best UI. But for a use case like scheduling something in the near future (e.g. a flight, delivery, whatever), the calendar picker is superior because days of the week actually matter for this use case.
Exactly, a plain text field that does best effort parsing. If you want to be precise you can enter "2022-12-01", but if you are in the mood you can enter things like "tomorrow" or "first of the year", or "June 1 1999". UI could even show the exact parsed date below the field as a hint.
I know it's not the fashion now, but the jQuery UI date picker works really well, can be configured for various situations And let's you type the date instead.
I wrote code on the back-end to also parsing. So just type 11 for the 11th of this month, or 11/11 for 11 Nov this year. Or 11 Nov. Or next Tuesday. Or tomorrow of yesterday etc.
It also only treats the screen format as a suggestion. Like it wants dd/mm/yyyy, you can type in 1945/12/6 and it'll figure it out. (it uses the suggested format to resolve ambiguities)
Computers are good at this, and should do more if it. Don't get me started on Web sites that reject my credit card number because I type in hyphens or spaces. With specific messages like
"enter the number as 16 digits, without spaces". WTF????
The best is to have both. Let customers type in a date and show it in a calendar below so people can confirm it's the date they're interested in. Let them tap on the calendar to correct it if needed.
I was a web developer when IE6 support was still a thing. Safari is the new IE, it may not be as bad yet, but it's right on track, cumulative regressions being the norm.
I have heard they are improving in recent updates. I'm skeptical, very skeptical, but it's possible that Apple has heard all of this complaining and is trying to pivot to counter it.
When I hear Internet explorer I don't hear about the monopoly Internet explorer 6, I hear about the Internet explorer 11 that had to be supported for years and constantly just had to be different from everything else in a way that was frustrating and infuriating whenever you were trying to develop a product.
Safari does not have the monopoly status, Chrome has that, but safari does have the IE 11 like constant fighting when you have to support it.
Also Safari has monopoly status for everyone using an iPhone. The people on iPhone simply can't pick another browser, because Apple won't let them.
> Firefox is the browser I want to see be the competition.
Extremely unlikely unfortunately unless the planets align and Google ceases all promotion of Chrome and Mozilla dramatically improves their own promotion game. Firefox would probably need more tangible reasons for people to switch too, because realistically the masses aren't going to care about the privacy or marketshare angles.
Mozilla can't stand up to that, which is why I mentioned that Google would need to cease all promotion of chrome (including cross-promotions in other Google products).
But that alone wouldn't suffice. From what I've seen of Mozilla's efforts to promote Firefox, they don't have any idea of how to appeal to the broader audience, or really any audience beyond the privacy-conscious. That Firefox allows better control of one's data is great but it's not nearly enough to carry most people past the friction point of switching browsers. For that you need things like major advantages in battery life and features that fix common web browsing annoyances.
> but safari does have the IE 11 like constant fighting when you have to support it.
Yes, and is also very IE like in that it's not evergreen, various iOS devices stuck on specific revisions that Apple has left in various states of broken.
Yes, but Firefox focus is Safari. Chrome is safari.
iPhones aren't allowed to have web browsers that aren't running Safari on the back end. They can have different names, different UIs, but at the end of the day it's the same browser.
And JS engine, the whole thing is basically safari with a different URL bar and ancillary stuff like bookmark syncing. As far as the code is concerned it's 100% Safari.
I don't know why non iOS browser play the stupid pseudo support game with Apple, it just makes it confusing for users like the parent comment... playing into Apple's hand, helping them pretend that it's actually a fair ecosystem with choices.
> I don't know why non iOS browser play the stupid pseudo support game with Apple, it just makes it confusing for users like the parent comment...
That's easy. Users want their bookmarks, history, passwords, etc synced across devices, and so if there's no Chrome, Firefox, Edge etc for iOS to accomplish that on iPhone/iPad, people who have multiple Apple devices would likely switch to Safari and those users would be lost. Additionally, in the case of Google and Microsoft, they'd be opting out of those sweet, sweet streams of user data if they had no iOS presence. And so, those browsers exist, just built around WebKit instead of Blink/Gecko.
Oh for sure, having to support IE 5.5/6/7/8 at the same time was a nightmare of conditional comments and css hacks, and testing as you typically could not run multiple versions side by side due to the deep integration into Windows.
Yea, it's not like they substantially diverged from the iframe spec and then abandoned that idea but left it active in a major version that needs support... wait
That's literally what I'm now doing for Safari, though. There are very, very few things that don't work automatically across Firefox and Chrome/Chromium/Edgium, but quite a lot where Safari wants it differently. Having to type 'apple' (apple-touch-icon) or 'webkit' (-webkit-text-fill-color) literally into your code is a bad thing in my opinion.
I'm just gonna comment on this instead of everyone and I won't reply after this because I've said my part.
In my opinion this is not comparable at all, slightly differently or prefixed property/attribute names are really very acceptable to me compared to the hacks we used to implement. Having to hack for multiple IEs while also ensuring those hacks are not applied to other browsers was a special kind of evil to battle, and we are not just talking about "oh IE does not support this so we need to do this another way" but also things like "oh IE like to double the specified padding because why not" - and then at some point they removed conditional comments because they were like "IE is good now." which of course it wasn't.
I develop for Safari amongst other browsers daily and have for years, and do not share these frustration everyone else seems to have for it. Do I agree there should be more frequent updates of Safari (also for older MacOS)? Yes. Do I agree iOS should allow other browser engines? Yes. Is supporting older Chromium engines annoying too? Yeah of course, I've run into that as well (don't have any concrete examples right now unfortunately). People like to think that you can expect Chrome to always be the latest version because of the auto updating, but I have experienced multiple issues caused by users with a (very) outdated version. Whether or not you support these depends on your business / target audience, I had to, and it was frustrating.
Different browser engines will always be different and implement standards at different rates, and standards are often implemented before they are finalised and some do this with prefixes and others do not. Supporting multiple browsers is part of the job, if you don't like it you should not be doing front-end web development.
I for one would hate living in a world that is run by Google (Chromium).
That's exactly how it works for safari, a bunch of ifs for each version of Safari having issues because they don't even have the same issues on desktop and on mobile
Interesting but I disagree, yes Safari has a lot of missing features & stuff behind prefix but it has also a lot of pure rendering bugs and that's where the "if safari" comes into play and the analogy with IE comes from. And Safari is still an outlier compared to the other modern browsers.
I've experienced zIndex bugs, border radius bugs, form bugs, svg bugs and even dom event bugs.
I've ran into issues with every browser I developed for (even to the point of the computer freezing in some Chrome bugs I remember) and have never felt like Safari was as annoying or frustrating as IE was back in the day (and _that_ is the main comparison being made in this post). In my 20+ years of front-end development with work supporting millions of users worldwide I can say without doubt, IE was much much worse than Safari is.
I don't know how many of the people making this comparison actually had to deal with IE 5.5/6/7/8 support on a daily basis back in those days or what exotic things people are doing now.
Safari does feel like it has more rendering bugs yes, but I did also say in my comment that I believe Safari should have more frequent updates because bugs hang around longer. But then again, you are still not guaranteed that people always have the latest version anyway, even in Chrome.
I just don't get this comparison to IE and this is the first time I thought I'd comment on it, but in the future I will not do it again. The era of IE sucks, but IE was IE and Safari is Safari, Firefox is Firefox and almost all other browsers are Chrome. We are all allowed our own views on this and I should not have commented at all I guess.
Happy new year!
*: p.s. Apple should allow different browser engines on iOS
Safari 7-8 years ago was potentially worse than IE in my opinion.
Totally broken indexedDB implementation. Random rendering issues, especially if you happen to ever use z-index. Hacks needed to get the most basic events to trigger. Idiotic scrolling behaviour. Choppy animations that didn't adhere to basic CSS standards (even the ones that weren't added by Google).
Honestly, it was a mess, and sometimes felt like a deliberate ploy to stop web apps from becoming viable. Things are better now. Just waiting for them to finally add web push notifications.
The claim that "Safari is the new IE" has nothing to do with perceived quality of Safari's implementation of things.
It's that Safari is the only browser allowed on iOS. Which means that we are stuck with the subset of the standards that Safari has chosen to implement.
So Safari has outsized influence over which standards are actually feasible to build an application around.
One example: I've lost count of how long I've been waiting to build web apps that can send (user requested) push notifications.
> So Safari has outsized influence over which standards are actually feasible to build an application around.
Which, considering the alternative is Google having complete control over the web, I'm quite thankful for. It doesn't line up with how I'd like things to be in either case but it's much better for there to be some sort of check against Google. Google is far too aggressive about implementing new tech in the browser for very obvious reasons.
> Then everyone else can look like they're behind!
I’m not one to defend google, but in the matter of a datepicker… it’s 2023 for crying out loud! A datepicker standard should have been solved and implemented about 20 years ago.
Admittedly it’s non-trivial dealing with dates across regions, time zones, DST, etc, but c’mon, it’s been clearly solvable for decades.
I didn’t even know <input type="date"> was a thing, I rely on JS datepicker libraries in various places. However there’s usually plenty of configuration that goes along with that, so I’m not surprised it isn’t optimal in all cases.
Of course it's the new IE. What else would it be? It's all relative, and relatively it's the worst at implementing UX and standards (across mobile and desktop) compared to the rest of the field.
Just because it doesn't exactly match up to the same scenario of IE6 doesn't takeaway from the point that you can develop for everything else easily, then must deal with Safari's failures specifically.
That's an abusive use of editing. You've deprived the entire subthread of the context people were replying to. This is unfair to the other commenters in the thread, and is no different from when people rage-edit their comment because they don't like being flagged or downvoted.
Please don't do it again.
p.s. A comment beginning with "I hate these stupid parrots claiming Safari is the new IE" obviously broke the HN guidelines and therefore did not belong at the top of the thread. The moderation here was correct; your comment and laster destructive edit were out of line.
thanks for the context. I can see how the comment broke the guidelines, but can also imagine the frustration a user feels knowing they've been secretly screwed by the mod team. Couldn't the comment have simply been flagged instead? Just feels more honest
I don't think anyone has been "secretly screwed". HN is a complex system consisting of different factors, including community, software, and moderators, that all have their proper place and do things the other parts can't do.* If there's a way to modify the system to function better, I'm certainly interested, but I don't think mods doing their jobs properly is screwing anybody.
On the contrary, the things mods do—including downweighting top subthreads when they break the guidelines or aren't in the intended spirit of the site—are vital to why HN functions as well as it does (not that it functions particularly well; just that it could and would be worse). In fact, that process of downweighting top subthreads is probably the biggest thing we've ever figured out to improve thread quality, at least in recent years.
* Btw, if there were a way to have the community and software alone do what mods do, and thus eliminate the need for mods, that would be a day of great rejoicing on our part.
It's unfortunate, because there was more value in the discussion than the obvious sentence he posted, but because I simply didn't curb a word or two, the entire conversation is naught.
If you’re going to include my words, which I chose to remove, go ahead and post the whole thing instead of being rude and taking my post out of context by only posting the part you wanted everyone to see.
Don’t do that and tell me I’ve deprived people of context. You've already taken away from otherwise valid discussion about development with an industry and why this sentiment has proliferated by pushing my post to the bottom.
I could have also simply replaced the sentence with, "I don't like it when people repeat that Safari is the new IE," but HN doesn't have a recorded policy of restoring posts from downweighing.
If this is the only offending sentence, it seems like pretty shallow moderation to me.
“Edit out swipes” is a part of HN guidelines. I removed the post because clearly moderation found it fulminating, I agree it was, and now you seem to think you own my words.
If you have a problem with edits after silent moderation and believe this to be abuse, which contradicts current guidelines, just update the guidelines to include such a statement.
“Edit out swipes” is a part of HN guidelines. I removed the post because clearly moderation found it fulminating, I agree it was
Perhaps it's unclear but the guideline there is about taking that stuff out before you post. The whole set of subsequent problems just goes away entirely if you do that which should be straightforward given there's agreement on the root cause - the posting of yelly comments.
Sorry for the delay in replying to this! I appreciate that you were intending to follow the guidelines and apologize that I didn't pick up on that and instead interpreted your edit as abusive. I thought you were rage-editing, which is sort of the message-board equivalent of turning over the chessboard and storming off. That happens quite a bit and I erroneously pattern-matched your comment to that behavior.
The "edit out swipes" guideline is intended more along the lines of "please edit out any guideline-breaking swipey bits from your comment, while leaving the substantive point intact."
Now it seems the date picker, like the Safari one, is just meant to let you pick a recent date; for a faraway date like DOB, the weekday does not actually matter, so it is easier to ask the user to type. Just some quick thoughts after reading the article and comments.
The date picker only defaults to today's date if they don't specify a default value.
Tbh I think setting a default value might actually have been a better solution. It's not perfect, but hacking together your own alternative could lead to a number of issues for folks relying on screen readers and other input devices. The `type="date"` gives a lot of semantic meaning that `type="number"` lacks.
If you're gonna ditch it, I'd say at least use an existing external library that's been battle tested for accessibility.
What would a default birthdate be? That would span 80+ years. That's not going to work. Any time an input spans ~29k values, you better provide some logarithmic-time searching mechanism. So yes, Safari's date picker is f'ing dumb.
From left to right, that's Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop
---
The post specified that the users are mostly senior. Regardless of what they go with clearly 0% of their users benefit from leaving it to default today unless they somehow figured out how to sell smartphones to fetuses
If a default value is set you’re going to have the problem of people skipping the field and submitting the default value instead. What is needed is a way of influencing the picker’s default view into year view with a default year visible, but without actually setting a default value. Only Apple can provide that level of control.
You’re talking about slightly different things. You’re right that when the UI opens it’s always going to be on a default date, if you don’t set one it’ll be today.
But if you don’t set one then the value of the HTML element will be null before it’s selected. So if you add a required attribute then you can make sure that your users use the date picker (or leave in frustration after failing to do so) before submitting the form.
If you set a default value using the value attribute, then that becomes both the HTML default value and the UI default. IMO the spec is missing a way to just set the UI default, so that the field is default empty but interacting puts it at a sensible starting point.
That's not what `defaultValue` does. `defaultValue` is a JS (not HTML) attribute which simply allows you to retrieve the original value set in the HTML. So if you have this HTML:
<input id="foo" value="bar">
Then `document.getElementById('foo').defaultValue` will always return `'bar'`, even if the user has edited the value in the field.
Then yeah I suppose it'd have to be a javascript trick that sets the default value when the calendar is opened or, as GP suggested, something done at the standards or implementation level
And lacks the semantic information that's used by screen readers. If you're gonna ditch the native elements you should probably use an external library that has meticulously worked through all of these issues
Agreed. I'm an iOS user primarily and have been since almost iOS 1. Some android intermittently.
I have no trouble figuring out how to pick by year because the rest of iOS follows a standard UX.
It seems more important to me to support the native accessibility of the phone than use an external UI vendor.
I am a huge advocate of family members and elders to purchase devices they are comfortable operating. This is why my grandparents primarily use their desktop computer for any important things, and their iPhones for messaging/video chat.
The most straightforward solution I can think of is to split date inputs by context. Create an `<input type="dob">` that is tailored for picking a date of birth from 1900-today. "date" is too vague of a context to create an UX that works well in all the different contexts. It'll always be bad in some contexts, if it's trying to solve all the use cases.
This. In my form generation library (that I maintain and use for client apps) there are two types of datetime input areas available. They take the same arguments for ranges and single/double dates, with or without time, and at what frequency of time (e.g. hourly, 15 minutes, etc). One wraps a calendar library (daterangepicker) and attaches it to the form; the other generates a responsive text input with placeholders and danger labels. Their outputs are both returned as Moments which can be sanity checked, tested against other constraints and shipped back out as YYYY-MM-DD HH:MM:SS to the database.
Date pickers are one of the worst interfaces on the web. Everyone seemingly has a wildly different design and they're almost always hard to use and unintuitive. And forget about if you're picking a date _range_
I've been using daterangepicker [1] for ages, and it's one of the reasons I still just default to jQuery for web apps (the other being jQuery's custom event chain). Works well, very readable, easy to pass functions to disable individual dates which is important in reservations apps, ties in nicely with moment.js. More to the point, finding a decent calendar that didn't baffle users was such a pain for so long that I never want to have to do it again. And of course, with native browser components who knows what your user's going to see next year?
> I chalked up the "New IE" stuff to annoying little CSS issues
Here, too, Safari is the cause of 2/3rds of the lines of exceptional UI code now that Edge switched to a compatible render engine. Or blocks features altogether. All major browsers settled on doing things a certain way and then you remember that you always need to check Safari and of course they want it another way, so you get to re-do the work and duplicate your code with a comment "//because safari wants x to be done this way". I had less trouble with MSIE6 back in the day, though I can't rule out that I did less fancy things back then.
These things are not like "oops we render it differently by chance", it's conscious choices like not supporting SVG or being able to read file names in JavaScript (can't have javascript-based upload progress bars or local file encryption if you want to keep the filename; need to encrypt on the server and have the server report progress back via another channel).
My definition of compatible is basically what I described in the comment: "[not being] the cause of 2/3rds of the lines of exceptional UI code".
There's the occasional situation where Chromium doesn't support something or Firefox doesn't support something, but it feels like Safari has double the rate of both combined.
The computing industry has a pretty poor track record of multiple-implementations ever agreeing or being a net positive for the user. Instead it always seems to devolve into pile-of-hacks for platform X and pile-of-hacks for platform Y, regardless of what the specification says.
Can any browser that is not a reskin of Chrome with feature and bug-for-bug parity actually satisfy web developers at this point?
If Firefox had the marketshare of Safari and was mandatory to support because they were a major platform’s browser devs would be cursing their name too but with a different set of things that aren’t exactly like Chrome.
It really does feel like devs are literally developing against Chrome with not even so much a thought at cross-browser compat or a glance at caniuse and then taking their finished site and then working backwards from there on other browsers cursing the compatibility issues when they could have avoided it entirely had they started with a cross-platform subset of browser features. Just the same as how cross-platform native development works.
I develop with Firefox on the desktop, and for the vast majority of cases if you develop for Firefox on the desktop, Chrome just works perfectly fine, and most of the time the mobile browsers work as well.
Safari (mobile), however, will be broken. Firefox on Android often breaks for more complicated stuff, but works better in my experience.
> If Firefox had the marketshare of Safari and was mandatory to support
Uh, it kind of is? At least, I use Firefox exclusively and thus also support it when developing things.
The browser I have trouble with sometimes is a webview skin on mobile (whose engine is blink or whatever it's called nowadays), there some sites block the http user agent string for some reason or it's missing some advanced this or that and I have to switch to mobile firefox which is a lot slower.
> Can any browser that is not a reskin of Chrome with feature and bug-for-bug parity actually satisfy web developers at this point?
Uh, yes? Firefox? I don't understand your question.
> now that Edge switched to a compatible render engine
Not “compatible”. The same render engine.
Edge is essentially just Chrome with a slap of Microsoft paint.
That’s nice for uniformity, but having all browsers use the same engine is not good for the health of the open web. We do not want Google as a single point of failure any more than Microsoft.
Hah, tell that to Edgium. There are still incompatible sites, same as with Google Chrome® and Chromium. Their own Google Meet will not work properly in Chromium whereas it does in Google Chrome and Firefox. I don't use Edge myself since I'm on Linux (though, surprising fact of the day: there is an Edge release for Linux!) but my girlfriend has stories (which I apparently failed to remember or I'd give examples now; they might also be company intranet sites though). Might have something to do with trying to be more IE-compatible.
and inevitably those JS implementations almost never take into account screen readers. I think we should use the platform as much as possible for this reason
90% of the annoyance could've been dealt with if they had just chosen a default date value of, say, Jan 1960 or so.
Well I mean you don't. And you know that. And 95% of internet users know that. It's just an issue with elderly folks not being familiar with this UI
Maybe the real solution is a simple explanation for how to use a date picker component. It'd help those users not just on this site but on many other sites in the future.
Tbh I don't really know what improvements could be made to the picker itself. It looks pretty consistent with the implementation of most other browsers and OSes and even most native components I've seen
I'd love to hear actual thoughts on improvements though
The Android one always makes me chuckle when some obscure site decided to use it. It's so unexpected to get a big pop-up in an entirely different UI style as the rest of the website suddenly, and when I realize what monster I now have to fight, idk it's humorous to me. It also differs between versions but hasn't gotten better.
I have gripes with Safari, but date pickers isn't one of the things only Safari struggles with.
It seems like the first screenshot is `type="time"` and the second and third are `type="date"`. But I don't know if those are native components or the browsers defaults. Would be useful information
Try https://snipboard.io (iirc I found them via HN, https://news.ycombinator.com/item?id=4887660, used to be snag.gy which imo was a much nicer domain but oh well), I use that to paste-and-forget images that I don't care much about but want to be longer-lived than on dro.pm
But yeah that's a good point. I'm on Firefox on Mac and it looks pretty much exactly the same. I don't really get why other browsers wouldn't be causing the same issues
From the screenshots it seems like they're talking about users on a mobile device. iPhones only allow you to use WebKit, but I'd be curious to see what Android's date picker looks like
I feel like they could've just saved themselves the headache by setting the default value to 1950 or something
> Also wild how this post is singling out Safari when Android seems to somehow be even worse
My guess is that it is selection bias. Older people are probably more like to use iOS devices, since they are marketed as being simple to use and maintain. So, they don't hear too many complaints about Chrome on Android, even though it's worse.
Year drop-downs are annoying for things like DOB because there are 100 choices to scroll through. Reminds me of my Humana insurance app where some questions had drop-downs of literally 1,000 values, so I'd swipe and swipe for several minutes, but if I swiped outside the box by a little bit, it would collapse and I'd have to start over. Eventually found that I could select a part-way value and then start swiping again, and if it collapsed I would at least go back to the part-way value.
So, typing in Y/M/D is better in most cases for DOB than drop downs, unless maybe it's dropdowns for [YYY][Y], then [MM] and [DD]? Or how about start with "How old are you" and then get me most of the way there on the picker? :-)
Usually setting a default value is a good idea. That way it doesn't default to today's date.
But the standard implementation does make it very easy to navigate to a different year as pointed out in the blog post. The issue was that elderly folks don't always find it obvious how to do so. However, looking at the alternative implementations from Chrome and Android,[0] I don't think any other browser has made it any more obvious...
If you think Safari is the new IE, you have definitely forgotten (or not experienced) how bad things were with IE6.
They didn’t just have a few bugs in their browser implementation or were slow to implement new features.
Basic, crucial CSS features were broken. Microsoft didn’t add any new features to the browser about a decade, basically holding the entire web back to the standards of circa year 2001 until it was finally safe to drop support for it almost a decade later.
And furthermore, Microsoft weren’t pushing users to upgrade to the latest version, so we had to support older versions of IE long after their replacements were released.
I understand wishing that Safari would be better, but luckily the Safari team is much more on the ball than the IE team ever was.
It's not my experience as a web developer. It's 'a lot' at best. And not only in js, but also in css or literal anywhere you might interact to.
It always requires a few workaround when I finished the page in other browser. Firefox or Chrome, in the other end. If your page works on one of them, it will pretty much just work on the other.
Safari is probably 50% of my bug ticket, almost equals to every others sums together.
Write a page for safari really reminds me the age IE is still a thing.
Interesting. I've run into issues with the way Safari handles transparency values, but don't actually come across many other Safari specific issues these days. Safari has been pouring a lot of effort into improving their web compatibility recently and I feel like it's already making a difference
I'd be very curious to hear some common issues you have to deal with
You have a point, yet I feel the situation isn't as bright as you make it look.
I think Safari isn't broken in the ways IE was, because IE always had comptetitors running along it and pushing the enveloppe where Microsoft was pulling the brakes. Firefox and later Chrome were handicaped in adoption, yet had little to no limitations on the features they wanted to add.
In comparison no other browser can run with the same privileges as Safari on the phone, while the iPhone is a dominant platform. So there just isn't the same space to innovate in a profitable way. The only company who can afford pushing the envelope is Google, and at this point their only real competitor is Firefox, that they basically pay to keep alive. They also have little incentve to really push the web as it doesn't impact their bottom line (native app ads also go in their pockets afterall)
I have submitted 10s of webkit bugs and most of them will never get fixed.
New bugs randomly appear in every OS update.
5 year old cheap android device can handle complex webpages really well, but my 1500 eur brand new iPhone runs out of memory. iOS Safari is really buggy.
I once developed an unusually complex HTML5 Offline app, and found that Safari even had regressions on some basic standard behavior that I needed.
I know there's good faith work around WebKit, etc., by smart and genuine people. But it was easy to wonder (especially with the anger that comes from being existentially threatened) whether some element at Apple wanted to make Web apps work badly, to keep the proprietary App Store party going.
(I did pull it off successfully, but only with much heroics.)
Date widgets are almost universally bad. Most I encounter are unintuitive or outright buggy.
However, OP complaining about usability and the providing three text fields with the MM and DD being placeholders is terrible. Normally placeholder-only labels are a bad idea, but this is especially true when the month and day fields have different order depending on the region. The moment you've got [1] [4] [1980], you no longer know which is month and which is day.
And do they swap these placeholders and entered values if you change the country from US to an EU country?
The lack of progress in the tech world in making consistent user interface standards is disappointing. We should not be still struggling with these topics (and as users we should not be suffering). Tax time, trying to fetch reports from banks/exchanges is one of the worst recurring experiences...
> Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache
I'm not sure how that really helps? Moving multiple years is still going to be a huge pain, so you're only really saving people who have a birthdate in or very close to that same year.
- provide some helpful text explaining to users how to switch between years
- use an external library with a custom date picker
The reason why I wouldn't recommend the approach they went with is because there's all sorts of aria-related properties and semantic meaning for screen readers that type="date" carries. This is especially relevant for the target audience they're talking about. I guess the third option is
- what they did but actually try it with a screenreader yourself. Make sure your aria labels make sense and is navigable for both keyboards and screenreaders (two separate issues). Also make sure you're replicating the validation logic that type="date" gives us for free. Basically replicate all the complex HTML5 logic and semantics
Such text will likely not be read by many. I think I will read it as I am generally a reader of how-to or help files to get a better idea of features. However the rest of my family you would need to point out the explanation text and likely also 'force' them to read it. They much rather tap around in the hope for the desired outcome.
> Actually the Firefox and Chrome date pickers look... exactly the same
They look nothing alike though.
Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).
Hmm I'm on a macbook. I assumed the component was a browser implementation, but maybe MacOS somehow overrides that?
Would you mind providing a screenshot of how it looks on a different OS?
Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
The Safari from the OP is on mobile. Chrome and Firefox on Android are arguably even worse than Mobile Safari since they don't even have the little affordance arrow https://i.imgur.com/4w8IvO8.png
Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png
Agreed. Safari's mobile implementation is better than Chrome's. Firefox feels like the only one that got it "right" but even then I think many seniors would still not realized they could navigate by year
Ah I see. So the issue is basically just that on Safari mobile the arrow points to the right instead of downwards. That seems to be the only difference between Safari and Chrome. It seems Chrome's mobile implementation is worse on every front here (second in pic):
> Ah I see. So the issue is basically just that on Safari mobile the arrow points to the right instead of downwards
The "correct" direction for mobile safari would actually be left, IMHO. Mac and iOS (as well as the iPod and watch) use navigator patterns heavily, where left to right you have a stack of screens with progressively more detail. So it would make sense to have a MMYYYY view, which opens into a monthly calendar, which goes to a time of day.
"Correct" in quotes though because the date/time information is directly manipulatable at every level (it is a picker, after all). Turns out the best level to start at and affordances to pick a date in particular differ by use case.
For instance, the iOS Calendar app has a years view, but it shows a full yearly calendar, one per screen, and makes you swipe 15 pages up to see if you had any calendar entries from the first iPhone.
This makes sense from a calendar point of view, because it is far more common to want to navigate within the same year or previous year than to want to visit your calendar from 15 years ago.
It would be an absolutely terrible interface for seniors to enter their birthdate; far worse than the default here in fact.
If you enter a birthdate in the Contacts app, you get the "three tumbler" interface (for Gregorian calendars, at least) - months, days, and years, presumably in a localized order with localized text.
It is somewhat unfortunate they didn't just stick with this for the iOS Safari interface, as form input entry already expects that a good chunk of screen real estate will disappear for the keyboard. Instead, they went with a floating picker because thats what most websites currently implement (via javascript)
Except that the second and third ones are clearly awful, as there really is no way to dig into the month/year for faster manipulation (at least not one that's readily apparent).
From left to right: Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop
Yes both Chrome and Safari's implementations suck, but I feel like seniors would have a hard time with pretty much all of these. Firefox is clearly the winner here, but I'd imagine would still trip many seniors up
The ones with editable text input fields are all desktop browsers (1 is Chrome, 3 is Safari and I think the last one is Firefox) and the ones without them are mobile (2 is Chrome 4 is Safari)
I haven't tried it, but I imagine you can manually override an `<input>`'s onFocus to not call `e.target.showPicker()` when it's focused on. This would likely allow users to keyboard enter an amount instead
Might be annoying for users that actually know how to use and prefer the picker however.
> Actually the Firefox and Chrome date pickers look... exactly the same
It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem.
At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).
>And do they swap these placeholders and entered values if you change the country from US to an EU country?
The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03.
Note that it i18n isn't implemented correctly by any of the browser date pickers. Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive. So for anybody wanting to interact with both US sites and local sites (presumably quite a few people on the planet), they'll never be able to have appropriate browser date controls - either they get to have US controls on local sites, or local controls on US sites - and both are quite confusing, especially before you open the date control. Unopened date controls just show the client-culture-localized date, so if that doesn't match the site culture... it's going to be a mess.
Definitely not, from experience. Browser widgets need to be context sensitive, not client sensitive. There are (at least!) two simple reasons to see that: firstly, non-browser site provided controls are more common, and those are context sensitive, so it's quite unusual and surprising when a date-widget suddenly is not context sensitive merely because it's using the browser default. Secondly, date controls display dates even when unopened, and in that mode - the default, initial mode upon page load - they look like plain text with some mild styling to indicate interactivity. Dates in plain text should behave like other dates in plain text - i.e. context-sensitively.
To reiterate, there is an obvious, correct implementation here: let the site specify the content culture much like it does the language, and fall back to the user's choice when unspecified. The spec is asking for user confusion and data corruption as-is, which contributes to why usage of date controls remains fairly low.
You could also do both and have the placeholder smoothly transition between being a placeholder vs being a label. Not to self-plug but here's an example I made myself
Not everyone uses the Julian calendar, or even 4-digit years. Here in Japan, this is year 4 of the Reiwa era, so you need a year picker that lets you choose the correct era (Reiwa, Showa, etc.) and then the year of that era, and of course the number of permissible years per era differs greatly. (The era reflects an emperor's term, so when we get a new emperor, we start a new era.) Then, just because this system is such a PITA and anything international doesn't use it (but everything government-related does), we need a converter that lets you convert between the Japanese standard and the Julian calendar.
I wouldn't say the Japanese calendar is used for "most" activity. As far as I can tell, the Japanese calendar is certainly used for things like government forms, but for non-government stuff, not so much. If I buy tickets for something online, for instance, the web form asks for my birthdate using the normal Gregorian calendar year. Even the government stuff is a mix; my residence card shows my birthdate and card expiration date with the Gregorian year.
I have a special hate for the native browser controls when it comes to date ordering. Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format. It's normal therefore to see dates in a format that's appropriate in context - a us news article might use a US format; others will use a different format that makes sense in context.
Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.
> Given the us-centric nature of the web, most of the rest of the world needs to interact with the oddness that is US format.
What is odd about it other than being different and not being immediately lexically sortable in file names?
Edit: It's an honest question. People and context help determine what you're wanting out of a date, so I am curious what is viewed odd about the U.S. format aside from it being not what your country uses or what the ISO standard is,
What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, the day clarifies the particulars, and the year locks down the date but it is almost always known in the given context. In my opinion, there is the one true format for data formatting and text representation (the ISO standard), but each of the various permutations do have their use cases where they shine. For normal dates, all three components are needed, but it is usually nice to know the month, then the day, and then the year is there just to be clear. Knowing the day gives me little information until I have the month, whereas getting the month first gives me more information, where sometimes I can even ignore the day.
> What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, [...]
In my experience, the thing which is the most important/relevant in most situations is the day of month. People often say things like "dia 10" when asked when something is going to happen; that means in context the 10th of the current month if today is the 9th or earlier, or the 10th of the next month if today is the 11th or later. The month is added only when necessary, like "dia 10 de fevereiro" (just "dia 10" today would mean the 10th of January).
Truly a bizzare argument that only gets harder to understand every time I hear it. Whether the day, month or year is most important changes per every case.
Are you telling me if you had file cabinets for the last 50 years, and you had to get a specific file Nov 1992, you would rather sort first and get all the files marked "November", and then sort through those 50 to get to the 1992 November? Surely one would reduce down to the year - 1992 - first, and then to the month.
Same for alphabetical ordering, a data list ordered by logname-MMDDYYYY.log alphabetically wouldnt be chronological order - YYYYMMDD or DDMMYYYY would.
Month is primary in some cases sure, but I think year and day endian are primary in many others - plus have the above sorting and ordering benefits.
As others have said, it's the middle-endianness itself which is weird. Also, if you're going to write the whole date anyhow, I don't think it makes a huge amount of sense to describe any part of it as "more important" to the extent that it deserves re-ordering a date.
The evolution of the US ordering feels (I might be wrong!) similar to how spoken numbers are little endian from 11 to 19, yet big endian from 21 to 99. Some languages are even worse in this regard; but regardless, they're unhelpful historical artifacts that we learn to live with, not actually helpful, well-thought-out, or even merely irrelevant. Notably there are considerable differences between how quickly children learn maths in different languages, and digit ordering may contribute (of course other cultural factors may contribute too). I wouldn't be surprised if date ordering too is similarly a small but real drag on learning.
It's "odd" for a person who is used to saying "third november" and not "november third", i.e the order is reversed even there.
A spoken language full date format for me would be like "third november 2022". That, in either in english or in my native language.
I don't know how circular this argument is (does the spoken form come from a written form of the date?). But this is what makes it odd, that in spoken form I, for example, am used to saying the date first but the "odd" date format writes the month first.
That’s the type of thing I was looking for. Thanks.
I’m curious about the circular reasoning as well, as the same would hold true for both preferences.
Do you mind sharing what language you speak where the day is most often said first? It sometimes is said that way in English, but not as often as the other way around. It’s usually said that way when the day carries higher importance than normal. Like the 4th of July or something.
Can you elaborate on what you mean by date ordering?
I suppose that the ordering of dates is independent of locale.
The locale rules for the date format are simple:
the DOM value property of the field is a string in YYYY-MM-DD format, independent of locale.
The date display format and what the text input accepts depend on browser locale.
Conversion happens automatically and the text input is shown in a way that indicates locale on desktop, least I remember (e.g. dots for European format, slashes for US). If a user enters "1.5.2011" in a browser with German locale, HTMLInputElement.value would be the string "2011-05-01" (invisible to the user).
I honestly can't think of any better choices, the only thing missing is some attribute to eplicitly control display locale. Which is probably by design, as it would be abused to override system/browser locale and create confusion.
I once replaced a Vue date picker library in a web app with native date inputs for UX reasons (e.g. typable dates, reliable visibility of the picker when fields are near window borders, mobile UI...) and users were reportedly happy with that.
Admittedly, it was mainly a desktop app.
So, long story short: the only problem I see here is the mobile modal date picker UX.
And thankfully, it can be improved in the future because it's part of the OS and not controlled by the website.
All of this is thankfully resolved by the spec choice to stick to a specific ISO string format for the value property.
You are talking about locale-dependent formats - which is why the value property of the input element conforms to ISO 8601 YYYY-MM-DD and guarantees that the values are predictably sortable.
There is no other meaningful ordering of dates other than sorting chronologically.
HTMLInputElement with type=date honestly does everything right given the constraints.
As said, this post is a valid complaint about mobile native UI, no less no more.
The problem isn't the machine-readable encoding that indeed happens to use the ISO YMD ordering, its that you can have a site that's in language/culture X, which includes dates related to whatever events or moments are relevant, but also includes a form with a date-field ordering that is _different_ from that of the text and possibly date fields, and _different_ from the convention in language/culture X.
Actual human language is context sensitive. The user's date formatting preference is almost a non-sequitur even as a concept. People fundamentally can't pick whatever date formatting they want in general-purpose content; they'll need to be able to understand whatever is the norm in that context. And in most contexts while there are various date forms, they're usually not (problematically) ambiguous. As long as a user stays within one date-formatting bubble, that's fine, but it just works really poorly if a user does not. Within an application that's primarily concerned with dates and in which every date is a specially typed value, like say a calendar - sure, date formatting preferences are feasible. That however describes a rather small fraction of the overall web. And the textual, machine-comprehensible hypertext web itself, while eating the world, is itself still only part of culture; dates are visible in videos, images, books, magazines, etc - and they make sense in those contexts _in context_ - i.e. _not_ using the client's date formatting preferences.
If a user's date-formatting preferences were to really have meaning on the web, you'd need to ensure that even dates in plain text or written summaries satisfy that formatting, and hope that videos and images rarely are mixed with such text. But that's just not the norm, and likely completely impractical; it'll never happen, especially not given the reality that many dates are manually written by humans without any markup at all. And where software tries to "fix" that - well, you get disasters like Excel, which is notorious for causing insidious data-corruption by trying to guess data-types in pretty creative and unhelpful ways.
In practice that's not what sites _actually_ do. They either have really simplistic date handling, in which case date controls can be confusing but rare enough that it's not hugely impactful, _or_ they use custom date controls (the actual norm). And that makes browser date controls _even_ worse, because those will then unpredictably not use the context culture, but instead the client's culture - unlike most sites, which don't use input type=date as far as I can tell.
The correct solution would be to allow a site to specify the site's culture and formatting settings, much like language can be specified. And if none is specified: sure, fall back to the user's date preference.
When does this problem come up? I don't see much combination of dates in the page's content in addition to simultaneously submitting a form with date input.
Some commenters seem to forget what the MSIE monopoly was all about. About not keeping up with emerging web standards? That's a misconception. That was a result of Firefox interrupting the market.
MS deliberately added non-standard crap to get everyone off the rails when not using IE. That's why websites often showed "Best viewed in 1024x768 and 16M colors using Internet Explorer".
And that is a remark I see more often every day. And it's Chrome being recommended.
Remember why MS switched from EdgeHTML to Blink? Because Google would hamstring EdgeHTML at every corner on their services. Not completely break it, but make Gmail or Youtube a tad slower than in Chrome.
> Remember why MS switched from EdgeHTML to Blink? Because Google would hamstring EdgeHTML at every corner on their services. Not completely break it, but make Gmail or Youtube a tad slower than in Chrome.
I'm not exactly condoning, nor condemning, that behavior, but there's a little part of me that wants to say to Microsoft: "not so funny now, is it?"
I know Microsoft was notorious for not playing nice with other browsers but I thought that mostly had to do with them deciding to go their own way with non-standard features or simply not implementing standards they don't like
Is there documented evidence that Microsoft stooped this low as well? Did they purposely make their sites not work as well on other browsers?
Google also did this to Windows Phone, actively sabotaging the platform by refusing to allow Google Maps to load in WP's browser and repeatedly disabling Microsoft's YouTube app. It was Google at its worst for me, together with their shenanigans around subtly breaking FF on their web products throughout the years.
I absolutely cannot stand those scrolling selectors. They're a UX nightmare in every possible way - literally every one of them would be better replaced by either a normal list, or (when they're numbers) a number input field.
iOS used to use those exclusively to pick times for alarms and such, and I could not for the life of me understand why I'm spending all this time spinning wheels up and down trying to get it right when just typing in "1030" is done in 4 taps
If you’re not aware the iOS time spinner has a hidden number input that comes up it you tap the wheels. So one extra tap then 1030 will get you what you want. Impossible to find without being told it’s there though. And as far as I can tell there’s no date equivalent.
Solution: add a transparent native date picker transparently fitted to a drop-down/calendar icon on the right of the inputs. Requires JavaScript to sync value between native date picker and the xx/xx/xxxx inputs, and it requires some CSS to make the picker “invisible”, and tabIndex to -1. This gives users access to their localised date picker (which can be really important), and may or may not help accessibility. Not DRY, but it solves a bunch of different problems on different browsers (e.g. you can’t tell if a browser has a broken date picker).
This technique also fixes the issue where a Safari Mobile date picker defaults to todays date, for example when using > to move through existing dates that are empty (clicking Done unobviously picks today - often not what you want). Terrible UI for fields like birth date or employment end date. Although depends a bit on whether a blank date makes sense.
Oh, and be really careful of type=number on Safari - it silently fails. inputmode=xxx can help, but it has weird differences between devices last time I looked (versions, Android, iPad etcetera). My mum repeatedly failed to enter a dollar value into a type=number, because she was entering a thousand’s comma (the UI showed $ and , everywhere for numbers so it is a sensible mistake to make; although Safari will display the entered number in the input field the .value==0 —— arrrgh silent failures are hideous).
I hate Mobile Safari - buggy, impossible to get bugs fixed, relatively poor standards support e.g. still need -webkit- prefix for some standardised CSS from a decade ago. Oh, and you end up with people using obsolete phones stuck on old Mobile Safari versions. Android updates Chrome even if it doesn’t update the OS (although Android also has the problem, it is less of a problem).
Right, I agree. What do you think would be a better solution?
The date picker in the image is basically the exact same as Firefox and Chrome's implementation minus some stylistic differences.[0] Most native components also look a lot like this. So this isn't just a Safari issue but an issue across web UI in general
Better configurability which would let the author decide whether they want a calendar or a straight date input. Though I'm not sure iOS even supports a calendar-less date input anymore.
Rolling back the entire "flat" shit would probably be a good idea: before iOS 7, the control was functionally similar but had a lot more visual affordances: https://www.andyibanez.com/img/date_picker_pre_7.png
It was much clearer that the central shade is an index, and that the three fields are separate wheels. The iOS 7 picker makes it much subtler by simulating curvature, and the new sub-selector (year-month) does the same and makes the index kinda even worse by outlining it in an abstract shape: https://user-images.githubusercontent.com/6268177/209607212-...
You think that 1/3 of user support issues due to elderly accessibility problems is acceptable? That is the context the article gave us. And in my experience for every user support issue you get, there are 100 people that had the same problem but didn’t contact user support for whatever reason.
I am not suggesting my solution is perfect, but I am saying I have successfully used it (although I admit is was a few years ago now, and I first used it was when iOS and Android type=date support was unpredictably broken so type=date must not be exclusively be used). I think it was about iOS10 before the bugs in the UI to clear dates were fixed? Another situation for me was New Zealander’s confused by MM/DD/YYYY native formats when using browsers configured for US date localisation.
Until April 2021, Safari on Mac didn’t even support the date control, and Safari (on Mobile or Desktop) still doesn’t support the min or max value attributes. And time entry is a complete nightmare. I always try to make sure data entry controls work well for everybody, even console devices.
There are always corner cases that somewhat depend on your particular users, so compromises are necessary.
Background: I have programmed HTML entry controls (combo, date, time, number, etcetera) for actual man-years of my own life. That is because I started before jQuery existed, supporting IE5.5, and the available DHTML controls were mad broken for usability. I have had to understand the compromises between different solutions on different browsers, and try to find the most elegant solution, given that data entry on browsers is an extremely gnarly problem space.
No tbh I actually really like your solution compared to the alternatives that have been thrown around.
I'm just pointing out it's not easy to implement just to get the logic and styling to work right. And then on top of that, making sure it's screen reader and keyboard accessible adds another layer that is often simply ignored
The simpler solution I put forth resolves most people's problems, maintains the advantages of using native HTML controls the way they were meant to be used, and is easy to implement in... literally a few seconds.
Custom entry fields have different compromises (oh defuckinently), and trying to be too tricky leads to corner-case usability problems and a heavy maintenance overhead in my experience. I judged it was worthwhile for our users’ needs at the time for me to spend very significant development time plus ongoing development time, but my choices would be totally inappropriate in many other situations.
> Here's a simpler solution that's even safer for screen reader accessibility: use the platform
That's exactly what's happening here though, Safari shows the platform's widget.
> Just set a default date and it won't default to today.
That's not really helpful either, DOBs have wide ranges of dates so the need to switch year, possibly decade (as this is for the elderly) will always come up).
362 comments
[ 3.2 ms ] story [ 198 ms ] threadIt's a really terrible UI - why would the month and year both pop up at the same time? They should come up independently.
And for 12 months, you can show all of them together on the screen. Same for the years, you can show more than one at the same time and scroll many of them together.
I'm not suggesting that they are stuck together; that would be pointless.
The issue (which I agree with) is that the month and date "share" a continuous grey background which makes them seem connected.
They can be visible at the same time, but it would make sense to me to separate the backgrounds as to indicate that they can be scrolled separately before touching them.
Although in this case since the only thing you can do is try to touch and move something, it only takes one "not sure what this does-touch" action to discover that they are independent; and then you know how to operate it. Not ideal, but low on the pain scale.
If you hide it on a different screen I need to react to it when it appears.
Not to mention that you now need a "Next" button and a "Back" button in case I made a mistake (or just want to double-check what I inputted)
It does not, that interpretation does not make any sense.
Although I do agree that the old skeymorphic iteration of the control which made it clear those are wheels and the bar is an index was infinitely clearer: https://www.andyibanez.com/img/date_picker_pre_7.png
It's all rather minimalist - and if a user catches it, that's fine, but if they don't, there aren't any fallbacks or additional hints as to what to do. Additionally, the icon seems fairly small from the screenshot - though on an actual device that may not be an issue. It may be too small to function as a good UX element.
I have no doubt that 9/10s of people reading HN would be able to figure this out if not more. But what is the figure like out in the normal/non-IT world? I miss when Microsoft had their accessibility research lab that tested stuff like this scientifically and released tons of great papers. We need more of that, I'd love for Apple to invest in stuff like that.
The problem is whether they're getting calls because the UI is objectively worse, or because there's an upstream selection issue: there are comments on the gist showing the UIs on other browsers are not fundamentally different, the biggest difference is that Firefox desktop makes it much clearer that the month/year is an active control, and the three desktop variants clearly allow textual input.
They also indicate that their population is:
> As such, most of our customers are in their 60s or older.
So sounds to me the issue is not that Safari is worse than the rest (although it's no better either), but elderly generally get (or get offered) iPads for pretty obvious reasons, and so there's a huge selection bias.
But the UI is not superfluous for many use cases. Often, you want to see the whole calendar for context -- eg, to see the associated day of week.
Not on iOS (at least assuming you don’t have a hardware keyboard). The software keyboard does not appear and there’s no option to bring it up.
I wrote code on the back-end to also parsing. So just type 11 for the 11th of this month, or 11/11 for 11 Nov this year. Or 11 Nov. Or next Tuesday. Or tomorrow of yesterday etc.
It also only treats the screen format as a suggestion. Like it wants dd/mm/yyyy, you can type in 1945/12/6 and it'll figure it out. (it uses the suggested format to resolve ambiguities)
Computers are good at this, and should do more if it. Don't get me started on Web sites that reject my credit card number because I type in hyphens or spaces. With specific messages like
"enter the number as 16 digits, without spaces". WTF????
Further reading
[1]: https://github.com/minimaxir/hacker-news-undocumented/issues...
Safari does not have the monopoly status, Chrome has that, but safari does have the IE 11 like constant fighting when you have to support it.
Also Safari has monopoly status for everyone using an iPhone. The people on iPhone simply can't pick another browser, because Apple won't let them.
Firefox is the browser I want to see be the competition.
Extremely unlikely unfortunately unless the planets align and Google ceases all promotion of Chrome and Mozilla dramatically improves their own promotion game. Firefox would probably need more tangible reasons for people to switch too, because realistically the masses aren't going to care about the privacy or marketshare angles.
I don't see how Mozilla could "improve their promotion game" to stand up to that.
But that alone wouldn't suffice. From what I've seen of Mozilla's efforts to promote Firefox, they don't have any idea of how to appeal to the broader audience, or really any audience beyond the privacy-conscious. That Firefox allows better control of one's data is great but it's not nearly enough to carry most people past the friction point of switching browsers. For that you need things like major advantages in battery life and features that fix common web browsing annoyances.
Yes, and is also very IE like in that it's not evergreen, various iOS devices stuck on specific revisions that Apple has left in various states of broken.
i have an iphone with safari, firefox, firefox focus and chrome, ...
iPhones aren't allowed to have web browsers that aren't running Safari on the back end. They can have different names, different UIs, but at the end of the day it's the same browser.
I don't know why non iOS browser play the stupid pseudo support game with Apple, it just makes it confusing for users like the parent comment... playing into Apple's hand, helping them pretend that it's actually a fair ecosystem with choices.
That's easy. Users want their bookmarks, history, passwords, etc synced across devices, and so if there's no Chrome, Firefox, Edge etc for iOS to accomplish that on iPhone/iPad, people who have multiple Apple devices would likely switch to Safari and those users would be lost. Additionally, in the case of Google and Microsoft, they'd be opting out of those sweet, sweet streams of user data if they had no iOS presence. And so, those browsers exist, just built around WebKit instead of Blink/Gecko.
In my opinion this is not comparable at all, slightly differently or prefixed property/attribute names are really very acceptable to me compared to the hacks we used to implement. Having to hack for multiple IEs while also ensuring those hacks are not applied to other browsers was a special kind of evil to battle, and we are not just talking about "oh IE does not support this so we need to do this another way" but also things like "oh IE like to double the specified padding because why not" - and then at some point they removed conditional comments because they were like "IE is good now." which of course it wasn't.
I develop for Safari amongst other browsers daily and have for years, and do not share these frustration everyone else seems to have for it. Do I agree there should be more frequent updates of Safari (also for older MacOS)? Yes. Do I agree iOS should allow other browser engines? Yes. Is supporting older Chromium engines annoying too? Yeah of course, I've run into that as well (don't have any concrete examples right now unfortunately). People like to think that you can expect Chrome to always be the latest version because of the auto updating, but I have experienced multiple issues caused by users with a (very) outdated version. Whether or not you support these depends on your business / target audience, I had to, and it was frustrating.
Different browser engines will always be different and implement standards at different rates, and standards are often implemented before they are finalised and some do this with prefixes and others do not. Supporting multiple browsers is part of the job, if you don't like it you should not be doing front-end web development.
I for one would hate living in a world that is run by Google (Chromium).
I've experienced zIndex bugs, border radius bugs, form bugs, svg bugs and even dom event bugs.
I don't know how many of the people making this comparison actually had to deal with IE 5.5/6/7/8 support on a daily basis back in those days or what exotic things people are doing now.
Safari does feel like it has more rendering bugs yes, but I did also say in my comment that I believe Safari should have more frequent updates because bugs hang around longer. But then again, you are still not guaranteed that people always have the latest version anyway, even in Chrome.
I just don't get this comparison to IE and this is the first time I thought I'd comment on it, but in the future I will not do it again. The era of IE sucks, but IE was IE and Safari is Safari, Firefox is Firefox and almost all other browsers are Chrome. We are all allowed our own views on this and I should not have commented at all I guess.
Happy new year!
*: p.s. Apple should allow different browser engines on iOS
Totally broken indexedDB implementation. Random rendering issues, especially if you happen to ever use z-index. Hacks needed to get the most basic events to trigger. Idiotic scrolling behaviour. Choppy animations that didn't adhere to basic CSS standards (even the ones that weren't added by Google).
Honestly, it was a mess, and sometimes felt like a deliberate ploy to stop web apps from becoming viable. Things are better now. Just waiting for them to finally add web push notifications.
Try to put something in absolute on top at width 100% and height 100%, if you scroll down, the snapping goes further than the div...
It's that Safari is the only browser allowed on iOS. Which means that we are stuck with the subset of the standards that Safari has chosen to implement.
So Safari has outsized influence over which standards are actually feasible to build an application around.
One example: I've lost count of how long I've been waiting to build web apps that can send (user requested) push notifications.
Which, considering the alternative is Google having complete control over the web, I'm quite thankful for. It doesn't line up with how I'd like things to be in either case but it's much better for there to be some sort of check against Google. Google is far too aggressive about implementing new tech in the browser for very obvious reasons.
I’m not one to defend google, but in the matter of a datepicker… it’s 2023 for crying out loud! A datepicker standard should have been solved and implemented about 20 years ago.
Admittedly it’s non-trivial dealing with dates across regions, time zones, DST, etc, but c’mon, it’s been clearly solvable for decades.
Just because it doesn't exactly match up to the same scenario of IE6 doesn't takeaway from the point that you can develop for everything else easily, then must deal with Safari's failures specifically.
> https://github.com/minimaxir/hacker-news-undocumented/issues...
Can you elaborate on this? How does this happen, and is it a permanent de-buff?
Please don't do it again.
p.s. A comment beginning with "I hate these stupid parrots claiming Safari is the new IE" obviously broke the HN guidelines and therefore did not belong at the top of the thread. The moderation here was correct; your comment and laster destructive edit were out of line.
On the contrary, the things mods do—including downweighting top subthreads when they break the guidelines or aren't in the intended spirit of the site—are vital to why HN functions as well as it does (not that it functions particularly well; just that it could and would be worse). In fact, that process of downweighting top subthreads is probably the biggest thing we've ever figured out to improve thread quality, at least in recent years.
* Btw, if there were a way to have the community and software alone do what mods do, and thus eliminate the need for mods, that would be a day of great rejoicing on our part.
Don’t do that and tell me I’ve deprived people of context. You've already taken away from otherwise valid discussion about development with an industry and why this sentiment has proliferated by pushing my post to the bottom.
I could have also simply replaced the sentence with, "I don't like it when people repeat that Safari is the new IE," but HN doesn't have a recorded policy of restoring posts from downweighing.
If this is the only offending sentence, it seems like pretty shallow moderation to me.
“Edit out swipes” is a part of HN guidelines. I removed the post because clearly moderation found it fulminating, I agree it was, and now you seem to think you own my words.
If you have a problem with edits after silent moderation and believe this to be abuse, which contradicts current guidelines, just update the guidelines to include such a statement.
Perhaps it's unclear but the guideline there is about taking that stuff out before you post. The whole set of subsequent problems just goes away entirely if you do that which should be straightforward given there's agreement on the root cause - the posting of yelly comments.
The "edit out swipes" guideline is intended more along the lines of "please edit out any guideline-breaking swipey bits from your comment, while leaving the substantive point intact."
Tbh I think setting a default value might actually have been a better solution. It's not perfect, but hacking together your own alternative could lead to a number of issues for folks relying on screen readers and other input devices. The `type="date"` gives a lot of semantic meaning that `type="number"` lacks.
If you're gonna ditch it, I'd say at least use an existing external library that's been battle tested for accessibility.
https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...
From left to right, that's Chrome desktop, Chrome mobile, Safari desktop, Safari mobile, and Firefox desktop
---
The post specified that the users are mostly senior. Regardless of what they go with clearly 0% of their users benefit from leaving it to default today unless they somehow figured out how to sell smartphones to fetuses
But if you don’t set one then the value of the HTML element will be null before it’s selected. So if you add a required attribute then you can make sure that your users use the date picker (or leave in frustration after failing to do so) before submitting the form.
If you set a default value using the value attribute, then that becomes both the HTML default value and the UI default. IMO the spec is missing a way to just set the UI default, so that the field is default empty but interacting puts it at a sensible starting point.
There’s an MDN example here where the date starts empty and is required, if you try submitting the form you’ll see there’s no default for the HTML element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
EDIT: ignore the below. It was pointed out I misinterpreted defaultValue.
but there's actually also a `defaultValue` attribute which I believe behaves how you would like it to:
https://caniuse.com/mdn-api_htmlinputelement_defaultvalue
Ofc you can also use JS to make sure an input has been blurred or touched to pass validation on submit
Then yeah I suppose it'd have to be a javascript trick that sets the default value when the calendar is opened or, as GP suggested, something done at the standards or implementation level
I have no trouble figuring out how to pick by year because the rest of iOS follows a standard UX.
It seems more important to me to support the native accessibility of the phone than use an external UI vendor.
I am a huge advocate of family members and elders to purchase devices they are comfortable operating. This is why my grandparents primarily use their desktop computer for any important things, and their iPhones for messaging/video chat.
[1] https://daterangepicker.com
Here, too, Safari is the cause of 2/3rds of the lines of exceptional UI code now that Edge switched to a compatible render engine. Or blocks features altogether. All major browsers settled on doing things a certain way and then you remember that you always need to check Safari and of course they want it another way, so you get to re-do the work and duplicate your code with a comment "//because safari wants x to be done this way". I had less trouble with MSIE6 back in the day, though I can't rule out that I did less fancy things back then.
These things are not like "oops we render it differently by chance", it's conscious choices like not supporting SVG or being able to read file names in JavaScript (can't have javascript-based upload progress bars or local file encryption if you want to keep the filename; need to encrypt on the server and have the server report progress back via another channel).
What is the definition of “compatible” here?
The point of “one specification, multiple implementations” is to explicitly leave the door open for slightly deviant implementations.
There's the occasional situation where Chromium doesn't support something or Firefox doesn't support something, but it feels like Safari has double the rate of both combined.
If Firefox had the marketshare of Safari and was mandatory to support because they were a major platform’s browser devs would be cursing their name too but with a different set of things that aren’t exactly like Chrome.
It really does feel like devs are literally developing against Chrome with not even so much a thought at cross-browser compat or a glance at caniuse and then taking their finished site and then working backwards from there on other browsers cursing the compatibility issues when they could have avoided it entirely had they started with a cross-platform subset of browser features. Just the same as how cross-platform native development works.
Hell someone did all the hard work for you https://github.com/amilajack/eslint-plugin-compat
Then multiply by all the npm packages blindly imported that were developed with the same methodology and I see where the rage comes from.
Safari (mobile), however, will be broken. Firefox on Android often breaks for more complicated stuff, but works better in my experience.
Uh, it kind of is? At least, I use Firefox exclusively and thus also support it when developing things.
The browser I have trouble with sometimes is a webview skin on mobile (whose engine is blink or whatever it's called nowadays), there some sites block the http user agent string for some reason or it's missing some advanced this or that and I have to switch to mobile firefox which is a lot slower.
> Can any browser that is not a reskin of Chrome with feature and bug-for-bug parity actually satisfy web developers at this point?
Uh, yes? Firefox? I don't understand your question.
Not “compatible”. The same render engine.
Edge is essentially just Chrome with a slap of Microsoft paint.
That’s nice for uniformity, but having all browsers use the same engine is not good for the health of the open web. We do not want Google as a single point of failure any more than Microsoft.
90% of the annoyance could've been dealt with if they had just chosen a default date value of, say, Jan 1960 or so.
Maybe the real solution is a simple explanation for how to use a date picker component. It'd help those users not just on this site but on many other sites in the future.
Tbh I don't really know what improvements could be made to the picker itself. It looks pretty consistent with the implementation of most other browsers and OSes and even most native components I've seen
I'd love to hear actual thoughts on improvements though
I feel like the data is flawed. This is (supposedly) 1/3 of tech issues raised by customer support — how many of which are total?
I have gripes with Safari, but date pickers isn't one of the things only Safari struggles with.
An image search for 'android date picker' brings up at least three different designs: https://i.stack.imgur.com/3DW4n.png https://i.stack.imgur.com/LLRmB.png https://i.stack.imgur.com/kJqln.png
It seems like the first screenshot is `type="time"` and the second and third are `type="date"`. But I don't know if those are native components or the browsers defaults. Would be useful information
https://snipboard.io/8fL9Kl.jpg
That 2018 and the top left gives you a selection for all of the different years
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
But yeah that's a good point. I'm on Firefox on Mac and it looks pretty much exactly the same. I don't really get why other browsers wouldn't be causing the same issues
From the screenshots it seems like they're talking about users on a mobile device. iPhones only allow you to use WebKit, but I'd be curious to see what Android's date picker looks like
I feel like they could've just saved themselves the headache by setting the default value to 1950 or something
Video: https://imgur.com/a/W196T5f
iOS keeps the input on screen, so you can see the value in context. Android covers it up, and shows the value in a different format in the header.
iOS shows the Month+Year inside the calendar, with a blue arrow beside it to indicate interactivity. It’s not a strong affordance, but it’s something.
On Android, nothing gives any such affordance.
Blindly tapping the month+year in the calendar does nothing.
Blindly tapping the day or month on the header does nothing.
The year looks similar to the day and month, only smaller, and slightly darker grey. But if you tap it, you can scroll through the years.
There’s no way to scroll through months – the only option is to tap through them one at a time.
Firefox and Samsung Browser are basically the same thing with different colour schemes.
Samsung managed to make the year seem even less tappable: https://imgur.com/a/2q4CiXk
Also wild how this post is singling out Safari when Android seems to somehow be even worse
My guess is that it is selection bias. Older people are probably more like to use iOS devices, since they are marketed as being simple to use and maintain. So, they don't hear too many complaints about Chrome on Android, even though it's worse.
So, typing in Y/M/D is better in most cases for DOB than drop downs, unless maybe it's dropdowns for [YYY][Y], then [MM] and [DD]? Or how about start with "How old are you" and then get me most of the way there on the picker? :-)
But the standard implementation does make it very easy to navigate to a different year as pointed out in the blog post. The issue was that elderly folks don't always find it obvious how to do so. However, looking at the alternative implementations from Chrome and Android,[0] I don't think any other browser has made it any more obvious...
[0] https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...
They didn’t just have a few bugs in their browser implementation or were slow to implement new features.
Basic, crucial CSS features were broken. Microsoft didn’t add any new features to the browser about a decade, basically holding the entire web back to the standards of circa year 2001 until it was finally safe to drop support for it almost a decade later.
And furthermore, Microsoft weren’t pushing users to upgrade to the latest version, so we had to support older versions of IE long after their replacements were released.
I understand wishing that Safari would be better, but luckily the Safari team is much more on the ball than the IE team ever was.
It's not my experience as a web developer. It's 'a lot' at best. And not only in js, but also in css or literal anywhere you might interact to.
It always requires a few workaround when I finished the page in other browser. Firefox or Chrome, in the other end. If your page works on one of them, it will pretty much just work on the other.
Safari is probably 50% of my bug ticket, almost equals to every others sums together.
Write a page for safari really reminds me the age IE is still a thing.
I'd be very curious to hear some common issues you have to deal with
I think Safari isn't broken in the ways IE was, because IE always had comptetitors running along it and pushing the enveloppe where Microsoft was pulling the brakes. Firefox and later Chrome were handicaped in adoption, yet had little to no limitations on the features they wanted to add.
In comparison no other browser can run with the same privileges as Safari on the phone, while the iPhone is a dominant platform. So there just isn't the same space to innovate in a profitable way. The only company who can afford pushing the envelope is Google, and at this point their only real competitor is Firefox, that they basically pay to keep alive. They also have little incentve to really push the web as it doesn't impact their bottom line (native app ads also go in their pockets afterall)
I have submitted 10s of webkit bugs and most of them will never get fixed.
New bugs randomly appear in every OS update.
5 year old cheap android device can handle complex webpages really well, but my 1500 eur brand new iPhone runs out of memory. iOS Safari is really buggy.
I work with online maps.
I know there's good faith work around WebKit, etc., by smart and genuine people. But it was easy to wonder (especially with the anger that comes from being existentially threatened) whether some element at Apple wanted to make Web apps work badly, to keep the proprietary App Store party going.
(I did pull it off successfully, but only with much heroics.)
However, OP complaining about usability and the providing three text fields with the MM and DD being placeholders is terrible. Normally placeholder-only labels are a bad idea, but this is especially true when the month and day fields have different order depending on the region. The moment you've got [1] [4] [1980], you no longer know which is month and which is day.
And do they swap these placeholders and entered values if you change the country from US to an EU country?
The lack of progress in the tech world in making consistent user interface standards is disappointing. We should not be still struggling with these topics (and as users we should not be suffering). Tax time, trying to fetch reports from banks/exchanges is one of the worst recurring experiences...
I don't think this is so much a problem of UI not being consistent as us just not providing resources to help elderly navigate the web better.
Also, they could've just... set a default date of like Jan 1, 1960 and saved 90% of their users a headache
Edit: ok, not "exactly" the same but functionally very similar. Or at least they'd have the exact problems pointed out in the post. See for yourself:FF: https://blog.nightly.mozilla.org/files/2017/06/input_date_ca...
comparison: https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...
I'm not sure how that really helps? Moving multiple years is still going to be a huge pain, so you're only really saving people who have a birthdate in or very close to that same year.
- provide some helpful text explaining to users how to switch between years
- use an external library with a custom date picker
The reason why I wouldn't recommend the approach they went with is because there's all sorts of aria-related properties and semantic meaning for screen readers that type="date" carries. This is especially relevant for the target audience they're talking about. I guess the third option is
- what they did but actually try it with a screenreader yourself. Make sure your aria labels make sense and is navigable for both keyboards and screenreaders (two separate issues). Also make sure you're replicating the validation logic that type="date" gives us for free. Basically replicate all the complex HTML5 logic and semantics
They look nothing alike though.
Are you trying all three on iOS? On iOS Apple only allows a single rendering engine (WebKit), so Apple dictates what the <input type="date" /> entry dialog looks like, and there's nothing other "browsers" on the platform can do to fix it (since they're just shells built on top of WebKit).
Would you mind providing a screenshot of how it looks on a different OS?
Edit: I've google around and I'm only finding UI that looks the same so now I'm very curious about what UI you're seeing that looks different. What browser and OS are you on if you don't mind me asking?
Firefox https://i.imgur.com/j8djrhN.png
Chrome https://i.imgur.com/mmBInsQ.png
Both different, both slightly better (because it's clearer the year field is a drop-down) than safari from TFA. I find FF to be the best usability-wise
Safari on desktop is pretty bad but at least it leaves the text fields there for you to just type in https://i.imgur.com/NSRvPcm.png
https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...
I do think Firefox does it best if the whole issue here is just that the year-month picker needs to more obviously look like a drop-down
I agree that would be an improvement, but tbh it doesn't seem substantial enough to fully prevent the issue that the seniors in the OP were facing
The "correct" direction for mobile safari would actually be left, IMHO. Mac and iOS (as well as the iPod and watch) use navigator patterns heavily, where left to right you have a stack of screens with progressively more detail. So it would make sense to have a MMYYYY view, which opens into a monthly calendar, which goes to a time of day.
"Correct" in quotes though because the date/time information is directly manipulatable at every level (it is a picker, after all). Turns out the best level to start at and affordances to pick a date in particular differ by use case.
For instance, the iOS Calendar app has a years view, but it shows a full yearly calendar, one per screen, and makes you swipe 15 pages up to see if you had any calendar entries from the first iPhone.
This makes sense from a calendar point of view, because it is far more common to want to navigate within the same year or previous year than to want to visit your calendar from 15 years ago.
It would be an absolutely terrible interface for seniors to enter their birthdate; far worse than the default here in fact.
If you enter a birthdate in the Contacts app, you get the "three tumbler" interface (for Gregorian calendars, at least) - months, days, and years, presumably in a localized order with localized text.
It is somewhat unfortunate they didn't just stick with this for the iOS Safari interface, as form input entry already expects that a good chunk of screen real estate will disappear for the keyboard. Instead, they went with a floating picker because thats what most websites currently implement (via javascript)
https://wd.imgix.net/image/vvhSqZboQoZZN9wBvoXq72wzGAf1/uh0U...
I'm really struggling to see how any of these alternative implementations are an improvement as they seem functionally exactly the same.
Yes both Chrome and Safari's implementations suck, but I feel like seniors would have a hard time with pretty much all of these. Firefox is clearly the winner here, but I'd imagine would still trip many seniors up
I haven't tried it, but I imagine you can manually override an `<input>`'s onFocus to not call `e.target.showPicker()` when it's focused on. This would likely allow users to keyboard enter an amount instead
Might be annoying for users that actually know how to use and prefer the picker however.
It does not seem that most websites use the built-in date pickers. I've seen dozens of different date pickers all while using Firefox. This is the key problem.
At least if everyone used the browser native date picker, it would be consistent within that browser. Then we could debate about which browser had the better one (and maybe standardize).
The solution is to use words instead of numbers for Month. I dont care which part of the world you are from and how the date settings differs. Months are only show up as Jan, Feb, March Etc and not 01, 02 , 03.
And always show 4 digit for years as YYYY.
Except for the vast majority of the world that doesn't use the English language.
> Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive.
For what it’s worth, whenever I have to write a date on an American-authored form, I use YYYY-MM-DD, as do all my colleagues.
To reiterate, there is an obvious, correct implementation here: let the site specify the content culture much like it does the language, and fall back to the user's choice when unspecified. The spec is asking for user confusion and data corruption as-is, which contributes to why usage of date controls remains fairly low.
https://dontplaywithculi.netlify.app/readlater
(it doesn't do anything, just a UI experiment)
Not everyone uses the Julian calendar, or even 4-digit years. Here in Japan, this is year 4 of the Reiwa era, so you need a year picker that lets you choose the correct era (Reiwa, Showa, etc.) and then the year of that era, and of course the number of permissible years per era differs greatly. (The era reflects an emperor's term, so when we get a new emperor, we start a new era.) Then, just because this system is such a PITA and anything international doesn't use it (but everything government-related does), we need a converter that lets you convert between the Japanese standard and the Julian calendar.
Almost nobody does. You probably mean the Gregorian calendar.
The one true date format is YYYY-MM-DD
Yet that's not how browser controls work - browser controls for all major browsers always use the client's date formatting settings when displaying dates (once popped up it's usually obvious which is which). And that just makes them pretty much unusable; it means outside of the US you will have dates in text using 1 format, whereas browser controls use a different one. That's... completely unusable. How all three of the major browser manufacturers managed to agree on this particularly hostile design is beyond me.
What is odd about it other than being different and not being immediately lexically sortable in file names?
Edit: It's an honest question. People and context help determine what you're wanting out of a date, so I am curious what is viewed odd about the U.S. format aside from it being not what your country uses or what the ISO standard is,
What I like about it is that it arranges things in order of importance/relevance in most situations. The month tells me the most important bucket, the day clarifies the particulars, and the year locks down the date but it is almost always known in the given context. In my opinion, there is the one true format for data formatting and text representation (the ISO standard), but each of the various permutations do have their use cases where they shine. For normal dates, all three components are needed, but it is usually nice to know the month, then the day, and then the year is there just to be clear. Knowing the day gives me little information until I have the month, whereas getting the month first gives me more information, where sometimes I can even ignore the day.
In my experience, the thing which is the most important/relevant in most situations is the day of month. People often say things like "dia 10" when asked when something is going to happen; that means in context the 10th of the current month if today is the 9th or earlier, or the 10th of the next month if today is the 11th or later. The month is added only when necessary, like "dia 10 de fevereiro" (just "dia 10" today would mean the 10th of January).
When are we back at work? On the second. Then go-live is on the fifth of March. (Normally 5 March or 5th March when written.)
Are you telling me if you had file cabinets for the last 50 years, and you had to get a specific file Nov 1992, you would rather sort first and get all the files marked "November", and then sort through those 50 to get to the 1992 November? Surely one would reduce down to the year - 1992 - first, and then to the month.
Same for alphabetical ordering, a data list ordered by logname-MMDDYYYY.log alphabetically wouldnt be chronological order - YYYYMMDD or DDMMYYYY would.
Month is primary in some cases sure, but I think year and day endian are primary in many others - plus have the above sorting and ordering benefits.
> each of the various permutations do have their use cases where they shine
The evolution of the US ordering feels (I might be wrong!) similar to how spoken numbers are little endian from 11 to 19, yet big endian from 21 to 99. Some languages are even worse in this regard; but regardless, they're unhelpful historical artifacts that we learn to live with, not actually helpful, well-thought-out, or even merely irrelevant. Notably there are considerable differences between how quickly children learn maths in different languages, and digit ordering may contribute (of course other cultural factors may contribute too). I wouldn't be surprised if date ordering too is similarly a small but real drag on learning.
A spoken language full date format for me would be like "third november 2022". That, in either in english or in my native language.
I don't know how circular this argument is (does the spoken form come from a written form of the date?). But this is what makes it odd, that in spoken form I, for example, am used to saying the date first but the "odd" date format writes the month first.
I’m curious about the circular reasoning as well, as the same would hold true for both preferences.
Do you mind sharing what language you speak where the day is most often said first? It sometimes is said that way in English, but not as often as the other way around. It’s usually said that way when the day carries higher importance than normal. Like the 4th of July or something.
The languages I know how to say it in are all closely related to Swedish but they agree. And then Spanish uses day first too.
I suppose that the ordering of dates is independent of locale.
The locale rules for the date format are simple: the DOM value property of the field is a string in YYYY-MM-DD format, independent of locale.
The date display format and what the text input accepts depend on browser locale.
Conversion happens automatically and the text input is shown in a way that indicates locale on desktop, least I remember (e.g. dots for European format, slashes for US). If a user enters "1.5.2011" in a browser with German locale, HTMLInputElement.value would be the string "2011-05-01" (invisible to the user).
I honestly can't think of any better choices, the only thing missing is some attribute to eplicitly control display locale. Which is probably by design, as it would be abused to override system/browser locale and create confusion.
I once replaced a Vue date picker library in a web app with native date inputs for UX reasons (e.g. typable dates, reliable visibility of the picker when fields are near window borders, mobile UI...) and users were reportedly happy with that.
Admittedly, it was mainly a desktop app.
So, long story short: the only problem I see here is the mobile modal date picker UX. And thankfully, it can be improved in the future because it's part of the OS and not controlled by the website.
day/month/year
month/day/year
year/month/day
year/day/month
The order of the numbers an be problematic. For example, 01/01/01 could be 1 Jan 2001, Jan 1 2001, 01 1 jan, or 01 jan 1.
Would rather not do the april fools example. Or the pi day example.
You are talking about locale-dependent formats - which is why the value property of the input element conforms to ISO 8601 YYYY-MM-DD and guarantees that the values are predictably sortable.
There is no other meaningful ordering of dates other than sorting chronologically.
HTMLInputElement with type=date honestly does everything right given the constraints.
As said, this post is a valid complaint about mobile native UI, no less no more.
Actual human language is context sensitive. The user's date formatting preference is almost a non-sequitur even as a concept. People fundamentally can't pick whatever date formatting they want in general-purpose content; they'll need to be able to understand whatever is the norm in that context. And in most contexts while there are various date forms, they're usually not (problematically) ambiguous. As long as a user stays within one date-formatting bubble, that's fine, but it just works really poorly if a user does not. Within an application that's primarily concerned with dates and in which every date is a specially typed value, like say a calendar - sure, date formatting preferences are feasible. That however describes a rather small fraction of the overall web. And the textual, machine-comprehensible hypertext web itself, while eating the world, is itself still only part of culture; dates are visible in videos, images, books, magazines, etc - and they make sense in those contexts _in context_ - i.e. _not_ using the client's date formatting preferences.
If a user's date-formatting preferences were to really have meaning on the web, you'd need to ensure that even dates in plain text or written summaries satisfy that formatting, and hope that videos and images rarely are mixed with such text. But that's just not the norm, and likely completely impractical; it'll never happen, especially not given the reality that many dates are manually written by humans without any markup at all. And where software tries to "fix" that - well, you get disasters like Excel, which is notorious for causing insidious data-corruption by trying to guess data-types in pretty creative and unhelpful ways.
In practice that's not what sites _actually_ do. They either have really simplistic date handling, in which case date controls can be confusing but rare enough that it's not hugely impactful, _or_ they use custom date controls (the actual norm). And that makes browser date controls _even_ worse, because those will then unpredictably not use the context culture, but instead the client's culture - unlike most sites, which don't use input type=date as far as I can tell.
The correct solution would be to allow a site to specify the site's culture and formatting settings, much like language can be specified. And if none is specified: sure, fall back to the user's date preference.
MS deliberately added non-standard crap to get everyone off the rails when not using IE. That's why websites often showed "Best viewed in 1024x768 and 16M colors using Internet Explorer".
And that is a remark I see more often every day. And it's Chrome being recommended.
Remember why MS switched from EdgeHTML to Blink? Because Google would hamstring EdgeHTML at every corner on their services. Not completely break it, but make Gmail or Youtube a tad slower than in Chrome.
"Don't be evil" my ass.
I'm not exactly condoning, nor condemning, that behavior, but there's a little part of me that wants to say to Microsoft: "not so funny now, is it?"
Is there documented evidence that Microsoft stooped this low as well? Did they purposely make their sites not work as well on other browsers?
This technique also fixes the issue where a Safari Mobile date picker defaults to todays date, for example when using > to move through existing dates that are empty (clicking Done unobviously picks today - often not what you want). Terrible UI for fields like birth date or employment end date. Although depends a bit on whether a blank date makes sense.
Oh, and be really careful of type=number on Safari - it silently fails. inputmode=xxx can help, but it has weird differences between devices last time I looked (versions, Android, iPad etcetera). My mum repeatedly failed to enter a dollar value into a type=number, because she was entering a thousand’s comma (the UI showed $ and , everywhere for numbers so it is a sensible mistake to make; although Safari will display the entered number in the input field the .value==0 —— arrrgh silent failures are hideous).
I hate Mobile Safari - buggy, impossible to get bugs fixed, relatively poor standards support e.g. still need -webkit- prefix for some standardised CSS from a decade ago. Oh, and you end up with people using obsolete phones stuck on old Mobile Safari versions. Android updates Chrome even if it doesn’t update the OS (although Android also has the problem, it is less of a problem).
Just set a default date and it won't default to today.
The date picker in the image is basically the exact same as Firefox and Chrome's implementation minus some stylistic differences.[0] Most native components also look a lot like this. So this isn't just a Safari issue but an issue across web UI in general
[0] See for yourself: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Better configurability which would let the author decide whether they want a calendar or a straight date input. Though I'm not sure iOS even supports a calendar-less date input anymore.
This is what the "date" control looked before iOS 14: https://i.stack.imgur.com/ms5tX.png
Rolling back the entire "flat" shit would probably be a good idea: before iOS 7, the control was functionally similar but had a lot more visual affordances: https://www.andyibanez.com/img/date_picker_pre_7.png
It was much clearer that the central shade is an index, and that the three fields are separate wheels. The iOS 7 picker makes it much subtler by simulating curvature, and the new sub-selector (year-month) does the same and makes the index kinda even worse by outlining it in an abstract shape: https://user-images.githubusercontent.com/6268177/209607212-...
I am not suggesting my solution is perfect, but I am saying I have successfully used it (although I admit is was a few years ago now, and I first used it was when iOS and Android type=date support was unpredictably broken so type=date must not be exclusively be used). I think it was about iOS10 before the bugs in the UI to clear dates were fixed? Another situation for me was New Zealander’s confused by MM/DD/YYYY native formats when using browsers configured for US date localisation.
Until April 2021, Safari on Mac didn’t even support the date control, and Safari (on Mobile or Desktop) still doesn’t support the min or max value attributes. And time entry is a complete nightmare. I always try to make sure data entry controls work well for everybody, even console devices.
There are always corner cases that somewhat depend on your particular users, so compromises are necessary.
Background: I have programmed HTML entry controls (combo, date, time, number, etcetera) for actual man-years of my own life. That is because I started before jQuery existed, supporting IE5.5, and the available DHTML controls were mad broken for usability. I have had to understand the compromises between different solutions on different browsers, and try to find the most elegant solution, given that data entry on browsers is an extremely gnarly problem space.
I'm just pointing out it's not easy to implement just to get the logic and styling to work right. And then on top of that, making sure it's screen reader and keyboard accessible adds another layer that is often simply ignored
The simpler solution I put forth resolves most people's problems, maintains the advantages of using native HTML controls the way they were meant to be used, and is easy to implement in... literally a few seconds.
Custom entry fields have different compromises (oh defuckinently), and trying to be too tricky leads to corner-case usability problems and a heavy maintenance overhead in my experience. I judged it was worthwhile for our users’ needs at the time for me to spend very significant development time plus ongoing development time, but my choices would be totally inappropriate in many other situations.
That's exactly what's happening here though, Safari shows the platform's widget.
> Just set a default date and it won't default to today.
That's not really helpful either, DOBs have wide ranges of dates so the need to switch year, possibly decade (as this is for the elderly) will always come up).