Add webview support data to web-features

[tonypconway]

Hi all, sorry it's taken me a few days to get this written up.

Problem

web-features does not currently include data concerning the feature support of webviews. There are a subset of features in Baseline - both newly and widely available - that are not supported by the webview that corresponds to the browsers they are based on (Chrome Android and iOS Safari).

Webview developers thus have two possible negative outcomes when they try to use Baseline:

• They trust Baseline statuses for features and end up implementing something that doesn’t actually work in the webview they are targeting.
• They are aware of the inconsistencies and consequently avoid using Baseline and have to depend on the same cognitively challenging workflow as before where they spend a lot of time looking at support tables. They probably, as a result, avoid using newer features for the same reason that other web developers did before, i.e. too difficult to get a simple go/no-go decision for a feature.

I’ve created a sheet that lists out all the features and their statuses as outlined below based on a module that supplements web-features with BCD webview support data.

Proposal - Add webview data to web-features JSON

Adding webview support to web-features would make it significantly easier for technical writers and tools teams to indicate whether a feature is supported or not in webview.
We should add a new webview_support objects alongside the existing support objects in the web-feature JSON output that explains the level of webview support for a given feature. There are a few different ways we could do this.

Feature level data

Based on my research, features exist in different states that we should reflect in the output data, broken out by android and ios support:

• Equivalent - Chrome Android and/or Safari iOS do not support the feature and their corresponding webviews have the same level of support for all supported BCD keys in that feature, supported or not.
  • It might make sense to break this out into two statuses (Equivalent-supported, equivalent-unsupported), or replace it with high, low, false based on the feature-level support.
• Partial - Chrome Android and/or Safari iOS support the feature, and their corresponding webviews support a subset of the supported BCD keys but not all of them.
• Unsupported - Chrome Android and/or Safari iOS support the feature, but the webview does not support any of the keys.

In addition, the current data has an ambiguous status that indicates none of the above apply - usually it applies to features where the webview supports more keys than the corresponding browser. Someone with more expertise would need to look at these and tell me what I’m not understanding!

BCD-key level data

In addition, we should add webview_support to each BCD key in the by_compat_key support object where we can.

It might also be worth including a gap if there’s a gap of more than e.g. 1 month between the release date of the webview version and browser version that first supported a feature.

Format

Output should look something like:

"feature-id": {
  ...
  "status": {
    "baseline": "high",
    "support": { ... } // browsers listed here
    "webview_support": {
      "all": "equivalent",
      "android": "equivalent",
      "ios": "equivalent",
    }
    "by_compat_key": {
      "mdn.browser.compat.key": {
        "baseline": "high",
        "support": { ... },
        "webview_support": {
          "android": "120",
          "ios": "15.4"
        }
      }
    }
  }
}

Implementation details

My work in web-features-plus-webview is based on copying the logic of compute-baseline as possible - i.e. treating partial_implementation and the presence of other such properties as unsupported - without directly editing compute-baseline. I think it would be prudent to update compute-baseline to include a utility for calculating support for webviews and then mediating that to an overall status. This could be optional when using compute-baseline in isolation, but always used in the web-features build process.

Overrides for non-BCD features

Some web-features do not have any BCD keys, and are hard coded in a web-features .yml file - specifically image formats (avif, webp) and HTTP2 and HTTP3. At the moment, I have these set up as overrides indicating full support which are inserted and returned before the usual calculations take place. It would be worth discussing if there’s a more sustainable way to do this, either by hardcoding the same info into the .yml files or updating BCD to include these features.

Other webviews

The above suggestions are based on Android and iOS webviews because they have comprehensive data in @mdn/browser-compat-data. Other webviews will need more research to be fully supported, potentially involving testing or contributions from the vendors themselves:

• Windows Webview2 - this support article from MS details the differences between Webview2 and Edge. It looks like we could probably handle this as an overrides subset and then copy the rest from Edge, but someone with more insight into Windows and webviews should weigh in.
• Popular Chinese super-apps - we should try to get folks from Tencent (WeChat), Alibaba (Alipay), Baidu and so on to contribute data on their underlying Chromium versions and what the feature delta is where possible.
• FB/Instagram - likewise, it would be valuable to get definitive statements from Meta on their support levels. I may have a contact here, but any Meta folks reading this, please reach out!

[captainbrosset]

Windows Webview2 - this support article from MS details the differences between Webview2 and Edge. It looks like we could probably handle this as an overrides subset and then copy the rest from Edge, but someone with more insight into Windows and webviews should weigh in.

Minor nitpick: it's called Microsoft Edge WebView2.

Another comment on this is that the article you mentioned is currently outdated, but I'm getting it updated soon.
Bottom line, though, is that this is a manually edited article. So, while we can certainly use this to derive WebView2 BCD data from the Edge BCD data, we should realize it's always going to kind of lag behind a little bit.

Question: what about merging the browser support data and the webview support data in the web-features computed files? Instead of having 2 separate data structures. That would make the data a little simpler to read I think. And the Baseline headline can still only consider the core browser set anyway.

