Structure operating system and device limitations

BCD reports operating system (OS) and device limitations through free-form text, but it's a relatively common kind of data. BCD should provide structured access to this data.

Background

BCD support statements are only partly segregated by OS and/or device. For example, there is separate data for Chrome for Android and desktop-versions of Chrome (running on Windows, macOS, and Linux); iPhone (iOS) and iPad (iPadOS) devices are grouped together as safari_ios.

Within browser data that covers multiple operating systems, notes and partial_implementation flags indicate when only a subset of the operating system-browser pairs provide support. See the relevant data guideline.

While notes and partials are uncommon, operating system limitations are extremely common within the notes and partials that BCD reports. At least one third of partial implementation notes on open support statements describe an operating system or device limitation.

This issue originated from my audit of BCD notes and partials. See the Partial implementation notes most-often describe operating system limitations (but inconsistently) and Structure operating system and device limitations sections for further reading.

Problem

BCD uses free-from notes and the boolean partial_implementation field to indicate OS and device limitations. Unfortunately, the phrasing is often inconsistent. Examples include:

• “Only supported on macOS.”
• “Currently supported on Windows only.”
• “Exposed in Mobile Safari on iPad but not on iPhone.”
• “Linux support is not enabled by default.”

The lack of consistency makes it impossible to consume automatically. This affects consumers such as web-features and Baseline that wish to make explicit reliance on operating systems or device support.

Recommendations

BCD ought to promote OS and device limitations to a distinct support statement field (plus supplementary browser data) or fully separate devices.

Support statement and browser release statement fields

BCD could add a field to browser release statements that indicate which devices are supported by the given release a browser:

{
  "browsers": {
    "edge": {
      "name": "Edge",
      "type": "desktop",
      "upstream": "chrome",
      "pref_url": "about:flags",
      "accepts_flags": true,
      "accepts_webextensions": true,
      "releases": {
        /* … */
        "18": {
          "release_date": "2018-10-02",
          "release_notes": "https://learn.microsoft.com/en-us/archive/microsoft-edge/legacy/developer/dev-guide/whats-new",
          "status": "retired",
          "engine": "EdgeHTML",
          "engine_version": "18",
          "default_devices": ["Windows"]
        },
        "79": {
          "release_date": "2020-01-15",
          "release_notes": "https://blogs.windows.com/windowsexperience/2020/01/15/new-year-new-browser-the-new-microsoft-edge-is-out-of-preview-and-now-available-for-download/",
          "status": "retired",
          "engine": "Blink",
          "engine_version": "79",
          "default_devices": ["Linux", "macOS", "Windows"]
        },
        /* … */
      }
    }
  }
}

Then support statements for that browser could indicate when they don't cover the full set of default devices. For example, this support statement shows that this browser only supports the feature on macOS:

{
  "version_added": "83",
  "devices": ["macOS"]
}

Or the data could be inverted:

{
  "version_added": "83",
  "excludes_devices": ["Linux", "Windows"]
}

This approach would favor an incremental effort, migrating notes and partials to a dedicated field over time. During a migration period, partial_implementation and note text could be generated for legacy consumers.

Separate browsers

Alternatively, BCD could represent this data as wholly separate browsers, replacing chrome with chrome_linux, chrome_macos, chrome_windows, etc.

This would be a more challenging effort to do incrementally. It could be a follow up to the incremental approach proposed in the previous section.

Start with the operating-system limitations section of docs/data-guidelines and compare the two proposed models: device fields on support statements or separate browser data. Review the linked audit and consider impacts on web-features and Baseline consumers; done requires an agreed structured representation and a clear migration or legacy-consumer plan.