Simplified support status: do prefixes and aliases count?

[ddbeck]

(We might want to consider re-titling this to capture more broadly the rules for simplifying support statuses, but I'm starting with some narrow questions now.)

Some questions by way of https://github.com/web-platform-dx/feature-set/pull/78/files#r1129450273:

1. Should vendor prefixes count toward satisfying a definition of widely supported? For instance, given a feature group containing alfa-property, should support for -webkit-alfa-property contribute toward satisfying support for alfa-property and the group as a whole?

   If no (as suggested by @foolip), then how might we go about annotating the group to show that a workaround is available?

2. Should vendor prefixes ever be required for a definition of widely supported? For instance, given some feature group that contains bravoInterface, should the feature group ever require support for WebKitBravoInterface to satisfy support for the group as a whole?

   An example of this would be WebKitCSSMatrix, which is specified as an alias to DOMMatrix. Conformant implementations should implement the alias, but do we care?

3. Should aliases ever be required for a definition of widely supported? For instance, given some feature group that contains charlie-property, should the feature group ever require support for legacy-charlie-property to satisfy support for the group as a whole?

   Examples include the legacy gap properties (grid-column-gap, grid-row-gap, grid-gap), which are now specified as aliases to the contemporary standard properties.

[zcorpan]

If developers want to know if the standard feature is supported, then imo

1. no
2. no
3. maybe yes, unless the legacy things are deprecated

[foolip]

@ddbeck this issue has been answer with code, right?

[ddbeck]

I think only the first item is answered with code (in the forthcoming baseline calculation code, that is). The latter two are asking more for group definition guidelines: should we include blessed-by-specification prefixes into the list of things that make up a feature?

FWIW, #503 implies that yes we should.

[foolip]

On standardized prefixes, I think we should treat them like any alias to the most favored spelling, like document.charset which is an alias of document.characterSet and hidden under that in BCD. Most standardized prefixes are like this, including WebKitCSSMatrix:
https://github.com/mdn/browser-compat-data/blob/662d4a0210a990f9059f05df053089f82eb4844e/api/DOMMatrix.json#L95-L107

Let's treat that as any alias and ignore it for the purposes of Baseline, effectively saying that support with a prefix only is a serious caveat.

Prefixed things that are listed as separate entries in BCD are trickier. A complete list:

api.DataTransferItem.webkitGetAsEntry
api.Element.webkitmouseforcechanged_event
api.Element.webkitmouseforcedown_event
api.Element.webkitmouseforceup_event
api.Element.webkitmouseforcewillbegin_event
api.File.webkitRelativePath
api.HTMLInputElement.webkitdirectory
api.HTMLInputElement.webkitEntries
api.WebKitPoint
api.WebKitPoint.WebKitPoint
api.WebKitPoint.x
api.WebKitPoint.y
api.Window.webkitConvertPointFromNodeToPage
api.Window.webkitConvertPointFromPageToNode
css.at-rules.media.-webkit-animation
css.at-rules.media.-webkit-device-pixel-ratio
css.at-rules.media.-webkit-max-device-pixel-ratio
css.at-rules.media.-webkit-min-device-pixel-ratio
css.at-rules.media.-webkit-transform-2d
css.at-rules.media.-webkit-transform-3d
css.at-rules.media.-webkit-transition
css.properties.-webkit-app-region
css.properties.-webkit-border-before
css.properties.-webkit-border-horizontal-spacing
css.properties.-webkit-border-vertical-spacing
css.properties.-webkit-box-reflect
css.properties.-webkit-column-axis
css.properties.-webkit-column-break-after
css.properties.-webkit-column-break-before
css.properties.-webkit-column-break-inside
css.properties.-webkit-column-progression
css.properties.-webkit-cursor-visibility
css.properties.-webkit-hyphenate-character
css.properties.-webkit-hyphenate-limit-after
css.properties.-webkit-hyphenate-limit-before
css.properties.-webkit-hyphenate-limit-lines
css.properties.-webkit-initial-letter
css.properties.-webkit-line-align
css.properties.-webkit-line-box-contain
css.properties.-webkit-line-clamp
css.properties.-webkit-line-clamp.none
css.properties.-webkit-line-grid
css.properties.-webkit-line-snap
css.properties.-webkit-locale
css.properties.-webkit-logical-height
css.properties.-webkit-logical-width
css.properties.-webkit-margin-after
css.properties.-webkit-margin-before
css.properties.-webkit-mask-attachment
css.properties.-webkit-mask-box-image-outset
css.properties.-webkit-mask-box-image-repeat
css.properties.-webkit-mask-box-image-slice
css.properties.-webkit-mask-box-image-source
css.properties.-webkit-mask-box-image-width
css.properties.-webkit-mask-box-image
css.properties.-webkit-mask-composite
css.properties.-webkit-mask-position-x
css.properties.-webkit-mask-position-y
css.properties.-webkit-mask-repeat-x
css.properties.-webkit-mask-repeat-y
css.properties.-webkit-mask-source-type
css.properties.-webkit-max-logical-height
css.properties.-webkit-max-logical-width
css.properties.-webkit-min-logical-height
css.properties.-webkit-min-logical-width
css.properties.-webkit-nbsp-mode
css.properties.-webkit-overflow-scrolling
css.properties.-webkit-perspective-origin-x
css.properties.-webkit-perspective-origin-y
css.properties.-webkit-rtl-ordering
css.properties.-webkit-tap-highlight-color
css.properties.-webkit-text-combine
css.properties.-webkit-text-decoration-skip
css.properties.-webkit-text-decorations-in-effect
css.properties.-webkit-text-fill-color
css.properties.-webkit-text-security
css.properties.-webkit-text-stroke-color
css.properties.-webkit-text-stroke-width
css.properties.-webkit-text-stroke
css.properties.-webkit-text-zoom
css.properties.-webkit-touch-callout
css.properties.-webkit-transform-origin-x
css.properties.-webkit-transform-origin-y
css.properties.-webkit-transform-origin-z
css.properties.-webkit-user-drag
css.properties.-webkit-user-modify
css.selectors.-webkit-details-marker
css.selectors.-webkit-inner-spin-button
css.selectors.-webkit-meter-bar
css.selectors.-webkit-meter-even-less-good-value
css.selectors.-webkit-meter-inner-element
css.selectors.-webkit-meter-optimum-value
css.selectors.-webkit-meter-suboptimum-value
css.selectors.-webkit-progress-bar
css.selectors.-webkit-progress-inner-element
css.selectors.-webkit-progress-value
css.selectors.-webkit-resizer
css.selectors.-webkit-scrollbar-button
css.selectors.-webkit-scrollbar-corner
css.selectors.-webkit-scrollbar-thumb
css.selectors.-webkit-scrollbar-track-piece
css.selectors.-webkit-scrollbar-track
css.selectors.-webkit-scrollbar
css.selectors.-webkit-search-cancel-button
css.selectors.-webkit-search-results-button
css.selectors.-webkit-slider-runnable-track
css.selectors.-webkit-slider-thumb

I haven't checked which are standardized, if any, but if some are with prefix and all, then I think they could also be added to web-features.

The most relevant case is -webkit-line-clamp, which is standardized, but the unprefixed form isn't shipped by anyone yet. Should it be -webkit-line-clamp in web-features then? Probably?

[foolip]

I don't think we need any change here. We already ignore prefix and alt name data from BCD, so a feature that requires a prefix cannot be Baseline. But we do have features that include "prefixed" BCD entries like api.File.webkitRelativePath. That's not a problem because the prefix is part of the name, and we get the right behavior.