[tidoust]

Question: what about merging the browser support data and the webview support data in the web-features computed files? Instead of having 2 separate data structures. That would make the data a little simpler to read I think. And the Baseline headline can still only consider the core browser set anyway.

I think my question is similar to Patrick's question, but I'm not sure what "web-features computed files" are, so I thought I'd still formulate it ;)

Right now, the proposal would seem to present webview support as a diff from support in the underlying browsers. That may make sense as a way to gather (and compute) the data, but would force package consumers to apply the diff themselves in order to compute actual support in webviews, which seems counter-intuitive to me. I would rather take the opposite approach: provide the actual support data in webviews and let consumers compute a diff if they need to. Is there a particular reason to take a diff approach in the output data?

[tonypconway]

@captainbrosset

Minor nitpick: it's called Microsoft Edge WebView2.

Good to know! I will abbreviate as MSEWV2 for now, haha.

Another comment on this is that the article you mentioned is currently outdated, but I'm getting it updated soon.
Bottom line, though, is that this is a manually edited article. So, while we can certainly use this to derive WebView2 BCD data from the Edge BCD data, we should realize it's always going to kind of lag behind a little bit.

Would MS folks be open to contributing MSEWV2 to BCD as part of their release process for new features? I guess backfilling won't be the hardest thing in the world as the list of unsupported features is quite short, then it's just a question of remembering to update the WV data alongside Edge data when updating BCD.

Question: what about merging the browser support data and the webview support data in the web-features computed files? Instead of having 2 separate data structures. That would make the data a little simpler to read I think. And the Baseline headline can still only consider the core browser set anyway.

Just to make sure I understand, you mean putting the webview support keys into the same object as the browser support keys, like this:

"support": {
  "chrome": "17",
  "chrome_android": "18",
  "edge": "12",
  "firefox": "5",
  "firefox_android": "5",
  "safari": "6",
  "safari_ios": "6",
  "android_webview": "18",
  "ios_webview": "6"
}

I'm not opposed to this, it would be simpler, cleaner, take up less space! We'd just need to be mindful that some consumers may be iterating through the module as it is currently structured and adding to it would make for a breaking change.

@tidoust

I think my question is similar to Patrick's question, but I'm not sure what "web-features computed files" are, so I thought I'd still formulate it ;)

I would assume Patrick meant the data.json file, but happy to be corrected.

Right now, the proposal would seem to present webview support as a diff from support in the underlying browsers. That may make sense as a way to gather (and compute) the data, but would force package consumers to apply the diff themselves in order to compute actual support in webviews, which seems counter-intuitive to me. I would rather take the opposite approach: provide the actual support data in webviews and let consumers compute a diff if they need to. Is there a particular reason to take a diff approach in the output data?

Absolutely fine with this as well. My proposal/work in the experimental package was mostly seeking to make @NiklasMerz 's life easier, but I imagine updating the pipeline for caniwebview.com to derive the difference itself wouldn't be too difficult if the webview data was in data.json directly.

Overall, I'm happy to go for the simplest approach, I've just been trying to reduce the overhead for other people in terms of deriving a 'webview' status for features. But happy to make that the module consumer's prerogative.

[NiklasMerz]

Just to make sure I understand, you mean putting the webview support keys into the same object as the browser support keys, like this:

I think I prefer adding webviews to the support property as well. Just like in your example as webview_android, ẁebview_ios` etc. In BCD it's done in a similar fashion.

It's pretty straightforward then to implement this in caniwebview and we want to show the data on https://caniwebview.com/baseline like this:

[tonypconway]

I'm in support of all of the above, but with one remaining question:

How do we reflect webview support where a subset of the BCD keys that are supported in a browser are unsupported in the corresponding webview?

compute_from features

As an example, image-maps status is computed from BCD key html.elements.area. image-maps in web-features shows support for all of its BCD keys in Android Chrome. But BCD indicates that the html.elements.area.implicit_noopener key is unsupported in Android WebView. Given the status of image-maps is derived simply from html.elements.area, do we simply say Android WebView is supported at the feature level even though its support differs from Android Chrome?

See as another example service-workers - computed from only two BCD keys, many BCD keys unsupported in webview but supported in iOS. How do we reflect that difference in support at the feature level?

non compute_from features

Other features suffer from the same issue without involving compute_from, e.g. state which has css.selectors.state unsupported in ios webview or meter which has several unsupported keys in Android webview.

---

I don't have a strong view on how we approach this, and it only affects a small number of features (~30), but we do need to decide how we're reflecting it before we move ahead. I guess if the compute_from features are supported in the webview in question, that's pretty simple, but the ones without a compute_from might need a bit of consideration.

[captainbrosset]

Maybe add the status at build-time as additional data, but not in the dist file, to avoid making PR reviews harder.
@NiklasMerz, @ddbeck is the right person to help you get started on the above.

[ddbeck]

I left a lengthy comment on the Niklas's PR about the schema implications for exposing data for browsers not in the core browser set. I don't think there's anything especially technically challenging here, but yet another naming problem. 😅