3 ms·
When the date spans a wide possible period, like birth date, this approach doesn't solve the root problem.
by bruce511 4y ago
When the date spans a wide possible period, like birth date, this approach doesn't solve the root problem.
- culi 4y agoRight, 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 [0] See for yourself: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
- masklinn 4y ago> What do you think would be a better solution? 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 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 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-4ca5bc8a-d5c3-4a9b-891f-78f4e1ed4be8.jpeg https://user-images.githubusercontent.com/6268177/209607212-...