Thanks everyone! On Fri, Jun 29, 2018 at 1:53 PM, Ojan Vafai <o...@chromium.org> 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 <beccahug...@chromium.org> > 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 <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/01ff8c715bb788e0d721948c7d7acd >>> 7d5cfa06c3/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> >>> > . >>> > >>> >> -- >> 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/CAFeLsEKAUsa6CjXcp4vsWOmBa4yGV >> WZEOVTPkdf3bgrjdNYENQ%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-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
