Intent to Implement and Ship: Support 'x' as a CSS resolution

[Chris Nardi]

Contact emails Chris Nardi (cna...@chromium.org) Spec https://drafts.csswg.org/css-values-4/#resolution

Summary

An addition in the CSS Values 4 spec was adding 'x' as a synonym for 'dppx'. This change would allow parsing '1x', '2x', etc. as resolutions in CSS.

Motivation The currently-prefixed webkit-image-set function is specified to take a resolution, but was only previously implemented with 'x' as a unit. The CSS WG decided to add 'x' as a unit for all <resolution> types.

Risks

Interoperability and Compatibility

There should be no compatibility risk for parsing, as only previously invalid code would become allowed.

Serialization will need to be defined for 'x', as currently the CSS Typed OM spec only specifies 'dppx' and leaves out 'x'. According to CSS Values 4, 'x' should be the canonical type, but since 'dppx' is currently the canonical type for resolutions, matching this might result in breaking serialization per other browsers that haven't implemented the 'x' unit. This change proposes leaving serialization as-is for now.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ergonomics

n/a

Activation

n/a

Debuggability

No changes to DevTools should be needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

No, but tests will be added through this change (currently only through media queries, but tests with the 'sizes' attribute can be added).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5150549246738432

Requesting approval to ship?

Yes.

[PhistucK]

Have you tried contacting the other vendors? Intent to ship usually asks for that...

The non-compliant serialization sounds problematic, you should probably have a conclusion about that, especially since the CSS Typed OM seems to be on its way to ship.

☆PhistucK

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXZydeyZLBd851meeg40S9jRDcmXcHy8cUsqX0FwuBxBbfXMA%40mail.gmail.com.

[Chris Nardi]

On Tue, Jan 30, 2018 at 1:18 AM, PhistucK <phis...@gmail.com> wrote:

Have you tried contacting the other vendors? Intent to ship usually asks for that...

I was planning on filing bugs with the other browsers today, but this is a mostly minor bit of syntax (I believe the only places that Chrome takes a <resolution> type are in media queries and the sizes attribute, with webkit-image-set to follow).

The non-compliant serialization sounds problematic, you should probably have a conclusion about that, especially since the CSS Typed OM seems to be on its way to ship.

I filed https://github.com/w3c/csswg-drafts/issues/2241 for that.  

[Joe Medley]

Chris,

Do you have a tracking bug so that I can follow the progress of this?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

--

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+unsubscribe@chromium.org.

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

[Chris Nardi]

This is a component of https://crbug.com/630597, but the bug is much broader than this intent. I can file a narrower bug for tracking this if needed.

[Joe Medley]

Can you please.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Chris Nardi]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=807653 to track this issue.

[Joe Medley]

thank you

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Yoav Weiss]

Thanks for working on this. Unprefixing image-set would be really great! :)

On Tue, Jan 30, 2018 at 12:56 PM Chris Nardi <cna...@chromium.org> wrote:

On Tue, Jan 30, 2018 at 1:18 AM, PhistucK <phis...@gmail.com> wrote:

Have you tried contacting the other vendors? Intent to ship usually asks for that...

I was planning on filing bugs with the other browsers today, but this is a mostly minor bit of syntax (I believe the only places that Chrome takes a <resolution> type are in media queries and the sizes attribute, with webkit-image-set to follow).

Could you enumerate those places so that we can better assess the compatibility impact here?

One example where I can think this can have a negative compatibility impact is for current content which contains e.g. `@media screen and (min-resolution: 2x) `.

This MQ right now doesn't apply anywhere, but supporting the `x` resolution will make it applicable in Chromium, creating a potentially visible difference between different browsers for existing content.

One way to tackle this is to enumerate all the places where we'd support such a unit and use HTTPArchive data to see if such content currently exists.

Another possibility is to start wiring support for the unit, but only use that parsing support for UseCounters, to make sure this will have no impact at the moment.

The non-compliant serialization sounds problematic, you should probably have a conclusion about that, especially since the CSS Typed OM seems to be on its way to ship.

I filed https://github.com/w3c/csswg-drafts/issues/2241 for that.  

--

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/CAKXZydcwWwXUHRkcirjMBfoFVG9wgXZe3VTxMHS9VHd6kJ55%2Bg%40mail.gmail.com.

[Chris Nardi]

On Fri, Feb 2, 2018 at 5:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Thanks for working on this. Unprefixing image-set would be really great! :)

On Tue, Jan 30, 2018 at 12:56 PM Chris Nardi <cna...@chromium.org> wrote:

On Tue, Jan 30, 2018 at 1:18 AM, PhistucK <phis...@gmail.com> wrote:

Have you tried contacting the other vendors? Intent to ship usually asks for that...

