Improving Chromium's browser compatibility in 2020(blog.chromium.org) |
Improving Chromium's browser compatibility in 2020(blog.chromium.org) |
https://twitter.com/sroussey/status/1273341472398381056?s=21
Really, if they have these kinds of problems, then the rest of us... :/
When finding things like this file bugs at https://crbug.com/new
I have mixed feelings about Microsoft giving up on their browser. On the one hand, it will make things more compatible and reduce effort for us. On the other, it's one step closer to a monoculture controlled by Google. I would prefer that Microsoft simply get their shit together and make a good browser.
* Still no real combobox. <datalist> is only a half-way solution.
* <optgroup> should be nestable - rarely do things fit into only 2 levels of depth.
* Biggest pain of all: Radio-button events.
This is a real pet peeve of mine. Perhaps there is some good reason, but as far as I can tell date pickers work well in chrome and firefox, and not having one in safari means you need to add javascript to your page and/or do some nasty server side user agent sniffing stuff to try and make sense of dates.
We expect it'll be ready for testing in a few months. However we expect that it'll be a bumpy rolling this out as table layout has a long history, and isn't exactly well defined :).
- Ian
Here's the official WebKit Bugzilla ticket for `<input type="date" />`: https://bugs.webkit.org/show_bug.cgi?id=119175
Here's Apple's Radar entry: rdar://problem/14567780 (I don't have access to Radar - can someone who does please let us know what the latest update is?)
Right now we use a quick-and-dirty date polyfill for macOS Safari - though more recently our GA stats show that 90% of our macOS users are using Chrome anyway which supports date inputs natively so for our lesser-used pages and areas I might forget to add the polyfill and we won't hear any complaints.
It's kinda mean to do that though - if that is the case then they're deliberately holding back the web, increasing web-development time, and worsening accessibility (so many inaccessible JavaScript date-picker components!) just so that they can avoid "looking bad".
Kind of like the way they refuse to support open formats like WebGL2, glTF, webP, various compressed GPU texture formats and probably lots more I'm not aware of.
Apple devs always answer "we're working on it" when pressed on these issues. But after several years of seeing the same half-hearted answers these assurances start to ring hollow.