Intent to Ship: Display Cutout & CSS Environment Variables

[Becca Hughes]

Contact emails

becca...@chromium.org, mlam...@chromium.org

Spec

Display Cutout Design Doc

CSS env() Design Doc

CSSWG spec

Summary

We are adding support for display cutouts in Blink through CSS environment variables and the viewport-fit meta tag. This is to add support for the display cutout API that is being released in Android P.

Link to “Intent to Implement” blink-dev discussion

Is this feature supported on all six Blink platforms?

Android only for display cutout. CSS env() is supported on all platforms.

Demo link

There is a demo page here, however it needs a device running Android P and simulating a display cutout.

Debuggability

CSS environment variables display correctly under the element styles tab in devtools. At the moment you cannot simulate a cutout using devtools but there is a bug filed for this in the future.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: No signals

Safari: Shipped (link)

Web developers: No signals

Activation

Developers can use the display cutout emulation feature in Android for testing. Widespread adoption of this feature is blocked by the release of Android P which has the Display Cutout API.

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

This is not tested by web platform tests since it would require an internal API to simulate a display cutout.

Entry on the feature dashboard

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

[Ian Kilpatrick]

\o/

Are you able to add tests for things like the env() function gets parsed correctly (and tests like CSS.supports(), @supports rule, etc), and that getting/setting via the appropriate CSSOM APIs works as expected?

Additionally shouldn't it be possible to test that without the env() variable present the fallback works as expected, and APIs like getComputedStyle return the correct thing?

Thanks,

Ian

 

Entry on the feature dashboard

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

--
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/CAFeLsEK09eFUtyHO7V2ss2dHLFZximh0a9j0y85AFuwnFzWDHw%40mail.gmail.com.

[Becca Hughes]

How env() works with CSS.supports() and CSSOM APIs for env() have not been spec'd yet and are out of scope for this launch.

We have a bunch of unit tests that provide coverage and these do test that fallbacks work correctly too.

Thanks,

Becca

\o/

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

[Ian Kilpatrick]

Hi Becca,

Yeah - totally understand it is frustrating not having a spec yet. However WPT are super important to make sure that we obtain interoperability with other browsers even in this state however.

One way around this while waiting for the specification to be firmed up is to add a suite of tests marked with .tentative, see:

https://web-platform-tests.org/writing-tests/file-names.html

Doing this will ensure that we have the same interoperability with Safari, and that when a third implementation appears (and the spec still potentially being in this state) the third implementation can match the behaviour. Having two/three private test suites can potentially lead to poor interoperability, and make developers being frustrated with us.

On Thu, Jun 21, 2018 at 11:05 AM Becca Hughes <becca...@chromium.org> wrote:

How env() works with CSS.supports() and CSSOM APIs for env() have not been spec'd yet and are out of scope for this launch.

Unless I'm reading the implementation incorrectly it seems like these APIs will just work(tm), and should be in a test suite?

(e.g. a similar WPT test for @supports for var()).

We have a bunch of unit tests that provide coverage and these do test that fallbacks work correctly too.

Yeah the unit tests look great, but not having any WPT for other APIs which use this machinery (via. getComputedStyle, or element.style.setProperty, etc) can be problematic.

Thanks,

Becca

\o/

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

[Becca Hughes]

On Thu, Jun 21, 2018 at 11:35 AM, Ian Kilpatrick <ikilp...@google.com> wrote:

Hi Becca,

Yeah - totally understand it is frustrating not having a spec yet. However WPT are super important to make sure that we obtain interoperability with other browsers even in this state however.

One way around this while waiting for the specification to be firmed up is to add a suite of tests marked with .tentative, see:

https://web-platform-tests.org/writing-tests/file-names.html

Doing this will ensure that we have the same interoperability with Safari, and that when a third implementation appears (and the spec still potentially being in this state) the third implementation can match the behaviour. Having two/three private test suites can potentially lead to poor interoperability, and make developers being frustrated with us.

On Thu, Jun 21, 2018 at 11:05 AM Becca Hughes <becca...@chromium.org> wrote:

How env() works with CSS.supports() and CSSOM APIs for env() have not been spec'd yet and are out of scope for this launch.

Unless I'm reading the implementation incorrectly it seems like these APIs will just work(tm), and should be in a test suite?

(e.g. a similar WPT test for @supports for var()).

We can add a test for @supports but env() variables have their own namespace so things like CSSVariableReferenceValue will not work. This implementation only has UA provided variables which don't have the '--' prefix but in the future there is discussion about having user defined variables that do have the prefix so we probably want to wait for the spec before we fix that.

We have a bunch of unit tests that provide coverage and these do test that fallbacks work correctly too.

Yeah the unit tests look great, but not having any WPT for other APIs which use this machinery (via. getComputedStyle, or element.style.setProperty, etc) can be problematic.

Yes we can add WPT tests for fallbacks but there is no way to define variables at the moment so we test those yet.

 

Thanks,

Becca

\o/

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

[Becca Hughes]

There is a pending CL out with these WPT tests: https://chromium-review.googlesource.com/c/chromium/src/+/1111023

[Ian Kilpatrick]

Thanks!

I added some comments for additional things to test.

Ian

 

Thanks,

Becca

\o/

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

[Emilio Cobos Álvarez]

On 6/21/18 7:30 PM, Becca Hughes wrote:
> Risks
>
> Interoperability and Compatibility
>
> Edge: No signals
>
> Firefox: No signals

FWIW, signals from Mozilla's side are negative I'd say, at least until
there's a proper spec and agreement on which environment variables
should people implement and ship, and that they all have gone through
the relevant privacy review, the same way new CSS properties go through
a process to get in a spec.

The fact that all the variable names are not listed anywhere would make
it pretty hard for others to implement and keep up with changes. We'd
need to keep track of the WebKit and Blink repos, and figure out when
they or you ship more of these. I don't think such a situation would be
tractable. Relevant links are [1] and [2] in this regard.

On the other hand, we do have a bug on file to implement[3], and
potential use-cases (see dependent bugs). Plus, our mobile team would
also love it, I'd suspect.

But I don't think we'd ship this without those concerns addressed, and
I'd be really sad if Blink did that.

-- Emilio

[1]:
https://groups.google.com/d/msg/mozilla.dev.tech.layout/UpzhcwaRyrM/J5sv7pfXAAAJ
[2]:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ZS1mEwvN-5E/rQvcSx0fAgAJ
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1462233

[becca...@chromium.org]

+ Tab

This focus of this launch is Display Cutout and we want to launch part of CSS env() to provide backwards compatability in terms of what Safari has already shipped for the iPhone X.

The full spec for CSS env() has a lot more functionality that is still being worked out and that is out of scope for this 'lite' launch of env().

In terms of a list of all the variable names there is an issue here that is working on defining a list: https://github.com/w3c/csswg-drafts/issues/2630

Becca

[Rune Lillesveen]

On Fri, Jun 22, 2018 at 5:54 AM <becca...@chromium.org> wrote:

+ Tab

This focus of this launch is Display Cutout and we want to launch part of CSS env() to provide backwards compatability in terms of what Safari has already shipped for the iPhone X.

As others have mentioned, proper wpt tests is a requirement here. That will make you discover short-comings in the spec as well as interop with Safari.

The full spec for CSS env() has a lot more functionality that is still being worked out and that is out of scope for this 'lite' launch of env().

In terms of a list of all the variable names there is an issue here that is working on defining a list: https://github.com/w3c/csswg-drafts/issues/2630

The CSSWG resolved on four values and edits to be made to CSS Variables Level 2[1]. Do we have a resolution overriding that to put it in a separate spec?

I would not be comfortable shipping this without having these four values put in a spec with a description of what they are.

[1]https://github.com/w3c/csswg-drafts/issues/1693#issuecomment-330909067

--

Rune Lillesveen

[Becca Hughes]

On Fri, Jun 22, 2018 at 12:47 AM, Rune Lillesveen <fut...@chromium.org> wrote:

On Fri, Jun 22, 2018 at 5:54 AM <becca...@chromium.org> wrote:

+ Tab

This focus of this launch is Display Cutout and we want to launch part of CSS env() to provide backwards compatability in terms of what Safari has already shipped for the iPhone X.

As others have mentioned, proper wpt tests is a requirement here. That will make you discover short-comings in the spec as well as interop with Safari.

The pending CL has been updated with more comprehensive WPT tests.

 

The full spec for CSS env() has a lot more functionality that is still being worked out and that is out of scope for this 'lite' launch of env().

In terms of a list of all the variable names there is an issue here that is working on defining a list: https://github.com/w3c/csswg-drafts/issues/2630

The CSSWG resolved on four values and edits to be made to CSS Variables Level 2[1]. Do we have a resolution overriding that to put it in a separate spec?

I would not be comfortable shipping this without having these four values put in a spec with a description of what they are.

I am not sure about the resolution, I will let @Tab answer that one. 

I added a pull request to add them to the spec: https://github.com/w3c/csswg-drafts/pull/2807

[Becca Hughes]

The WPT tests have landed upstream.

[Becca Hughes]

It looks like Tab will be OOO for the next couple of weeks, but this shouldn't block launch.

[L. David Baron]

On Monday 2018-06-25 13:18 -0700, Becca Hughes wrote:
> >> On Fri, Jun 22, 2018 at 12:47 AM, Rune Lillesveen <fut...@chromium.org> wrote:
> >>> The CSSWG resolved on four values and edits to be made to CSS Variables
> >>> Level 2[1]. Do we have a resolution overriding that to put it in a separate
> >>> spec?
> >>>
> >>> I would not be comfortable shipping this without having these four
> >>> values put in a spec with a description of what they are.
> >>>
> >>
> >> I am not sure about the resolution, I will let @Tab answer that one.
> >>
> >> I added a pull request to add them to the spec: https://github.com/w3c/csswg-drafts/pull/2807
> >>
> >
> It looks like Tab will be OOO for the next couple of weeks, but this
> shouldn't block launch.

I think the underlying objection here is that we don't want to get
in a situation where multiple implementations are shipping a feature
that doesn't have a specification. I don't think that something
being in Tab's backlog of specification editing in an acceptable
resolution to that, given the size of his backlog.

I also don't want to be in a situation where Tab is the single
person gating new features; other people should be able to edit CSS
specifications, particularly when given appropriate mentoring and
advice.

So I'd be substantially happier here if there were a specification
before a second implementation shipped, but I also think getting
that specification done shouldn't require any one particular person
to be involved.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Becca Hughes]

The spec pull request to define the safe area variables has been merged and is now part of the spec.

(@David - thanks again for reviewing the PR)

[Rick Byers]

Becca, thank you for getting all the environment variables you're supporting added to some draft spec, and tentative web-platform-tests landed - I agree with the earlier discussions that this is a pre-requisite to shipping (even when Safari has sadly shipped without having invested in such engineering discipline).

Ideally we'd have the rest of the env() behavior that we're shipping fully specified somewhere (even if not yet agreed upon), but given that Safari has already shipped and developers are starting to depend on it, I'm pretty confident that either the spec will end up following what's already been shipped in Safari, or WebKit will agree on breaking changes we feel we can make. So I'm not convinced we'd get any real-world interoperability value by blocking our ship further on getting the additional details added to the spec, instead of just continuing to incubate and iterate.

