Umbrella Focus Area for unprefixing various CSS properties/values

[BenjaminAster]

Description

CSS vendor prefixes are slowly dying out (fortunately), but there are still some CSS properties/values where some browsers need prefixes:

• print-color-adjust: Needs -webkit- prefix in Chromium.
• user-select: Needs -webkit- prefix in WebKit.
• text-size-adjust: Needs -webkit- prefix in WebKit and Firefox. (Firefox also supports the -moz- prefix.)
• box-decoration-break: Needs -webkit- prefix in Chromium and WebKit. Chromium is currently working on shipping unprefixed support.
• text-decoration: Needs -webkit- prefix in WebKit when specifying multiple values in the shorthand.
• line-clamp: Needs a -webkit- prefix and some additional non-standard properties (display: -webkit-box and -webkit-box-orient: vertical) to be set in Chromium, WebKit and Firefox. Chromium is currently working on implementing the unprefixed property.
• (min-/max-)width/height/inline-size/block-size: stretch: Implemented as -webkit-fill-available in Chromium and WebKit, and -moz-available in Firefox.

For many of these properties, browsers either do not implement some parts of the spec or implement it a bit differently. So "unprefixing" would also mean fixing those issues to align the implementation with the specification.

Specification

N/A (see hyperlinks above)

Additional Signals

No response

[o-t-w]

Needing to use Autoprefixer to prefix what is now just a small handful of properties feels wasteful and unfortunate.
It would be particularly beneficial if at least user-select would be unprefixed and text-decoration would work as a shorthand in Safari. The other properties are somewhat niche in comparison.

[gsnedders]

For many of these properties, browsers either do not implement some parts of the spec or implement it a bit differently. So "unprefixing" would also mean fixing those issues to align the implementation with the specification.

My first thought is that the amount of work to unprefix these significantly varies, given differences to what the unprefixed property has as specified behaviour, which may make this dubious as a single focus area. line-clamp is perhaps the most apparent, where the spec is significantly more complex than existing implementations as far as I'm aware.

[karlcow]

unprefixing can mean many different things.

• Add the unprefixed and make it an alias of the prefixed version
• Add an unprefixed version which is different from the prefixed version
• Replace the prefixed version by the unprefixed version

All these choices have webcompat impact most of the time with legacy websites and native apps using a form of these properties.

Also it really depends on each property, as @gsnedders mentioned the effort can sometimes be gargantuan for some of these.

[BenjaminAster]

@gsnedders @karlcow Yes, I agree; This issue can perhaps be seen as a discussion starting point for how to handle property unprefixing in interop. Putting line-clamp into its own focus area is probably a good idea, since yes, the spec is more complicated than how -webkit-line-clamp is currently handled.

As for the other properties:

print-color-adjust

I don't see any open issues about this in the Chromium issue tracker; the implementation also seems to exactly match the spec, so I think this can just be unprefixed?

user-select

Reading through the WebKit issue, there seem to be various open bugs, some of which block unprefixing the property.

text-size-adjust

WebKit seems to already match the behavior (?) (see bug) while Firefox does not yet implement percentages (see bug). Personally though I think not supporting percentages should not block unprefixing since the most common usage of text-size-adjust probably is setting it to none anyway, and there probably isn't any compatibility risk with user agents supporting only a subset of a property's valid value syntaxes.

box-decoration-break

There is currently an open pull request for WebKit, but some minor edge cases still seem to be unimplemented. (see bug)

text-decoration

There also exists an open pull request for WebKit, and the implementation seems to already match the spec pretty well (?). (see bug)

stretch

This also seems to be one of the more complicated ones (maybe also make this its own focus area?), since there are some layout edge cases with floats etc. that still need to be fixed in various browsers. See Chromium bug, WebKit bug, Firefox bugs: 1, 2, 3

Note also that text-size-adjust and user-select would still need to keep the -webkit- prefix around as an alias, as per https://compat.spec.whatwg.org/#css-prefixed-aliases and https://drafts.csswg.org/css-ui-4/#propdef--webkit-user-select.

[jgraham]

I'd recommend making separate issues for each property, and mentioning in the issue description that there's a possible group.

The process allows us to easily take multiple issues and combine them into a single focus area, whereas pulling apart a single issue containing multiple parts with potentially different levels of complexity and priority is harder.

[bfgeek]

box-decoration-break

There is currently an open pull request for WebKit, but some minor edge cases still seem to be unimplemented. (see bug)

This isn't as trivial as one might assume. The majority of the work involved in Blink's recent un-prefixing (https://issues.chromium.org/issues/40415661) was to get box-decoration-break to work with block-fragmentation.

stretch

This also seems to be one of the more complicated ones (maybe also make this its own focus area?), since there are some layout edge cases with floats etc. that still need to be fixed in various browsers. See Chromium bug, WebKit bug, Firefox bugs: 1, 2, 3

See: mozilla/standards-positions#1054 (comment) for further discussion.
WebKit's implementation of -webkit-fill-available doesn't match what stretch should do, and might have trouble performing a simple un-prefixing due to existing web-content relying on the quirky behaviour. (But that's up to the WebKit folks to analyze).

[BenjaminAster]

@jgraham @bfgeek Thanks for your feedback! I have now opened seven separate issues for the seven properties. Let's continue the discussions there!

• Unprefixed print-color-adjust #720

• Unprefixed user-select #721

• Unprefixed text-size-adjust #722

• Unprefixed box-decoration-break #723

• Unprefixed text-decoration #724

• Unprefixed line-clamp #725

• Unprefixed stretch keyword for size-declaring CSS properties #726

[Mouvedia]

@BenjaminAster could you add one for -webkit-font-smoothing/-moz-osx-font-smoothing?
cf https://developer.mozilla.org/en-US/docs/Web/CSS/font-smooth

[BenjaminAster]

@Mouvedia This is a non-standard property that does not exist in any specification, and is only implemented on MacOS. The Interop project is only for web features that are already standardized.

From proposal_guide.md:

Interop is not a venue for performing standards work. Proposals which are not backed by an existing standard in a recognized standards venue are highly unlikely to be accepted.

The right place to start a discussion about perhaps standardizing this property is to open an issue in https://github.com/w3c/csswg-drafts. EDIT: Turns out ~20 years ago, this was in a specification and has since been removed, probably because the CSSWG considered it an antipattern to override the browser's font antialiasing behavior? So I think it is very unlikely that this will ever get unprefixed in browsers.

[karlcow]

An issue can also be opened on https://github.com/whatwg/compat/issues

[Mouvedia]

@karlcow whatwg/compat#115