I was planning on filing bugs with the other browsers today, but this is a mostly minor bit of syntax (I believe the only places that Chrome takes a <resolution> type are in media queries and the sizes attribute, with webkit-image-set to follow).

Could you enumerate those places so that we can better assess the compatibility impact here?

One example where I can think this can have a negative compatibility impact is for current content which contains e.g. `@media screen and (min-resolution: 2x) `.

This MQ right now doesn't apply anywhere, but supporting the `x` resolution will make it applicable in Chromium, creating a potentially visible difference between different browsers for existing content.

One way to tackle this is to enumerate all the places where we'd support such a unit and use HTTPArchive data to see if such content currently exists.

Another possibility is to start wiring support for the unit, but only use that parsing support for UseCounters, to make sure this will have no impact at the moment.

The 3 places resolutions are accepted in media queries are for resolution, min-resolution, and max-resolution. The HTML sizes attribute would also be affected, as media query expressions are parsed within it. 

Also regarding serialization: it appears that the original intent was for 'dppx' and 'x' to be two different units with a 1:1 ratio (see the linked discussion). This way, 'x' could serialize to 'x' and 'dppx' could serialize to 'dppx'. Does this approach make sense? Or should we pick one unit to serialize both to, as they are synonyms?

[Chris Harrelson]

On Fri, Feb 2, 2018 at 7:10 AM, Chris Nardi <cna...@chromium.org> wrote:

On Fri, Feb 2, 2018 at 5:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Thanks for working on this. Unprefixing image-set would be really great! :)

On Tue, Jan 30, 2018 at 12:56 PM Chris Nardi <cna...@chromium.org> wrote:

On Tue, Jan 30, 2018 at 1:18 AM, PhistucK <phis...@gmail.com> wrote:

Have you tried contacting the other vendors? Intent to ship usually asks for that...

I was planning on filing bugs with the other browsers today, but this is a mostly minor bit of syntax (I believe the only places that Chrome takes a <resolution> type are in media queries and the sizes attribute, with webkit-image-set to follow).

Could you enumerate those places so that we can better assess the compatibility impact here?

One example where I can think this can have a negative compatibility impact is for current content which contains e.g. `@media screen and (min-resolution: 2x) `.

This MQ right now doesn't apply anywhere, but supporting the `x` resolution will make it applicable in Chromium, creating a potentially visible difference between different browsers for existing content.

One way to tackle this is to enumerate all the places where we'd support such a unit and use HTTPArchive data to see if such content currently exists.

Another possibility is to start wiring support for the unit, but only use that parsing support for UseCounters, to make sure this will have no impact at the moment.

The 3 places resolutions are accepted in media queries are for resolution, min-resolution, and max-resolution. The HTML sizes attribute would also be affected, as media query expressions are parsed within it. 

Hi,

Given that, do you have data showing that the compatibility risk is limited enough to ship this change? It seems we need that data to make an informed decision.

[Chris Nardi]

I'm currently looking into that with HTTPArchive data, but I keep hitting the free quota with my personal account for BigQuery and my Chromium account won't let me use BigQuery at all. Is there any way I can get access to BigQuery for HTTPArchive with my Chromium account?

[Yoav Weiss]

Could you include a link to the query you're trying to run?

I'm not aware of a patch to run them with the Chromium account, but maybe one of the Google employees can run it for you.

[Philip Jägenstedt]

If I understand the situation, this will strictly expand the cases where 'x' as a resolution works, right? And the cases that will begin to work will previously not have worked in any browser at any time? If that's the case, then I think that unless we suspect that such content exists out there, HTTPArchive research or adding use counters to check for it would be much more caution than we normally use when adding things. Any web-observable change can break things, after all.

2xChris, Yoav, WDYT?

--
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/CACj%3DBEgp%3DgV-PfVZcTwo4q_vOQ_f8EMy97zp2Ghq2Fs4mtmK%3Dw%40mail.gmail.com.

[Chris Nardi]

Your interpretation is correct. If we were to be able to do HTTPArchive research, I expect that few authors would have specified 'x' as a unit of resolution, as no other browsers currently support this (and 'dppx' would have the exact same meaning).

My only concern would be with serialization. As I noted in the spec issue, the original intent was for 'x' to be a "different unit" than 'dppx', with a one-to-one mapping. However, the spec doesn't make this clear, and makes it look like 'dppx' and 'x' are synonyms of each other. I'm not sure what makes the most sense here, as making the two units independent would also mean that Typed OM would need to pick up 'x' as a unit of resolution, as it currently is not mentioned (only 'dppx'). The spec also states that 'x' should be the canonical form, but this would change the canonical serialization of all <resolution> types.

[Philip Jägenstedt]

Hmm, sounds like resolving that before shipping this is important. What do you think the behavior should be? +Tab Atkins, WDYT?

[Yoav Weiss]

On Thu, Feb 22, 2018 at 12:38 PM Philip Jägenstedt <foo...@google.com> wrote:

Hmm, sounds like resolving that before shipping this is important. What do you think the behavior should be? +Tab Atkins, WDYT?

On Thu, Feb 22, 2018 at 1:55 AM Chris Nardi <cna...@chromium.org> wrote:

Your interpretation is correct. If we were to be able to do HTTPArchive research, I expect that few authors would have specified 'x' as a unit of resolution, as no other browsers currently support this (and 'dppx' would have the exact same meaning).

The main reason I asked for more data on this is that IIRC `x`/`dppx` were common source of confusion back in the day. 

To make sure, I ran the following query:

```

select url as url1

FROM [httparchive:har.2018_02_01_chrome_requests_bodies]  

WHERE REGEXP_MATCH(body, r'\(.*resolution:[\s]*[1-9\.]*x\)');

```

and got back 0 results. So, I think there's little risk of breakage here.

[Chris Nardi]

Since other properties (i.e. the srcset attribute on <image> tags) accept x to denote dppx, I might suggest 1) keeping x as a unit, but 2) making x be a synonym of dppx, and dppx be the "main" unit. That would mean that it would serialize/reify as dppx, but still be allowed anywhere a <resolution> type is accepted. That way, authors used to x can still use x, and only for serialization would authors notice a difference. 

On Fri, Mar 2, 2018 at 7:08 PM, Tab Atkins <taba...@google.com> wrote:

The reasoning behind adding 'x' in the first place is because that's
how Safari shipped the resolution part of image-set() (rather than
using one of the existing resolution units, or asking us to add a new
pixel-focused one).  For reasons I don't fully remember, the CSSWG
decided to add dppx instead of x, and I've been trying to make this
less awkward ever since.

Alternately, we could just drop this effort entirely, and accept that
x is just a weird legacy unit accepted solely in image-set(), and have
it serialize/reify as dppx.

[Chris Nardi]

Are there any additional thoughts on this? (Tab?) Should I add my last reply to the spec issue to be brought up with the WG?

[Chris Harrelson]

Hi Chris,

Sorry for the delay. Emil/Tab are going to try to add an agenda item to the next CSS working group meeting to resolve some of the remaining corner cases.

(other) Chris

[Yoav Weiss]

Tab & Emil - any updates from the discussion or ETA for when this will be discussed?

[Chris Nardi]

Speaking for myself, I was primarily suggesting it as a defensive move since all other browsers (at least to my knowledge) currently serialize resolution as `dppx`. Additionally, Typed OM does not even speak of `x` as a unit of resolution, so that would need to be changed if we continue with `x` as the canonical unit.

On Mon, Apr 30, 2018 at 2:22 PM, Tab Atkins <taba...@google.com> wrote:

We didn't remember to get it on the agenda for the f2f, but I'm opening an
issue in the GH repo right now.

The reason I set `x` as the "canonical unit" was because I figured
image-set() was the main place authors would see the values, and it made
the most sense to preserve the `x` there, as that's what Safari's current
behavior is anyway (since, in -webkit-image-set(), the `x` isn't a
<resolution>, it's just a random unit that is interpreted identically to
dppx...).

Do we have any actual compat concern with serializing computed-value
resolutions to `x` (rather than `dppx`), or is this just a defensive move
due to other browsers not yet supporting `x` in MQs either?

[Tab Atkins]

We didn't remember to get it on the agenda for the f2f, but I'm opening an
issue in the GH repo right now.

The reason I set `x` as the "canonical unit" was because I figured
image-set() was the main place authors would see the values, and it made
the most sense to preserve the `x` there, as that's what Safari's current
behavior is anyway (since, in -webkit-image-set(), the `x` isn't a
<resolution>, it's just a random unit that is interpreted identically to
dppx...).

Do we have any actual compat concern with serializing computed-value
resolutions to `x` (rather than `dppx`), or is this just a defensive move
due to other browsers not yet supporting `x` in MQs either?

[Philip Jägenstedt]

The spec issue is https://github.com/w3c/csswg-drafts/issues/2241.

Looks like a Gecko implementer and Blink implementer are in agreement, so is it now just a matter of making it so?

[Chris Nardi]

The spec has now been changed in https://github.com/w3c/csswg-drafts/commit/ce8046fd907c17d2e0ab6d0f7ed65f81eedcb89a so that 'dppx' will remain the canonical unit for resolution types.

Thoughts on proceeding with this intent following this change?

[Philip Jägenstedt]

LGTM1 to match the spec and share tests for it in the process :)

[Yoav Weiss]

LGTM2

[Chris Harrelson]

LGTM3

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/CACj%3DBEismi4Z2cKsO9S%3DNPuRkcYLHKBF5LZRkhuGgKV-6zrCtA%40mail.gmail.com.