Intent to Deprecate and Remove: support for position values with 3 parts (excluding background)

[Eric Willigers]

Primary eng (and PM) emails

ericwi...@chromium.org

Summary

In 2017 the spec syntax changed so that <position> values, excluding background-position, no longer accept 3-value syntax like "left 20% top" or "right bottom 20%".

Blink will follow the spec and, after a deprecation period, no longer support values excluded by the spec.

Motivation

• Consistency with spec

• This will make it easier to parse future shorthands that may have a length or percentage adjacent to a <position>.

• New properties accepting <position> will use the spec syntax, and we should be consistent.

Interoperability and Compatibility Risk

The risk is low as usage is less than 0.002% in total. The spec change to remove support for position values with 3 parts occurred early last year, and was recently reaffirmed in an  CSS WG discussion.

Edge: Supported, positive to removal

Firefox: Supported, positive to removal

Safari: Supported, positive to removal

Alternative implementation suggestion for web developers

Web developers can easily use 2 (or 1 or 4) value syntax instead of 3 value.

e.g. "80% 100%" or "top 0% right 20%" instead of "top right 20%"

Usage information from UseCounter

3 part position values appear in the following contexts:

basic-shape

0.00003%

gradient

0.0008%

object-position

0.0007%

perspective-origin

0.000001%

They also appear in background-position, with much higher usage, but that is supported by spec and isn't affected by this Intent.

OWP launch tracking bug

crbug.com/804187

Entry on the feature dashboard

https://www.chromestatus.com/features/5116559680864256

Requesting approval to remove too?

Yes, in M68.

[TAMURA, Kent]

LGTM1 to remove.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cac08cfb-8ded-4be7-a9dd-47186ea30975%40chromium.org.

--

TAMURA Kent
Software Engineer, Google

[Rick Byers]

LGTM2

The usage in some cases like gradient isn't tiny, and the fact that all engines currently support this increases the risk.  But my intuition is that the severity of breakage (and ease of update) will be quite low in this case, so I support attempting a removal after at least a one milestone deprecation period.  As always if we discover significant breakage (eg. during beta) we should be prepared to re-enable and re-evaluate the tradeoff.  Since background-position will need to continue to support 3-value, it doesn't seem worth causing much pain to avoid the need for a couple other exceptions.

Also I'm somewhat skeptical that all other engines will actually remove - we've seen several cases in the past where removal lingers for years as a low-priority bug on every engine other than Chrome (and so we ultimately gain nothing by being willing to go first and take the risk).  So I'd like to go on record and say that if after a year of being removed in Chrome, it's still supported in at least two other engines then I'd argue for adding it back to Chrome (and the spec) to get back to a place of interop.  I.e. we're willing to take the risk of going first, but not to be the only one over a period of a year :-).

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqH5aONrG_J7_3As%2BO%3DdpuwFiL_4MEJUN_nLwwiSCz8yNQ%40mail.gmail.com.

[Philip Jägenstedt]

LGTM3

Please make sure there are negative tests for the non-support of this in web-platform-tests. This will make it easy to figure out if anyone else is following, and if we regularly triage tests that only we have been passing for a year, then this would come up. Similar to Rick, I think we should reopen the spec discussion if nobody else removes in a year, and put it back even if the spec doesn't change unless anyone else moves even then.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY93x6nqFcJoPZBQjfhXHbFfp3VTzJoT2BLj2RYi8G-z2A%40mail.gmail.com.

[Daniel Bratell]

In general it would be good to know these numbers in relation to a relevant feature usage so that we don't accidentally that larger features. I checked object-position and perspective-origin and about 0.03% of the sites using object-position triggered the counter while perspective-origin was much lower (0.00001%). The two others, basic-shape and gradient, I had no reference for.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cac08cfb-8ded-4be7-a9dd-47186ea30975%40chromium.org.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Eric Willigers]

On Wednesday, January 24, 2018 at 1:55:26 PM UTC+11, Rick Byers wrote:

Also I'm somewhat skeptical that all other engines will actually remove - we've seen several cases in the past where removal lingers for years as a low-priority bug on every engine other than Chrome (and so we ultimately gain nothing by being willing to go first and take the risk).  So I'd like to go on record and say that if after a year of being removed in Chrome, it's still supported in at least two other engines then I'd argue for adding it back to Chrome (and the spec) to get back to a place of interop.  I.e. we're willing to take the risk of going first, but not to be the only one over a period of a year :-).

Rick

We now have removal complete in all engines.

WebKit commit:

https://trac.webkit.org/changeset/251668/webkit#file11

Firefox passing:

https://wpt.fyi/results/css/css-images/parsing/object-position-invalid.html?label=experimental&label=master&aligned