Skip to content

Simplified support status: do prefixes and aliases count? #86

Closed
@ddbeck

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions