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
