From:  "Eric Shepherd (Sheppy)" <eshepherd@mozilla.com>
Date:  04 Jul 2018 04:29:34 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.layout
Subject:  

Re: [blink-dev] Intent to Ship: Display Cutout & CSS Environment Variables

NNTP-Posting-Host:  63.245.214.181

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

On Fri, Jun 29, 2018 at 4:53 PM, Ojan Vafai  wrote:

> 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.
>
> On Fri, Jun 29, 2018 at 7:15 AM Becca Hughes 
> wrote:
>
> > 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 
> > wrote:
> >
> >> LGTM3
> >>
> >> On Thu, Jun 28, 2018 at 12:21 PM Rick Byers 
> 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 .
> >> >
> >> > 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  11718
> >> >,
> >> > 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
> >> >
> >> > On Thu, Jun 28, 2018 at 1:48 PM Becca Hughes <
> beccahughes@chromium.org>
> >> > wrote:
> >> >
> >> >> 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 
> >> 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,  >> >
> >> >>> > wrote:
> >> >>> >
> >> >>> >> On Thu, Jun 28, 2018 at 8:32 AM Yoav Weiss  >> >>> >
> >> >>> >> 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/01ff8c715bb788e0d721948c7d7acd
> 7d5cfa06c3/Source/WebKit/Shared/WebPreferences.yaml#L1058
> >> >>> >
> >> >>> >
> >> >>> >>
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> >> 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:
> >> >>> >> >>>
> >> >>> >> >>> > 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
> >> >>> >> >>> >
> >> >>> >> >>> >
> >> >>> >> >>> > On Tue, Jun 26, 2018 at 12:57 AM Becca Hughes <
> >> >>> >> >>> becca...@chromium.org >
> >> >>> >> >>> > wrote:
> >> >>> >> >>> >
> >> >>> >> >>> >> 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)
> >> >>> >> >>> >>
> >> >>> >> >>> >> On Mon, Jun 25, 2018 at 2:55 PM, L. David Baron <
> >> >>> dba...@dbaron.org
> >> >>> >> >
> >> >>> >> >>> >> wrote:
> >> >>> >> >>> >>
> >> >>> >> >>> >>> 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)
> >> >>> >> >>> >>>
> >> >>> >> >>> >>
> >> >>> >> >>> >> --
> >> >>> >> >>> >> 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/CAFeLsELTCuBL83Dd6kOnEfNQGUpdO
> >> >>> >> >>> >> JV7VnVeV-7Bo-78oraG6A%40mail.gmail.com
> >> >>> >> >>>
> >> >>> >> >> >> <
> >> >>> >> >>>
> >> >>> >>
> >> >>>
> >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/
> CAFeLsELTCuBL83Dd6kOnEfNQGUpdOJV7VnVeV-7Bo-78oraG6A%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/CAFeLsELjgh5773%3DJpR7VdqqfUFqCpfQ7JzjN_ENdJhjafEABRA%40mail.gmail.com
> >> >>> >> >> <
> >> >>> >>
> >> >>>
> >> https://groups.google.com/a/chromium.org/d/msgid/blink-
> dev/CAFeLsELjgh5773%3DJpR7VdqqfUFqCpfQ7JzjN_ENdJhjafEABRA%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/CAFeLsE%
> 2BkJugFcOhaMxtBThZezroAPZTY1QaMSXW0oHDnu105Yg%40mail.gmail.com
> >> >> <
> >> 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+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
> >  CAFeLsEKAUsa6CjXcp4vsWOmBa4yGVWZEOVTPkdf3bgrjdNYENQ%40mail.
> gmail.com?utm_medium=email&utm_source=footer>
> > .
> >
> _______________________________________________
> dev-tech-layout mailing list
> dev-tech-layout@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