Status of documenting vendor prefixes

[schalkneethling]

Looking at the older issues I came across the following issue from @Ryuno-Ki:
mdn/content#8271

Here he mentions that, even though not linked or documented on MDN Web Docs, there is a ::-moz-meter-bar equivalent to the documented ::-webkit-meter-bar pseudo-class. I have two thoughts/questions in this regard.

1. Should we even continue to document vendor prefixes? I believe the industry has realized this was a mistake and moved on 😄
2. If we no longer document vendor prefixes, should we consider removing the documentation we do have on ::-webkit-meter-bar?

Would appreciate thoughts from the @mdn/yari-content-css team. Thanks!

[Ryuno-Ki]

👋 Thanks for picking this up :)

[teoli2003]

1. Should we even continue to document vendor prefixes? I believe the industry has realized this was a mistake and moved on 😄

There are quite a few different cases:

1. Vendor prefixes on features that are now standard. In this case, the only mention of the prefixes should be in the browser compatibility section.
   For example AudioContext was initially added as webkitAudioContext. As this is now standard, we shouldn't use or document webkitAudioContext (except as a note in the bcd table). We should retire pages like Migrating from webkitAudioContext and update examples in the different pages that use the unnecessary and outdated var AudioContext = window.AudioContext || window.webkitAudioContext; idiom.
2. Vendor prefixes that are in the process of becoming standard. This is getting rarer as, as you said, the industry moved away from them. These are often old features never quite standardized that stay around. We document the standard version, redirects the prefixed pages to it, and add differences as notes on it. (This is the most common case).
3. Vendor prefixes that have been standardized because they are used too much. We document them with their prefix: HTMLInputElement.webkitdirectory
4. Internal features, prefixed, not available to web developers, should not be documented.

For ::-webkit-meter-bar and ::-moz-meter-bar, the question is to know in which category they fell. Is there a will to uniform them as ::meter-bar or not? If there is a will, we should have one page, if not, likely not. Most of these edge cases are found for styling UI elements. (The idea is also: If they are visible for web developers, we should document them.)

[jpmedley]

Chrome still has a handfull of webkit-prefixed items. I'd need to do some digging to learn which of them are still in use. By the way, my bosses do not support me spending time to rewrite the remaining ocurrences as notes.

[estelle]

::-webkit-meter-bar and ::-moz-meter-bar are both pseudo-elements, not pseudo classes.
They pose a different issue:
They are used in selectors, and the rule goes, in a group of selectors, if any selector is invalid, the whole rule will be ignored.
They can, however, be included in :where() and :is(), and other browsers will not ignore them. These accept a "forgiving selector list".

We do have a page that lists all the webkit prefixed properties. At the bottom are the pseudo-elements.
https://developer.mozilla.org/en-US/docs/Web/CSS/WebKit_Extensions

We should be moving the prefixed properties that have a supported unprefixed equivalent out of the top section and into the "on the standards track"

In terms of pseudo elements, most have to do with UI widgets like scrollbars, date pickers, meters, range, etc.
If we don't document each individual one (which I am not advocating we do), maybe we could include a page for each UI widget and list the pseudo-elements that make up the UI component.

[jpmedley]

It occurs to me that we should have @foolip on this thread. The first question to ask is, is Philip's BCD automation tracking prefixes? It may be that these will gradually vanish from the data set on their own.

[foolip]

https://mdn-bcd-collector.appspot.com/ has tests for most prefixed APIs, but I and @queengooborg never finished the code for updating prefixed data correctly.

My view of prefixed APIs, since some are forever a part of the web platform, is that they're just long and bad names, or alternative names if you will.

So I'd suggest the same treatment for prefixed APIs as others legacy aliases and alternative names.