On Wed, Jun 27, 2018 at 6:32 PM 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.
>

Weird! Yeah my phone is a iPhone 6s with AppleWebKit/605.1.15, iOS 11.4.
But I see it passes in Chrome for iOS (which is using the identical WebKit
under the hood), and verified that it does indeed also pass when I enable
the "constant properties" experimental feature. Very strange that somehow
my iPhone 6s would have this disabled, but your iPhone 6 would have it
enabled with the same . Anyway, thanks for the debugging!

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

Reply via email to