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. 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> > >> . > >> > > > _______________________________________________ dev-tech-layout mailing list dev-tech-layout@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-layout
