Browser-compat-data: What does a lowercase `prefix` like "o" or "webkit" mean for interface names?

[foolip]

https://github.com/mdn/browser-compat-data/blob/f4f8ce8eb117281c5037d15cac257293fd19301c/api/AnimationEvent.json#L40-L52

This is for the AnimationEvent interface. From this data, it doesn't appear possible to infer what interface names were supported in which versions of Opera. It looks like the interface wasn't prefixed in Opera, but if it were it wouldn't have been called oAnimationEvent. Maybe OAnimationEvent, perhaps @lilles or @mstensho know?

For "webkit" there is a similar problem. The URL interface was prefixed as webkitURL, while the AnimationEvent interface was called WebKitAnimationEvent.

A case like element.matches vs. element.webkitMatchesSelector is similarly problematic, although not an interface.

In order to be able to generate tests for the presence or absence of prefixed forms, making it possible to derive the correct name would be useful.

A few options:

• Allowing alternative_name together with prefix when the name isn't just the concatenation of the prefix and name.
• Merging prefix into alternative_name, so that the full name must always be spelled out.

@Elchi3 @jpmedley please advise :)

[jpmedley]

I like the later. If I look at this from a set theory point of view, prefix is always a subset of alternative_name. What kind of logical operations do I need to do in code to consider them both? Having them in a single bucket means sorting and filtering on a single set rather than trying to merge two sets. That is not the opinion of a data scientist or engineer, I'll admit.

FYI you have another scenario which might be a bigger problem. I've seen at least one interface where the interface name itself was prefixed, but the members where not. If I could remember which it was, I'd link to it.

[foolip]

I've seen at least one interface where the interface name itself was prefixed, but the members where not. If I could remember which it was, I'd link to it.

This has been very common, the norm even when a whole non-standard interface was added. AnimationEvent is a case like this.

[Elchi3]

I think we first had "prefix" for CSS properties and then there were APIs that had prefixes as well or appeared as different names. I think merging the two would be useful indeed. I don't particularly like the name "alternative_name", though.

I'd like to maybe call this merged property "alias" (open for other suggestions) and it has the requirement that the full name must always be spelled out.
We could add "alias" to the repo, have data consumers switch to that, and then only remove "prefix" and alternative_name" in a future package version to have a bit of a deprecation period here.

To make an informed decision, it would be nice if we could attach some data to this issue before making a call:

• Numbers on how much "prefix" and "alternative_names" are used throughout
• Show different sample scenarios they appear in and see if "alias" makes sense (CSS samples, API samples, HTTP samples, ...)
• Find out if and how MDN, VSCode and webhintio use "prefix" and "alternative_name", and if "alias" would work for them.

[foolip]

Numbers on how much "prefix" and "alternative_names" are used throughout

With some JS that traverses all the data and shell scripts, counting number of prefix used:

 933 api prefix
1214 css prefix
  10 html prefix
   4 http prefix

Typical examples from each bucket:

https://github.com/mdn/browser-compat-data/blob/f4f8ce8eb117281c5037d15cac257293fd19301c/api/Blob.json#L255-L258

(FWIW, this is stale, Safari has unprefixed it now.)

https://github.com/mdn/browser-compat-data/blob/e47b30524457883b6ce2bf65147933ef35f3e02c/css/properties/animation-delay.json#L8-L16

https://github.com/mdn/browser-compat-data/blob/0e4822f2be39467e7003ab9f926dfc8dc7f0cb4f/html/elements/iframe.json#L179-L187

https://github.com/mdn/browser-compat-data/blob/56f434d232017e264574bb3e0d5ce9bbef5e4008/http/headers/sourcemap.json#L26-L34

Counts for alternative_name:

 243 api alternative_name
 258 css alternative_name
   3 html alternative_name
   4 http alternative_name
  44 javascript alternative_name
  55 webextensions alternative_name

Here's what seems like a typical usage:

https://github.com/mdn/browser-compat-data/blob/8575f4d98958b09afac8fc0d31dd1d1d6ccb717c/api/RTCDataChannel.json#L19-L28

(The lack of a per-spec prefix RTC in this case.)

But there's also lots of alternative_name used for prefixes, like this:

https://github.com/mdn/browser-compat-data/blob/398d65b60286de89eaef02e90b08cc87160450a3/css/properties/margin-inline-end.json#L75-L83

[foolip]

Looking at this, it seems pretty clear that a single merged concept would be beneficial.

One concern I'd have with alias as the name is that at least to browser engineers, something being aliased has a pretty specific meaning. URL and webkitURL are clearly aliases because webkitURL===URL is true. But that doesn't always happen. DOMMatrix===WebKitCSSMatrix is true in Chrome but not Safari, where they are different interfaces. I would not call Safari's WebKitCSSMatrix an alias of DOMMatrix.

Another case is requestAnimationFrame vs. webkitRequestAnimationFrame which have slightly different behavior. I wouldn't call these aliases.

For CSS, some properties are aliased at parse time and some are not, instead getting slightly different treatment but probably being effectively the same for most uses.

