Add meta viewport support data

[pepelsbey]

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.

• Firefox 4 for Android
• Chrome 18 for Android
• Opera Mobile 10

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

[pepelsbey]

Overall, this PR seems to missing some references for the determined support statuses.

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.

What makes you think [browser] supported this?

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:

1. Safari 3
2. Firefox 4
3. Chrome 18

The first mobile browsers of that time.

By the way, here’s another PPK’s compat table I found that might be helpful.

[pepelsbey]

How did you determine [interactive-widget] support in Chrome/Firefox Android?

I haven’t done any testing. I only have release notes:

• Chrome 108
• Firefox 133

[caugner]

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.

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.

[pepelsbey]

if we discussed to add specific version numbers, although we're not certain, then let's do this

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 spec_url ones.

[caugner]

With all that, I’m planning to resolve all comments regarding the initial support versions and address the spec_url ones.

Thank you, please ping me when you're done.

[caugner]

@Elchi3 @ddbeck @queengooborg Do you have an opinion on where the viewport-related content attribute values should go? (See my comment above.)

[pepelsbey]

We decided to restructure the viewport support data a bit, so marking it as a draft for now.

[pepelsbey]

I moved all viewport members and values into a subfolder (viewport_meta in meta/height.json), just like it works with input (type_button in input/button.json) but for some reason I get this error:

✖ html/elements/meta/height.json - Error → Expected only "html.elements.meta.height" but found "html.elements.meta.viewport_height"

I wonder why the same principle works for input types but doesn’t for meta viewport members.

Also, added support info for viewport-fit values shipped in Chrome 135.

[caugner]

@pepelsbey The file path must reflect the BCD feature path. You named the subfeature viewport_height and the file height.json. Instead, add a subfolder viewport/ and make the feature viewport.height.

[pepelsbey]

The file path must reflect the BCD feature path

@caugner but why does it work in the other case? The key in input/button.json is called type_button. I basically copied the principle. Maybe I'm missing something.

[caugner]

TIL about these special cases: https://github.com/mdn/browser-compat-data/blob/059828cba0dc8d85283f6d5cd022a66a9fc39abb/lint/linter/test-filename.ts#L52

[pepelsbey]

TIL about these special cases:

Would you recommend adding another special case (I don’t like it, to be honest) or getting rid of them altogether? I’ll bring this up next week.

[caugner]

I would strongly recommend for all viewport subfeatures to have a common parent feature, so that you can easily list them on a single MDN page about meta viewport:

html.elements.meta
html.elements.meta.viewport
html.elements.meta.viewport.height
html.elements.meta.viewport.initial-scale
html.elements.meta.viewport.interactive-widget
html.elements.meta.viewport.maximum-scale
html.elements.meta.viewport.minimum-scale
html.elements.meta.viewport.user-scalable
html.elements.meta.viewport.viewport-fit
html.elements.meta.viewport.width

Instead of viewport, the feature could also be called name_viewport (name="viewport"), or be nested inside html.elements.meta.viewport.name. The advantage of this would be that name="viewport" would be listed in the <meta> BCD table.

[github-actions[bot]]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[bsmth]

Note I just merged the following:

• [x] https://github.com/mdn/content/pull/39804

[dfabulich]

@pepelsbey On Discord you said that more testing would help move this PR forward. Testing what, exactly, and how? What's blocking this PR from merging?

[pepelsbey]

Testing what, exactly, and how? What's blocking this PR from merging?

I meant that if you have any suspicions about browser support data, feel free to research and suggest improvements. Otherwise, I’ll get back to this PR already next week.

[caugner]

I would strongly recommend for all viewport subfeatures to have a common parent feature, so that you can easily list them on a single MDN page about meta viewport:

html.elements.meta
html.elements.meta.viewport
html.elements.meta.viewport.height
html.elements.meta.viewport.initial-scale
html.elements.meta.viewport.interactive-widget
html.elements.meta.viewport.maximum-scale
html.elements.meta.viewport.minimum-scale
html.elements.meta.viewport.user-scalable
html.elements.meta.viewport.viewport-fit
html.elements.meta.viewport.width

Instead of viewport, the feature could also be called name_viewport (name="viewport"), or be nested inside html.elements.meta.viewport.name. The advantage of this would be that name="viewport" would be listed in the <meta> BCD table.

@Elchi3 @ddbeck @queengooborg Do you have any preference as to how to organize this viewport support data?