On Wed, 27 Jun 2018, 23:40 Yoav Weiss, <y...@yoav.ws> wrote: > On Thu, Jun 28, 2018 at 8:32 AM Yoav Weiss <y...@yoav.ws> wrote: > > > On Thu, Jun 28, 2018 at 12:32 AM Becca Hughes <beccahug...@chromium.org> > > 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 <beccahug...@chromium.org > > > >> 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> > 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 < > >>> beccahug...@chromium.org> > >>> > 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> > >>> >> wrote: > >>> >> > >>> >>> On Monday 2018-06-25 13:18 -0700, Becca Hughes wrote: > >>> >>> > >> On Fri, Jun 22, 2018 at 12:47 AM, Rune Lillesveen < > >>> >>> futh...@chromium.org> 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+unsubscr...@chromium.org. > >> 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 > > > >> . > >> > > > _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
