Add https://w3c.github.io/manifest-app-info/ #283
Comments
|
This doc shouldn't be added. |
|
@marcoscaceres What should we use instead? |
|
Depends... are you documenting things used by multiple engines or app stores? |
|
They're already documented in MDN at https://developer.mozilla.org/en-US/docs/Web/Manifest/categories, etc. Should we remove those MDN articles? The features are also in BCD. Should we remove them from BCD? As long as they are in BCD and documented in MDN and have a spec where they're defined,b is there a reason why we wound not want to record the spec URL? If we record the spec URL, we need a corresponding spec in browser-specs. |
|
I don't think we need to remove them from MDN - but it should be clear that they don't have multivendor support. Sorry, what's BCD again? |
|
BCD is https://github.com/mdn/browser-compat-data — it’s the data source for all the Browser Compatibility tables in MDN. So the data shown at https://developer.mozilla.org/en-US/docs/Web/Manifest/categories#browser_compatibility comes from https://github.com/mdn/browser-compat-data/blob/main/html/manifest/categories.json
Arguably, https://developer.mozilla.org/en-US/docs/Web/Manifest/categories#browser_compatibility makes that clear(ish) — it shows, at last, that feature is currently supported only in Chrome on Android. Beyond that, we these days otherwise make a practice of not attempting to editorialize further about whether something is on a path toward multivendor support. Vendors who have made an investment in implementing particular features to solve problems for developers would not be super happy about the prospect of MDN articles warning developers away from actually using the features — by having big red warning boxes telling developers, “This is a single-vendor feature that other browsers have no plans to implement support for” (or whatever). It seems better to just let the Browser Compatibility tables do the talking. |
|
coming back to the issue at hand (whether or not add the spec to browser-specs), the fact that it has some browser-based implementation means it probably qualifies for addition here |
|
Right, as it doesn't actually export anything (or declare any WebIDL), it should be ok to include. |
This adds three requested specs that sit at the boundary of spec selection criteria for browser-specs: 1. DNT, requested in w3c#281 2. SVG 1.1, requested in w3c#273 3. Web App Manifest - App info, requested in w3c#283 The SVG 1.1 entry uses SVG 2 as nightly URL for lack of a better alternative. JSON schema has to be slightly adjusted to account for the "-" in "tracking-dnt.html". Also, a test started to fail because "hr-time-3" is now the default level for HR Time.
This adds three requested specs that sit at the boundary of spec selection criteria for browser-specs: 1. DNT, requested in #281 2. SVG 1.1, requested in #273 3. Web App Manifest - App info, requested in #283 The SVG 1.1 entry uses SVG 2 as nightly URL for lack of a better alternative. JSON schema has to be slightly adjusted to account for the "-" in "tracking-dnt.html". Also, a test started to fail because "hr-time-3" is now the default level for HR Time.
|
Added to browser-specs and released in v1.35.0 |
https://w3c.github.io/manifest-app-info/
The text was updated successfully, but these errors were encountered: