-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Add meta viewport support data #25392
base: main
Are you sure you want to change the base?
Conversation
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.
Overall, this PR seems to missing some references for the determined support statuses.
"__compat": { | ||
"description": "content=\"height=[value]\"", | ||
"mdn_url": "https://developer.mozilla.org/docs/Web/HTML/Viewport_meta_tag#height", | ||
"spec_url": "https://drafts.csswg.org/css-viewport/#viewport-meta", |
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.
Either omit the spec_url (if it's not specific to this feature), or use a Text Fragment:
"spec_url": "https://drafts.csswg.org/css-viewport/#viewport-meta", | |
"spec_url": "https://drafts.csswg.org/css-viewport/#:~:text=width-,height,-initial-scale", |
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’m not sure that linking to a specific list item fragment is more useful (i.e., it gives more info) than linking to a dedicated spec section. We will have to update links when the spec matures either way.
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.
In the BCD call on October 29, we decided to use text fragments where anchors aren't available. Although this was in the context of behavioral subfeatures, I see no reason not to apply the same here.
I don't think it makes sense to repeat the parent spec_url
.
"chrome_android": { | ||
"version_added": "18" | ||
}, |
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.
How did you determine this given that the Chrome Android 18 release notes don't seem to mention these features?
"firefox_android": { | ||
"version_added": "4" | ||
}, |
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.
Same question, the Firefox 4 release notes , including the full release notes, don't seem to mention these features?
"opera_android": { | ||
"version_added": "10.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.
The Opera Mobile 10.1 Beta release notes mention viewport
, but don't seem to mention height
.
"safari_ios": { | ||
"version_added": "3" | ||
}, |
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.
Similar question: What makes you think Safari iOS supported this?
"chrome": { | ||
"version_added": false | ||
}, | ||
"chrome_android": { | ||
"version_added": "18" | ||
}, | ||
"edge": "mirror", | ||
"firefox": { | ||
"version_added": false | ||
}, | ||
"firefox_android": { | ||
"version_added": "4" | ||
}, | ||
"ie": { | ||
"version_added": false | ||
}, | ||
"oculus": "mirror", | ||
"opera": "mirror", | ||
"opera_android": { | ||
"version_added": "10.1" | ||
}, | ||
"safari": { | ||
"version_added": false | ||
}, | ||
"safari_ios": { | ||
"version_added": "3" | ||
}, |
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.
Same questions
"oculus": "mirror", | ||
"opera": "mirror", | ||
"opera_android": { | ||
"version_added": "10.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.
✅ LGTM.
"version_added": false | ||
}, | ||
"safari_ios": { | ||
"version_added": "3" |
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.
✅ LGTM.
"version_added": false | ||
}, | ||
"firefox_android": { | ||
"version_added": "4" |
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 above.
"version_added": false | ||
}, | ||
"chrome_android": { | ||
"version_added": "18" |
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 above.
As we discussed on the BCD call, this PR is a starting point in a long investigation and testing process. All early browser versions I provided have some degree of uncertainty unless we actually test it. Unfortunately, I don’t have the resources for such testing. But I think “the first best guess” would still be useful.
When it comes to mobile browsers, the meta viewport was an opt-in solution (invented by Apple) for browsers to render adequately scaled pages on mobile. All early mobile browsers had to mimic Safari’s viewport implementation to be compatible with the mobile web of that time. Unfortunately, the early release notes are lacking details and cannot be used in the “if it’s not mentioned, then it’s not there” way. That’s why the first best guess here is:
The first mobile browsers of that time. By the way, here’s another PPK’s compat table I found that might be helpful. |
I haven’t done any testing. I only have release notes: |
My apologies, if we discussed to add specific version numbers, although we're not certain, then let's do this. Otherwise, I would prefer to test in some version we're certain it's supported, add a range using that version instead, and create an issue with the used test case for further narrowing down the versions in the future. |
Yep, there’s a high level of certainty that the initial mobile browsers were shipped with the viewport support. We can revisit it once we’ve done the testing. I brought it up again on today’s BCD call and got positive feedback from @Elchi3. With all that, I’m planning to resolve all comments regarding the initial support versions and address the |
Summary
Adds missing support data for
<meta name="viewport">
.Test results and supporting details
This PR assumes that Mobile Safari 3 for iOS shipped the first
<meta name="viewport">
implementation, and all later released mobile browsers followed.There’s a
viewport-fit
feature that Safari 11 presumably shipped. I just learned that Chrome is planning to ship it soon, too.Related issues
Fixes #25311