-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updates for Safari 14.1 on macOS and Safari on iOS 14.5 #10129
Conversation
@@ -33,10 +33,10 @@ | |||
"version_added": false | |||
}, | |||
"safari": { | |||
"version_added": false | |||
"version_added": "14.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! Thanks to @svillar for closing the gap in flexbox 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed some of the trickier bits, I'll come back to review all the other changes after upgrading to macOS 11.3 :)
browsers/safari.json
Outdated
@@ -173,6 +173,19 @@ | |||
"status": "current", | |||
"engine": "WebKit", | |||
"engine_version": "610.1.28" | |||
}, | |||
"14.0.2": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #8838 for a previous discussion on how to handle MediaRecorder
and iOS 14.3. The conclusion then was to treat it as a minor version and live with a little bit of inaccuracy in the data.
But if the Safari teams considers these versions significant and would like to add them, that's a decision that should be revisited. cc @ddbeck @Elchi3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that pretty well summarizes it, but I can add some additional detail:
https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#release-lines-and-backported-is our best effort to document our thinking with which versions to include. If I were writing it today, I'd probably add some text which speaks to the question: will web developers be making a distinction between version X and version Y version in a year or two?
(I think during a call back in March, it was suggested that that 14.0.3 was a significant release, but there wasn't really a story for testing the difference between it and other 14.0.x versions. This suggested to me that developers won't make the distinction either. I'd expect similar problems for any 14.0.x.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are opting for fudging this data and using "14" in cases where 14.0.2
appear or safari_ios
shows 14.3
.
Oops, I submitted that review too early by accident. The rest is coming in a second batch :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've gotten through all of api/ now. Taking a break, because this was very time consuming :)
I anyone else wants to review css/ and later in detail, that would be great.
OK, with this many review comments I realize it's going to be hard to make sense of. To summarize the state of the API data, there are a bunch of minor errors that I've suggested fixes for, and one interesting decision to be made about whether to have "14.0.2" and "14.3" as their own versions. @apple-web-evangelist some of my comments are just confirming support or noting something interesting. Feel free to resolve those when you've read them to get them out of the way. Also note that GitHub will unhelpfully hide comments when there are lots of them, so somewhere in the middle there will be "Load more..." links to click. |
@foolip Thank you so much for taking on a big chunk of the work here. Makes this PR feel a lot smaller. 😄 I'll take a look at the CSS (and the interesting decision stuff) more closely later today. 👍 |
|
This is all great feedback. I'm working through incorporating the suggested changes based on your findings @foolip. Thanks for the additional verification. @json-derulo Also a good catch! I will incorporate that change as part of this PR as well. |
This looks good. I had earlier created a PR for JavaScript classes which also included updates to "static" and "static fields" sub-features which are currently missing from this PR. |
In addition, there is also data missing for In the case of |
browsers/safari.json
Outdated
@@ -173,6 +173,19 @@ | |||
"status": "current", | |||
"engine": "WebKit", | |||
"engine_version": "610.1.28" | |||
}, | |||
"14.0.2": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that pretty well summarizes it, but I can add some additional detail:
https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#release-lines-and-backported-is our best effort to document our thinking with which versions to include. If I were writing it today, I'd probably add some text which speaks to the question: will web developers be making a distinction between version X and version Y version in a year or two?
(I think during a call back in March, it was suggested that that 14.0.3 was a significant release, but there wasn't really a story for testing the difference between it and other 14.0.x versions. This suggested to me that developers won't make the distinction either. I'd expect similar problems for any 14.0.x.)
Performing another pass to address @ddbeck's comments. |
With regards to the new date/time input support. You don't appear to have changed the time input to show it's supported as of Safari 14.1. |
A follow-up commit will include it. Thank you for pointing it out that it didn't make it into our the data. |
css/properties/aspect-ratio.json
Outdated
@@ -69,7 +69,7 @@ | |||
"version_added": false | |||
}, | |||
"safari_ios": { | |||
"version_added": false | |||
"version_added": "14.5" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The aspect ratio experimental feature is disabled for me on both macOS and iOS. Is this not the case for others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://mdn-bcd-collector.appspot.com/tests/css/properties/aspect-ratio shows support for me on iOS 14.5, but feature detection can be broken.
Some of the basic test cases in https://wpt.live/css/css-sizing/aspect-ratio/ aren't passing, so I think most likely the property is recognized but the actual behavior is gated by a flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I verified that this is just wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 90183cb.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And I've updated mdn-bcd-collector in a way to avoid the WebKit bug leading to this false positive in foolip/mdn-bcd-collector#1132.
Confirmed with https://mdn-bcd-collector.appspot.com/tests/api/OfflineAudioContext in Safarai 14.1. This was missed in #10129.
Confirmed with https://mdn-bcd-collector.appspot.com/tests/api/OfflineAudioContext in Safarai 14.1. This was missed in #10129.
This is a large update of features supported with the release of Safari 14.1 on macOS and Safari on iOS 14.5. The changes have been compiled using mdn-results-collector, a thorough review of changes by the WebKit engineering team at Apple, manual tests to verify results, and engineer submissions.