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

[caugner]

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

[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]

Overall LGTM (*), but I have two remaining questions:

1. Shouldn't all these viewport-related content values go below the viewport feature, even if syntactically they are values of the content attribute? (@Elchi3 Wdyt?)
2. Should any of those version numbers be replaced with a range (≤x) if we're uncertain whether the feature was added in that exact version?

(*) I have only spot-checked some of the data based on the summary given in the referenced issue. If we already had the internal annotations field, we could record the confidence or reasoning for each support statement, but unfortunately we don't have it yet.

[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:

browser-compat-data/lint/linter/test-filename.ts

Line 52 in 059828c

.replace('html/elements/input/', 'html/elements/input/type_')

[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.