Add Web Audio API

[foolip]

No description provided.

[foolip]

@ddbeck claiming that these bits of the API have been Baseline since 2015 while the whole feature only since 2021 doesn't seem right. You can't use any of this without a prefix unless the unprefixed AudioContext constructor is supported.

Should getStatus perhaps clamp support to the support of the overall feature? The downside is that if we do that for a feature where the Baseline status (false/low/high) isn't the same for the feature and its earliest parts, that would end up being confusing on MDN, as compat tables could claim support but the Baseline badge says not Baseline, as well as getting the low/high connection to dates wrong, although that's not as noticeable.

[ddbeck]

Should getStatus perhaps clamp support to the support of the overall feature? The downside is that if we do that for a feature where the Baseline status (false/low/high) isn't the same for the feature and its earliest parts, that would end up being confusing on MDN, as compat tables could claim support but the Baseline badge says not Baseline, as well as getting the low/high connection to dates wrong, although that's not as noticeable.

So I'm guessing there's four scenarios, for any given key:

1. It's newer than the overall feature (by baseline low date). You do want to show the newer status.
2. It's the same as the overall feature (by baseline low date, even if the specific versions differ). No conflict.
3. It's older than the overall feature. It works in isolation, so you want to show the older status.
4. It's older than the overall feature. It depends on another part of the feature, so you want to show the newer status.

It's scenario 4 that's the danger here, right? If that's much more common than scenario 3, we should just clamp the status. If scenario 3 is much more common, then that's probably not a good idea.

Brainstorming here, there are a few ways to deal with that situation. Most are on the consumer side:

• If it's in scenario 3 or 4, change the appearance on MDN to say, "This is part of another feature, with a different status." (I'd like to see the "this is part of…" thing in the widget, but that's an even more general matter.)
• If it's in scenario 3 or 4, make the page author decide which status to show. (I prefer this! These are the people who ought to know best! But I don't think the MDN folks are hyped about this idea, though I could be wrong.)

The only part I think we can do on the authoring side would be to do the work of declaring some keys as being tightly coupled, to opt-in to clamping just those keys. That'd still leave apparent conflicts on MDN, but they'd be good scenario 4 conflicts, where Baseline tells a more correct story than the compat table.

So you might have something like this:

coupled_compat_features:
  - [api.AnalyserNode, api.AudioContext]

That would say, "for these keys specifically, clamp to the worst availability of them, otherwise, proceed normally."

If this is rare, I'd hate to have to proactively research every feature for this. But it'd be an escape hatch for "broken" features, as they get reported.

(I suppose one other option would exist, which is maybe more correct but harder: do this annotation in BCD.)

[foolip]

@ddbeck those four scenarios look correct, although I would really consider any differences in status, not just differences in Baseline low date. I'd like a way to override data that don't make sense together, even if it's only at the level of browser versions.

And yes, scenario 4 is the issue here. It should be common for prefixed features, especially APIs with multiple interfaces but where the prefix is in a single place, the entrypoint.

For scenario 3, I'm struggling to think of when we'd decide to author a feature like this. I can imagine it in theory, that some marginally useful part of a feature shipped first, followed by the real thing that was motivating it to begin with. So perhaps for Set this would happen if we decide that size is an essential part of the feature, leaving the initial parts in Firefox under scenario 3.

I wonder if a variation of use_ranges_before_baseline_low_date could be revived for this, perhaps use_ranges_before_initial_support that would use ranges for everything before the browser version in the overall feature.

An important part of this is to cut down on the amount of research we need to do, to move faster.

[ddbeck]

I wonder if a variation of use_ranges_before_baseline_low_date could be revived for this, perhaps use_ranges_before_initial_support that would use ranges for everything before the browser version in the overall feature.

I like this idea. We should try it, once we're surfacing ranges.

Heck, we could try clamping anything pre-compute_from as ≤ with respect to the Baseline low date and versions, by default. Then, for those cases where things might be useable anyway (Set without size), we opt into unclamping?

Filing this as #1335.

[foolip]

This matches https://developer.mozilla.org/en-US/docs/Web/API/AudioListener#browser_compatibility and the notes make me trust the data.

[foolip]

This and the next is correct, see mdn/browser-compat-data#23628.

[foolip]

BCD has notes linking to bugs for these.

[foolip]

This is a FIXME in WebKit:
https://github.com/WebKit/WebKit/blob/312f06335038c0c43733c76223f9a53806a002c1/Source/WebCore/Modules/webaudio/AudioContext.idl#L38-L39

[foolip]

This seems correct. I've sent mdn/browser-compat-data#23629 to make it even more easily verifiable next time around.

[foolip]

Should the name be "Web Audio" with Audio capitalized? "Web audio" looks wrong to me because it's not about audio generically, but this specific API. "Web Audio API" is the spec name.

[captainbrosset]

Web Audio feels much better. That's how everybody talks about it.

[foolip]

I think this is OK to land as-is.

[ddbeck]

I'm happy with this, though please fix the style nit I noted in a comment. Thank you!