Given that alternative_name is already used for some prefix cases, would folding prefix into alternative_name be an OK solution? Any users of BCD that handle alternative_name would need no change this way.

[Elchi3]

Looking at this, it seems pretty clear that a single merged concept would be beneficial.

+1

One concern I'd have with alias as the name ....

Good point, the semantics/behavior of things with prefix or an alternative name might actually be different, so alias is a bit misleading in these cases. I guess that's also why we came up with "alternative_name" then (it always sounded a bit weird to me, but maybe that's just me).

folding prefix into alternative_name be an OK solution?

This might work in fact. Given the usage numbers of prefix we need to see when we want to drop prefix, though.

Any users of BCD that handle alternative_name would need no change this way.

I think this would work fine for MDN docs compat tables. Need to see how other data consumers have dealt with "prefix" and "alternative_name" to avoid breakage.

[ddbeck]

(it always sounded a bit weird to me, but maybe that's just me).

It's not just you. For one, I always want to write (wrongly) alternate_name. And I think it implies something like "alias", where both names should work to access the same behavior. I'd kinda like to see both prefix and alternative_name go away. Something like known_as, exposed_as, assumed_name, or non_standard_name would probably capture what we're getting at better.

Need to see how other data consumers have dealt with "prefix" and "alternative_name" to avoid breakage.

At very least the compat tables on MDN consume prefix and alternative_name differently. Compare animation-delay's "Implemented with the vendor prefix: -webkit-" and RTCDataChannel's "Uses the non-standard name: DataChannel".

(Though if we're worrying about breaking changes, maybe it's time to semver our way to 1.0.)

[foolip]

FWIW, I didn't find alternative_name a strange name as a newcomer to the project. I'd favor the name of least resistance, but some relevant cases for the non_standard_name option:

• webkitMatchesSelector is now standard, but once was a prefixed variant of the then-standard name matchesSelector. It's now just matches.
• Other once-standard APIs remain in browsers, with WebRTC (addStream, removeStream, etc.) being a good example.

That being said non_standard_name seems fine to me, it's the terminology I usually use and have put in Blink's IDL files.

[zcorpan]

Non-standard is a misnomer when the name is standardized, though.

Also note that there can be multiple alt names, e.g. https://drafts.fxtf.org/geometry/#svgmatrix

[foolip]

Yes, in such cases there's a question of whether standardized aliases should be given separate entries in BCD. For webkitMatchesSelector it seems pretty unhelpful to split it out separately, and non_standard_name would be wrong if done as part of the matches entry.

[ExE-Boss]

I’m somewhat opposed to alias as the property name implies that both the official and non‑standard names are supported.

[jpmedley]

I agree with that.

I found a new edge case yesterday: a case where the webkit 'prefix' is actually used as an infix.

[ExE-Boss]

I’m pretty sure that all on‑ event handler properties use prefix as an infix.

[foolip]

I've seen cases like this too, initWebKitAnimationEvent is the most recent.

[Elchi3]

To summarize:

• We think it would be good to merge the current "prefix" and "alternative_name" data points.
• From a data point of view, "prefix" isn't a good name, as there are in-fixes (and maybe post-fixes) as well. Web developers know the term "prefix" fairly well, though (esp for CSS).
• "alternative_name" (or "alternate_name") and "alias" imply both names should work to access the same behavior, which isn't always the case. It also implies that that both the official and non‑standard names are supported, which might not be the case either.
• There are no (enforced) rules when things should actually be given separate entries in BCD.
• "non_standard_name" is a misnomer when the name is standardized (this happened).
• Other proposals mentioned: known_as, exposed_as, assumed_name.

Would it help to formulate a rule for when we actually need separate BCD entries and then come up with a name for the merged data point of "alternative_name" and "prefix"?

Keep in mind that one side of this is to improve the data points and automation possibilities, but the other side is also to make the most sense for data consumers (MDN readers, web developers). How do web developers refer to "prefixes/aliases/non-standard names" and how are they dealing with them usually? This might matter when modelling this.

[a2sheppy]

FWIW, alternative_name is a little odd. I wish we had used alternate_name instead. It flows better, it's slightly shorter, and it's just a more typical phrasing.

[ExE-Boss]

Same here, I’ve made a few PRs in the past where I accidentally used alternate_name.

[foolip]

Would it help to formulate a rule for when we actually need separate BCD entries and then come up with a name for the merged data point of "alternative_name" and "prefix"?

The rule I'd use is that if web developers can fall back from one API to the other with only trivial changes, then at least combining them on MDN makes sense. So webkitMatchesSelector support makes sense as part of matches (aliases) and webkitRequestFullscreen as part of requestFullscreen even though there are differences in which events fire.

One radical approach would be separate entries for everything, which would make some things maximally easy for tooling. If related APIs are linked that would handle cases like element.webkitCancelFullscreen() later becoming document.exitFullscreen(). However, that would have to be coupled with a proposal for how to present the data on MDN pages, which I don't have, or mapping back to exactly the current merged presentation would make the splitting questionable.