Browser-compat-data: Does WebKitCSSMatrix deserve a separate support statement?

[saschanaz]

Currently WebKitCSSMatrix exists as a separate interface while it's currently merely an alias of DOMMatrix. I wonder it could be replaced by something similar with alternative_name in DOMMatrix.

[ddbeck]

This is in WebKitCSSMatrix.json.

@sideshowbarker you created the file in #5405, so I was wondering if you had an opinion on this. It's a bit of an odd case: the specification explicitly calls for the alias. Do you have a take on on whether this is a real interface (that ought to have its own status information and such)?

[sideshowbarker]

I agree this an odd case. But WebKitCSSMatrix is exposed to web content/script and to web developers — in all current browsers. So web developers arguably shouldn’t necessarily need to know nor care that it’s an alias for DOMMatrix.

That said, I think it would be fine if we handled it internally in BCD by just attaching it to DOMMatrix as an alias — but _only_ if our tooling then caused the https://developer.mozilla.org/en-US/docs/Web/API/WebKitCSSMatrix Browser compatibility table to automatically pick it up from BCD based on looking for any other feature which has it as an alias.

But as far as I know, our current tooling won’t cause that to be automatically picked up through data from another feature.

I guess the next thing that could be questioned is whether we should even rightly have a separate MDN article for https://developer.mozilla.org/en-US/docs/Web/API/WebKitCSSMatrix rather than just noting it in the DOMMatrix article.

My opinion about that is, we indeed should have a https://developer.mozilla.org/en-US/docs/Web/API/WebKitCSSMatrix article — because of the fact that WebKitCSSMatrix is exposed to web developers in all current browsers; and in general, to make things more clear and easier for developers, we should always have an MDN article for any feature that’s exposed to them.

And that takes me back to asserting that — if others agree we should in fact actually have a separate WebKitCSSMatrix (as we do now) — we should have a way to generate the Browser compatibility table for that the corresponding article from BCD. And as far as I understand, the only way we can do that currently is by maintaining separate data for it in BCD.

[saschanaz]

My opinion about that is, we indeed should have a https://developer.mozilla.org/en-US/docs/Web/API/WebKitCSSMatrix article — because of the fact that WebKitCSSMatrix is exposed to web developers in all current browsers; and in general, to make things more clear and easier for developers, we should always have an MDN article for any feature that’s exposed to them.

Currently the page only have a singe sentence:

An alias for DOMMatrix.

I think it doesn't provide a good experience, could we instead make a redirection to DOMMatrix and include a note that there is an alias, as Wikipedia does?

[ddbeck]

OK, I find that I'm in agreement with @sideshowbarker's take on this. It's comprehensive, stating the implications for BCD consumers and our own contribution workflow. I think we should keep the feature around as its own thing (though more and more I think we need at least linting that binds different features together — as proposed in #6571).

That said, I agree with @saschanaz that it's a bad experience for MDN readers.

Paging @chrisdavidmills: is there a way to do a Wikipedia-style page alias on the wiki? Or is a redirect the only option? Do you know of any patterns for wiki content for shared content that's almost but not exactly identical?

[chrisdavidmills]

@ddbeck this is a difficult one. I can't recall coming across any similar such instances of DOM Interfaces with aliases, like this one.

The nearest I can think of is the case of CSS properties with aliases, such as https://developer.mozilla.org/en-US/docs/Web/CSS/appearance

In this case, we have the URL slug as the standard property, mention the alternative names/aliases in the title in parens, clearly state that they are aliases in the text, and redirect the other pages to this one.

In the absence of any clever platform feature for handling this better, I'd recommending doing something similar to this, but probably keep the BCD separate — as @sideshowbarker , it is good to make sure this data gets picked up by tools that consume it.

In future however, we probably ought to think about a better way to deal with such cases.

[ddbeck]

Thanks for your guidance on this, @chrisdavidmills.

I've added WebKitCSSMatrix to the DOMMatrix page title and set up the redirect. I think that leaves two possible steps remaining before we close this:

• Change the MDN URL in api.WebKitCSSMatrix
• Set the description to <code>WebKitCSSMatrix</code> (alias to <code>DOMMatrix</code>) or similar

Any thoughts or questions on that? Or should we go ahead to a PR?

[chrisdavidmills]

That sounds good to me, @ddbeck . Go ahead!

[ddbeck]

I opened #6920 to finish this up. It will close this issue, when it merges.

[ddbeck]

Also, I should add: thank you for raising this issue, @saschanaz. The solution we worked out here isn't fantastic, but I think it's a lot nicer than before. 👍

[foolip]

My https://github.com/mdn/browser-compat-data/issues/8054 was duped into this, and I think there's more to be said, so I'll reopen.

WebKitCSSMatrix is not as unusual as one might hope. By now, there are many prefixed things standardized and available in all browsers. Among APIs there's webkitMatchesSelector and webkitURL, and there are also many CSS properties and events, many of which are in the compat spec.

I think we should handle WebKitCSSMatrix, webkitMatchesSelector and webkitURL in the same way. My preference would be to merge WebKitCSSMatrix into DOMMatrix as is typical for prefixed and alternative names. Another option is to consistently create separate entries for things that are standardized and widely implemented, but I'm not sure that's more helpful to readers.

[foolip]

Thanks @ddbeck, I didn't notice that I failed to reopen :)

[ddbeck]

OK, looking over this again, I think we overcorrected in the first place. We dealt with the original issue by both a) redirecting WebKitCSSMatrix to DOMMatrix and b) putting both tables on the MDN page. Having separate compat data made sense for separate pages, but having merged the pages, it's a little odd.

I'd be happy with a PR merging the data, but two things need to happen with it:

• Every top-level DOMMatrix must have a support statement with the WebKitCSSMatrix alternative_name, even if the data is null or false. It bugs me a little that there's no way to indicate, in the merged data, that the alias is standardized, but I don't know that it bugs me enough to change the schema. Being thorough here should at least help.
• The PR to BCD is paired with a PR to mdn/content dropping the superfluous WebKitCSSMatrix table.