[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 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 <beccahug...@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 <mozilla.dev.tech.lay...@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:>> >> >> >> 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 >> >> <javascript:>> 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 <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:>> >> >> >>> >> 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 <javascript:>> 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 <javascript:>. >> >> >> 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> > . > _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
