I’m doing a doc update for a spec bug that was fixed recently in Web Audio API. It changes one method so that it guarantees a specific end-state for a value, instead of leaving it to chance. This seems too minor to have a line in BCD tables (I mean, in a few months or a year, nobody will care), but right now it matters. What’s the best way to handle this? I’m inclined to note the expected end value in the docs, then list that we meet this change in Firefox 63, and ignore BCD entirely for this. Any disagreement?
I think that’s OK, yes.
The larger question is: should these items that are actually sub-features of all of these other features be listed as top-level features, or should they be repeatedly listed as sub-features of the actual top-level features they’re part of?
Sorry, I don’t really understand the question; can you expand a bit and give examples? I’m a bit slow today
Sure. Take a look at https://github.com/mdn/browser-compat-data/blob/master/http/headers/content-security-policy.json#L1039. Here we see an entry for a feature called
The problem is that
"report-sample" is actually a keyword used by other directives (
img-src, etc). Those directives are all top-level features in the JSON, but so is
"report-sample", yet its availability within individual directives also needs to be noted. So what do I do here? I’m guessing I have to repeat the info for
"report-sample" for each directive. Tedious. So I’m asking in hopes that someone says there’s a better way.
There is this: https://github.com/mdn/browser-compat-data/pull/1799 which might help you if it (or something like it) gets merged. Assuming I understand the problem you are trying to solve.
Yes, that is exactly the type of issue BCD PR #1799 is trying to solve (I just need to fix merge conflicts and write tests for it).
Yup, that’s exactly what I need. I shall wait until that lands to finish this work, I think, until feature imports are in place. That will make things much more efficient to put together, and will result in simpler and better data.