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 <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/ > CAFeLsEKAUsa6CjXcp4vsWOmBa4yGVWZEOVTPkdf3bgrjdNYENQ%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 > -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy Check my Availability <https://freebusy.io/esheph...@mozilla.com> _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
