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