Also I filed this WebKit bug <https://bugs.webkit.org/show_bug.cgi?id=187151> after talking to Dean Jackson who built this feature for Safari.
On Thu, Jun 28, 2018 at 3:31 PM Rick Byers <rby...@chromium.org> wrote: > Sorry I got this thread confused with another - my LGTM2 was actually > LGTM1, so we still need a 3rd. > > On Thu, Jun 28, 2018 at 3:28 PM Chris Harrelson <chris...@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 >>> 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> >>>> . >>>> >>> -- >>> 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+unsubscr...@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> >>> . >>> >> _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