However it is important to ensure we are actually shipping something that's interoperable with Safari including the edge cases. I just ran all the tests at https://w3c-test.org/css/css-env on an iPhone (iOS 11.4) and see that most of them are failing (eg. every "syntax" test fails with "assert_equals expected "rgba(0, 0, 0, 0)" but got "rgb(0, 128, 0)"). They're passing on a Mac (Safari 11.0.3) and when I use an iPhone X on browserstack.com (iOS 11, can't tell which point release), so I suspect one of Mobile safari's non-standard quirks (maybe something about viewport behavior?), but I didn't try to debug them. Do you have access to an iPhone you can try debugging with, just to double-check that we really are shipping something that behaves the same on Chrome Android as Safari iOS?

Rick

--
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/CAFeLsELTCuBL83Dd6kOnEfNQGUpdOJV7VnVeV-7Bo-78oraG6A%40mail.gmail.com.

[Becca Hughes]

Hi Rick,

I tested this on an iPhone 6 running iOS 11.4, as well as a Mac (Safari 11.1.1) and iPhone Simulator running iOS 11.4 on both the iPhone 8 and iPhone X and for me all the tests are passing. The Safari version is AppleWebKit/605.1.15 Mobile/15E148 Safari/604.1.

On your iPhone if you type in "show user agent" to Google in Safari it should show you what version of Safari you are running. I wonder if for some reason your iPhone is running an older build of Safari.

Thanks,

Becca

[Becca Hughes]

We have been looking into the test failures and believe we have found the cause. It looks like env() is switched off on some iOS devices.

The feature can be switched on by going to Settings > Safari > Advanced > Experimental Features > Constant Properties. With the feature enabled all the WPT tests pass.

On Tue, Jun 26, 2018 at 4:15 PM, Becca Hughes <becca...@chromium.org> wrote:

Hi Rick,

I tested this on an iPhone 6 running iOS 11.4, as well as a Mac (Safari
11.1.1) and iPhone Simulator running iOS 11.4 on both the iPhone 8 and
iPhone X and for me all the tests are passing. The Safari version is
AppleWebKit/605.1.15 Mobile/15E148 Safari/604.1.

On your iPhone if you type in "show user agent" to Google in Safari it
should show you what version of Safari you are running. I wonder if for
some reason your iPhone is running an older build of Safari.

Thanks,
Becca

On Tue, Jun 26, 2018 at 2:25 PM, Rick Byers <rby...@chromium.org> wrote:

>> <https://drafts.csswg.org/css-env-1/#safe-area-insets>.

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsELTCuBL83Dd6kOnEfNQGUpdOJV7VnVeV-7Bo-78oraG6A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

[Yoav Weiss]

On Thu, Jun 28, 2018 at 12:32 AM Becca Hughes <becca...@chromium.org> wrote:

We have been looking into the test failures and believe we have found the cause. It looks like env() is switched off on some iOS devices.

The feature can be switched on by going to Settings > Safari > Advanced > Experimental Features > Constant Properties. With the feature enabled all the WPT tests pass.

So, the feature is shipped in some iOS devices but not others? Do we know if it's a matter of Safari version? Or some other criteria?

 

 

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/CAFeLsELjgh5773%3DJpR7VdqqfUFqCpfQ7JzjN_ENdJhjafEABRA%40mail.gmail.com.

[Yoav Weiss]

On Thu, Jun 28, 2018 at 8:32 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Jun 28, 2018 at 12:32 AM Becca Hughes <becca...@chromium.org> wrote:

We have been looking into the test failures and believe we have found the cause. It looks like env() is switched off on some iOS devices.

The feature can be switched on by going to Settings > Safari > Advanced > Experimental Features > Constant Properties. With the feature enabled all the WPT tests pass.

So, the feature is shipped in some iOS devices but not others? Do we know if it's a matter of Safari version? Or some other criteria?

Or did they ship this only on some hardware devices but not others?

[Becca Hughes]

On Wed, 27 Jun 2018, 23:40 Yoav Weiss, <yo...@yoav.ws> wrote:

On Thu, Jun 28, 2018 at 8:32 AM Yoav Weiss <yo...@yoav.ws> wrote:

> On Thu, Jun 28, 2018 at 12:32 AM Becca Hughes <becca...@chromium.org>
> wrote:
>
>> We have been looking into the test failures and believe we have found the
>> cause. It looks like env() is switched off on some iOS devices.
>>
>> The feature can be switched on by going to Settings > Safari > Advanced >
>> Experimental Features > Constant Properties. With the feature enabled all
>> the WPT tests pass.
>>
>>
> So, the feature is shipped in some iOS devices but not others? Do we know
> if it's a matter of Safari version? Or some other criteria?
>

The original launch announcement from Apple cites that you need at least iOS 11.2 beta.

Or did they ship this only on some hardware devices but not others?

I am not sure about the exact details but at least in their repo it is on by default:

https://github.com/WebKit/webkit/blob/01ff8c715bb788e0d721948c7d7acd7d5cfa06c3/Source/WebKit/Shared/WebPreferences.yaml#L1058

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsELjgh5773%3DJpR7VdqqfUFqCpfQ7JzjN_ENdJhjafEABRA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

[Alex Russell]

Hey all,

API OWNERS met this morning and while we're not exercised about the lack of spec text, the linked design docs don't fill the role of an Explainer:

    https://docs.google.com/document/d/1cJs7GkdQolqOHns9k6v1UjCUb_LqTFVjZM-kc3TbNGI/edit?usp=sharing

That is, it isn't clear what problems this is solving, why these (relatively large) proposals are the correct way to solve them, or what the considered alternatives are. Rubber-stamping the launched-without-consultation (or even Origin Trial) additions of another vendor without that sort of deliberation is very much a non-goals, so if there are docs that could stand in for an Explainer here, that would help unblock my LGTM.

Thanks!

[Becca Hughes]

Here is an explainer for the feature: https://docs.google.com/document/d/1lbZi18_5cMlLOphpFqTbuI4B0YGykQvvtRbw6j67UyE/edit

Thanks,

Becca

On Thu, Jun 28, 2018 at 9:35 AM, 'Alex Russell' via mozilla.dev.tech.layout <mozilla.dev...@googlegroups.com> wrote:

Hey all,

API OWNERS met this morning and while we're not exercised about the lack of
spec text, the linked design docs don't fill the role of an Explainer:


  https://docs.google.com/document/d/1cJs7GkdQolqOHns9k6v1UjCUb_LqTFVjZM-kc3TbNGI/edit?usp=sharing

That is, it isn't clear what problems this is solving, why these
(relatively large) proposals are the correct way to solve them, or what the
considered alternatives are. Rubber-stamping the
launched-without-consultation (or even Origin Trial) additions of another
vendor without that sort of deliberation is very much a non-goals, so if
there are docs that could stand in for an Explainer here, that would help
unblock my LGTM.

Thanks!

On Thursday, June 28, 2018 at 7:24:48 AM UTC-7, Becca Hughes wrote:
>
>
>

> On Wed, 27 Jun 2018, 23:40 Yoav Weiss, <yo...@yoav.ws <javascript:>>
> wrote:
>
>> On Thu, Jun 28, 2018 at 8:32 AM Yoav Weiss <yo...@yoav.ws <javascript:>>

>> wrote:
>>
>> > On Thu, Jun 28, 2018 at 12:32 AM Becca Hughes <becca...@chromium.org

>> <javascript:>>

>> > wrote:
>> >
>> >> We have been looking into the test failures and believe we have found
>> the
>> >> cause. It looks like env() is switched off on some iOS devices.
>> >>
>> >> The feature can be switched on by going to Settings > Safari >
>> Advanced >
>> >> Experimental Features > Constant Properties. With the feature enabled
>> all
>> >> the WPT tests pass.
>> >>
>> >>
>> > So, the feature is shipped in some iOS devices but not others? Do we
>> know
>> > if it's a matter of Safari version? Or some other criteria?
>> >
>>
>
> The original launch announcement from Apple cites that you need at least
> iOS 11.2 beta.
>
>
>> Or did they ship this only on some hardware devices but not others?
>>
>
> I am not sure about the exact details but at least in their repo it is on
> by default:
>
>
> https://github.com/WebKit/webkit/blob/01ff8c715bb788e0d721948c7d7acd7d5cfa06c3/Source/WebKit/Shared/WebPreferences.yaml#L1058
>
>
>>
>> >
>> >
>> >
>> >> On Tue, Jun 26, 2018 at 4:15 PM, Becca Hughes <becca...@chromium.org

>> <javascript:>>

>> >>> becca...@chromium.org <javascript:>>

>> >>> > wrote:
>> >>> >
>> >>> >> The spec pull request to define the safe area variables has been
>> >>> merged
>> >>> >> and is now part of the spec
>> >>>
>> >> >> <https://drafts.csswg.org/css-env-1/#safe-area-insets>.
>> >>
>> >>
>> >>> >>
>> >>> >> (@David - thanks again for reviewing the PR)
>> >>> >>
>> >>> >> On Mon, Jun 25, 2018 at 2:55 PM, L. David Baron <dba...@dbaron.org

>> <javascript:>>

>> >> email to blink-dev+...@chromium.org <javascript:>.

[Rick Byers]

On Wed, Jun 27, 2018 at 6:32 PM Becca Hughes <becca...@chromium.org> wrote:

We have been looking into the test failures and believe we have found the cause. It looks like env() is switched off on some iOS devices.

The feature can be switched on by going to Settings > Safari > Advanced > Experimental Features > Constant Properties. With the feature enabled all the WPT tests pass.

Weird! Yeah my phone is a iPhone 6s with AppleWebKit/605.1.15, iOS 11.4. But I see it passes in Chrome for iOS (which is using the identical WebKit under the hood), and verified that it does indeed also pass when I enable the "constant properties" experimental feature. Very strange that somehow my iPhone 6s would have this disabled, but your iPhone 6 would have it enabled with the same . Anyway, thanks for the debugging!

[Rick Byers]

[Dropping mozilla-dev-tech-layout since it's a subscribers-only list]

That explainer looks great to me, thanks! I added a link to the chromestatus entry.

It's sad that we still don't really have a proper spec for the meta viewport tag, just the apparently stalled device adaptation spec. But at least between that and the round display draft there's kinda an existing definition for the viewport-fit token. I guess there's not really any reasonable way to write a web-platform-test for the viewport-fit behavior. We'd have to add a WebDriver command to simulate a display cut-out, and also come up with some mitigation for the fact that mobile viewports are really an Android-only behavior in Chrome at the moment. That's a fair amount of work, and IMHO not worth blocking this feature on.

LGTM2

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

[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/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com.

[Rick Byers]

Sorry I got this thread confused with another - my LGTM2 was actually LGTM1, so we still need a 3rd.

[Rick Byers]

Also I filed this WebKit bug after talking to Dean Jackson who built this feature for Safari.

[Becca Hughes]

Thank you Chris and Rick for the LGTMs. We still need one more API owner to approve.

On Thu, Jun 28, 2018, 5:02 PM Chris Harrelson <chri...@chromium.org> wrote:

LGTM3

On Thu, Jun 28, 2018 at 12:21 PM Rick Byers <rby...@chromium.org> wrote:

> [Dropping mozilla-dev-tech-layout since it's a subscribers-only list]
>
> That explainer looks great to me, thanks! I added a link to the chromestatus

> entry <https://www.chromestatus.com/feature/5710044637167616>.

>
> It's sad that we still don't really have a proper spec for the meta
> viewport tag, just the apparently stalled device adaptation spec

> <https://drafts.csswg.org/css-device-adapt/>. But at least between that

> and the round display draft

> <https://drafts.csswg.org/css-round-display/#viewport-fit-descriptor> there's

> kinda an existing definition for the viewport-fit token. I guess there's
> not really any reasonable way to write a web-platform-test for the
> viewport-fit behavior. We'd have to add a WebDriver command to simulate a

> display cut-out <https://github.com/web-platform-tests/wpt/issues/11718>,

> and also come up with some mitigation

> <https://github.com/web-platform-tests/wpt/issues/11717> for the fact

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsE%2BkJugFcOhaMxtBThZezroAPZTY1QaMSXW0oHDnu105Yg%40mail.gmail.com?utm_medium=email&utm_source=footer>

>> .
>>
> --
> 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/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

[Ojan Vafai]

LGTM3

I'm torn about what standard to hold ourselves to when another vendor has already shipped an API without a spec. I think a basic explainer and a reasonable set of web platform tests is a good minimum bar though to ensure interop with the already shipped API. So, thanks for taking that on.

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

[Becca Hughes]

Thanks everyone!

> 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/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

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

[Eric Shepherd (Sheppy)]

For what it's worth, a basic explainer and tests are also a helpful minimum when the technical documentation folks get into it.

>> >> mozilla.dev.tech.layout <mozilla.dev.tech.layout@googlegroups.com>

>> > 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/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com
>> > <
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-KpYMW6Sr_a3JPZPjGWmisFM0%3D%2BP6w3nofH9MpEcQ7KQ%40mail.gmail.com?utm_medium=email&utm_source=footer
>> >
>> > .
>> >
>>
> --
> 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/CAFeLsEKAUsa6CjXcp4vsWOmBa4yGVWZEOVTPkdf3bgrjdNYENQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEKAUsa6CjXcp4vsWOmBa4yGVWZEOVTPkdf3bgrjdNYENQ%40mail.gmail.com?utm_medium=email&utm_source=footer>

> .
>
_______________________________________________
dev-tech-layout mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-layout

--

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability