Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Mike Taylor]

Bonus LGTM4 (Mike just beat me before I hit send).

On 4/13/22 8:23 AM, Yoav Weiss wrote:

LGTM2

Since the Yandex scripts are metrics scripts, there's little chance 
that their use would result in breakage, and the script is most likely 
doing some sort of "browser fingerprinting" and trying to see if the 
browser is indeed the one it claims to be. As such, I think that the 
risk here is low. It'd still make sense to watch out for incoming 
issues as Daniel suggested.


On Wed, Apr 13, 2022 at 2:17 PM Anders Hartvoll Ruud 
 wrote:


Yoav asked if I could do another HTTP Archive query to look for
sites that hit the counters, contain "not all" and contain at
least one media feature that's known to be unsupported in Chrome.
The idea would be to then look at what those sites do, check if
they break, etc.

Looking at a relevant table in MDN

,
I then queried
for 
r'(inverted\-colors)|(overflow\-block)|(overflow\-inline)|(prefers\-reduced\-data)|(scripting)'.
I found only a single interesting (non-Yandex-metrics) hit, which
was
https://marselshoes.by/assets/js/ym.js?hash=e427de0e11f74a8a57a8 .
The code was obfuscated/minimized, so it was a bit hard to see if
something would break from just reading the code. But at least
nothing appeared to be broken if I tried to shop for shoes with
the feature enabled.

Looking a bit closer today though, I think this is actually the
yandex metrics script as well, under a different name. (ym.js =
"yandex metrics"?). So maybe there are actually zero interesting
results.

Yeah, this is just an older version of 
https://mc.yandex.ru/metrika/tag.js (version: "4uzkmd4e35bv9wjiv", 
instead of "a8mjecangl5v275zywhk", which Yandex is currently serving. 
From what I can tell, (most of?) this script is just creating a 
fingerprint, so I'm less concerned about older versions returning a 
different result.




On Wed, Apr 13, 2022 at 11:59 AM Daniel Bratell
 wrote:

LGTM1, with a careful launch (as usual, but even more so).

The usage counter indicates that the ceiling of breakage is
quite high (in the 0.1% magnitude range) but I believe that
your analysis of is likely accurate and the real amount of
affected sites is likely to be much lower. Furthermore, any
breakage has a fair chance of not affecting a sites functionality.

/Daniel

On 2022-04-12 16:28, 'Joe Medley' via blink-dev wrote:

Please ping me if it ends up being 103. I don't like missing
things in the beta release post.

On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7
and...@chromium.org wrote:

On Mon, Apr 11, 2022 at 7:45 PM Joe Medley
 wrote:

Are you aiming for 102?


That's branching very soon, so definitely not. I'm not
really aiming for any particular release. But if you want
a prediction anyway, then likely 104.


On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio
Cobos Alvarez wrote:



On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> Ah, I'm not familiar with that way of doing
compat research. What would
> we gain from doing that vs. regular
use-counter + HTTP Archive?
>
> Do we expect those 0.1% to visibly break? (I
guess that depends on
> what they're feature testing for..)
>
>
> I would not expect that at all based on the
HTTP Archive query. If
> testing against "not all" was commonplace, I'd
expect more results
> beyond the two Yandex scripts. Or, perhaps it
is commonplace, but it
> happens mostly on features that actually *are*
supported at the moment.
>
> Just as an example (and to show that "not all"
testing isn't a myth),
> one of the few (non-Yandex-script) sites that
did show up was
> https://ww.sapo.pt , which
does the following:
>
> if(rule.mediaText.includes("not all") || ...)
>
> By the looks of it, it's an early-out related
to the theme switching,
> which prevents the code from amending the query
if prefers-color-scheme
> is not supported. Had we not
supported prefers-color-scheme, then I
> think the worst that 

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Yoav Weiss]

LGTM2

Since the Yandex scripts are metrics scripts, there's little chance that
their use would result in breakage, and the script is most likely doing
some sort of "browser fingerprinting" and trying to see if the browser is
indeed the one it claims to be. As such, I think that the risk here is low.
It'd still make sense to watch out for incoming issues as Daniel suggested.

On Wed, Apr 13, 2022 at 2:17 PM Anders Hartvoll Ruud 
wrote:

> Yoav asked if I could do another HTTP Archive query to look for sites that
> hit the counters, contain "not all" and contain at least one media feature
> that's known to be unsupported in Chrome. The idea would be to then look at
> what those sites do, check if they break, etc.
>
> Looking at a relevant table in MDN
> ,
> I then queried
> for 
> r'(inverted\-colors)|(overflow\-block)|(overflow\-inline)|(prefers\-reduced\-data)|(scripting)'.
> I found only a single interesting (non-Yandex-metrics) hit, which was
> https://marselshoes.by/assets/js/ym.js?hash=e427de0e11f74a8a57a8 . The
> code was obfuscated/minimized, so it was a bit hard to see if something
> would break from just reading the code. But at least nothing appeared to be
> broken if I tried to shop for shoes with the feature enabled.
>
> Looking a bit closer today though, I think this is actually the yandex
> metrics script as well, under a different name. (ym.js = "yandex
> metrics"?). So maybe there are actually zero interesting results.
>
> On Wed, Apr 13, 2022 at 11:59 AM Daniel Bratell 
> wrote:
>
>> LGTM1, with a careful launch (as usual, but even more so).
>>
>> The usage counter indicates that the ceiling of breakage is quite high
>> (in the 0.1% magnitude range) but I believe that your analysis of is likely
>> accurate and the real amount of affected sites is likely to be much lower.
>> Furthermore, any breakage has a fair chance of not affecting a sites
>> functionality.
>>
>> /Daniel
>> On 2022-04-12 16:28, 'Joe Medley' via blink-dev wrote:
>>
>> Please ping me if it ends up being 103. I don't like missing things in
>> the beta release post.
>>
>> On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7 and...@chromium.org
>> wrote:
>>
>>> On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:
>>>
 Are you aiming for 102?

>>>
>>> That's branching very soon, so definitely not. I'm not really aiming for
>>> any particular release. But if you want a prediction anyway, then likely
>>> 104.
>>>
>>>

 On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez
 wrote:

>
>
> On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> > Ah, I'm not familiar with that way of doing compat research. What
> would
> > we gain from doing that vs. regular use-counter + HTTP Archive?
> >
> > Do we expect those 0.1% to visibly break? (I guess that depends on
> > what they're feature testing for..)
> >
> >
> > I would not expect that at all based on the HTTP Archive query. If
> > testing against "not all" was commonplace, I'd expect more results
> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it
> > happens mostly on features that actually *are* supported at the
> moment.
> >
> > Just as an example (and to show that "not all" testing isn't a
> myth),
> > one of the few (non-Yandex-script) sites that did show up was
> > https://ww.sapo.pt , which does the following:
> >
> > if(rule.mediaText.includes("not all") || ...)
> >
> > By the looks of it, it's an early-out related to the theme
> switching,
> > which prevents the code from amending the query if
> prefers-color-scheme
> > is not supported. Had we not supported prefers-color-scheme, then I
> > think the worst that could happen is that we end up with a more
> > complicated query that still ultimately evaluates to false. Testing
> the
> > page with the feature enabled (with and without dark mode
> preference),
> > their color switcher still works normally.
> >
> > That is just one site though, it's probably theoretically possible
> to
> > write *something* that breaks. I did try to look at the "sample
> URLs"
> > for the counters, but I couldn't actually reproduce the counters
> being hit.
>
>
> It's a thing that even Google DevRel people have recommended in the
> past, ftr :)
>
> https://web.dev/prefers-color-scheme/#supporting-dark-mode
>
>
>>> Ouch ...
>>>
>>>
 But if you have data to indicate this is not a problem in the wild I'd
> be happy to implement it in Gecko after you ship this change.
>
> Cheers,
>
> -- Emilio
>
 --
>> 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

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Anders Hartvoll Ruud]

Yoav asked if I could do another HTTP Archive query to look for sites that
hit the counters, contain "not all" and contain at least one media feature
that's known to be unsupported in Chrome. The idea would be to then look at
what those sites do, check if they break, etc.

Looking at a relevant table in MDN
,
I then queried
for 
r'(inverted\-colors)|(overflow\-block)|(overflow\-inline)|(prefers\-reduced\-data)|(scripting)'.
I found only a single interesting (non-Yandex-metrics) hit, which was
https://marselshoes.by/assets/js/ym.js?hash=e427de0e11f74a8a57a8 . The code
was obfuscated/minimized, so it was a bit hard to see if something would
break from just reading the code. But at least nothing appeared to be
broken if I tried to shop for shoes with the feature enabled.

Looking a bit closer today though, I think this is actually the yandex
metrics script as well, under a different name. (ym.js = "yandex
metrics"?). So maybe there are actually zero interesting results.

On Wed, Apr 13, 2022 at 11:59 AM Daniel Bratell  wrote:

> LGTM1, with a careful launch (as usual, but even more so).
>
> The usage counter indicates that the ceiling of breakage is quite high (in
> the 0.1% magnitude range) but I believe that your analysis of is likely
> accurate and the real amount of affected sites is likely to be much lower.
> Furthermore, any breakage has a fair chance of not affecting a sites
> functionality.
>
> /Daniel
> On 2022-04-12 16:28, 'Joe Medley' via blink-dev wrote:
>
> Please ping me if it ends up being 103. I don't like missing things in the
> beta release post.
>
> On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7 and...@chromium.org wrote:
>
>> On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:
>>
>>> Are you aiming for 102?
>>>
>>
>> That's branching very soon, so definitely not. I'm not really aiming for
>> any particular release. But if you want a prediction anyway, then likely
>> 104.
>>
>>
>>>
>>> On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:
>>>


 On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
 > Ah, I'm not familiar with that way of doing compat research. What
 would
 > we gain from doing that vs. regular use-counter + HTTP Archive?
 >
 > Do we expect those 0.1% to visibly break? (I guess that depends on
 > what they're feature testing for..)
 >
 >
 > I would not expect that at all based on the HTTP Archive query. If
 > testing against "not all" was commonplace, I'd expect more results
 > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it
 > happens mostly on features that actually *are* supported at the
 moment.
 >
 > Just as an example (and to show that "not all" testing isn't a myth),
 > one of the few (non-Yandex-script) sites that did show up was
 > https://ww.sapo.pt , which does the following:
 >
 > if(rule.mediaText.includes("not all") || ...)
 >
 > By the looks of it, it's an early-out related to the theme switching,
 > which prevents the code from amending the query if
 prefers-color-scheme
 > is not supported. Had we not supported prefers-color-scheme, then I
 > think the worst that could happen is that we end up with a more
 > complicated query that still ultimately evaluates to false. Testing
 the
 > page with the feature enabled (with and without dark mode
 preference),
 > their color switcher still works normally.
 >
 > That is just one site though, it's probably theoretically possible to
 > write *something* that breaks. I did try to look at the "sample URLs"
 > for the counters, but I couldn't actually reproduce the counters
 being hit.


 It's a thing that even Google DevRel people have recommended in the
 past, ftr :)

 https://web.dev/prefers-color-scheme/#supporting-dark-mode


>> Ouch ...
>>
>>
>>> But if you have data to indicate this is not a problem in the wild I'd
 be happy to implement it in Gecko after you ship this change.

 Cheers,

 -- Emilio

>>> --
> 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/87a783d4-dbd7-4b0c-8ba1-7a118a87d759n%40chromium.org
> 
> .
>
>

-- 
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 we

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Daniel Bratell]

LGTM1, with a careful launch (as usual, but even more so).

The usage counter indicates that the ceiling of breakage is quite high 
(in the 0.1% magnitude range) but I believe that your analysis of is 
likely accurate and the real amount of affected sites is likely to be 
much lower. Furthermore, any breakage has a fair chance of not affecting 
a sites functionality.


/Daniel

On 2022-04-12 16:28, 'Joe Medley' via blink-dev wrote:
Please ping me if it ends up being 103. I don't like missing things in 
the beta release post.


On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7 and...@chromium.org wrote:

On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:

Are you aiming for 102?


That's branching very soon, so definitely not. I'm not really
aiming for any particular release. But if you want a prediction
anyway, then likely 104.


On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos
Alvarez wrote:



On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> Ah, I'm not familiar with that way of doing compat
research. What would
> we gain from doing that vs. regular use-counter + HTTP
Archive?
>
> Do we expect those 0.1% to visibly break? (I guess that
depends on
> what they're feature testing for..)
>
>
> I would not expect that at all based on the HTTP Archive
query. If
> testing against "not all" was commonplace, I'd expect
more results
> beyond the two Yandex scripts. Or, perhaps it is
commonplace, but it
> happens mostly on features that actually *are* supported
at the moment.
>
> Just as an example (and to show that "not all" testing
isn't a myth),
> one of the few (non-Yandex-script) sites that did show
up was
> https://ww.sapo.pt , which does the
following:
>
> if(rule.mediaText.includes("not all") || ...)
>
> By the looks of it, it's an early-out related to the
theme switching,
> which prevents the code from amending the query if
prefers-color-scheme
> is not supported. Had we not
supported prefers-color-scheme, then I
> think the worst that could happen is that we end up with
a more
> complicated query that still ultimately evaluates to
false. Testing the
> page with the feature enabled (with and without dark
mode preference),
> their color switcher still works normally.
>
> That is just one site though, it's probably
theoretically possible to
> write *something* that breaks. I did try to look at the
"sample URLs"
> for the counters, but I couldn't actually reproduce the
counters being hit.


It's a thing that even Google DevRel people have
recommended in the
past, ftr :)

https://web.dev/prefers-color-scheme/#supporting-dark-mode


Ouch ...

But if you have data to indicate this is not a problem in
the wild I'd
be happy to implement it in Gecko after you ship this change.

Cheers,

-- Emilio

--
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/87a783d4-dbd7-4b0c-8ba1-7a118a87d759n%40chromium.org 
.


--
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/9e520e75-783c-d2d8-df68-26fa9bb74ff8%40gmail.com.

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

['Joe Medley' via blink-dev]

Please ping me if it ends up being 103. I don't like missing things in the 
beta release post.

On Tuesday, April 12, 2022 at 12:23:37 AM UTC-7 and...@chromium.org wrote:

> On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:
>
>> Are you aiming for 102?
>>
>
> That's branching very soon, so definitely not. I'm not really aiming for 
> any particular release. But if you want a prediction anyway, then likely 
> 104. 
>  
>
>>
>> On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:
>>
>>>
>>>
>>> On 4/11/22 15:02, Anders Hartvoll Ruud wrote: 
>>> > Ah, I'm not familiar with that way of doing compat research. What 
>>> would 
>>> > we gain from doing that vs. regular use-counter + HTTP Archive? 
>>> > 
>>> > Do we expect those 0.1% to visibly break? (I guess that depends on 
>>> > what they're feature testing for..) 
>>> > 
>>> > 
>>> > I would not expect that at all based on the HTTP Archive query. If 
>>> > testing against "not all" was commonplace, I'd expect more results 
>>> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it 
>>> > happens mostly on features that actually *are* supported at the 
>>> moment. 
>>> > 
>>> > Just as an example (and to show that "not all" testing isn't a myth), 
>>> > one of the few (non-Yandex-script) sites that did show up was 
>>> > https://ww.sapo.pt , which does the following: 
>>> > 
>>> > if(rule.mediaText.includes("not all") || ...) 
>>> > 
>>> > By the looks of it, it's an early-out related to the theme switching, 
>>> > which prevents the code from amending the query if 
>>> prefers-color-scheme 
>>> > is not supported. Had we not supported prefers-color-scheme, then I 
>>> > think the worst that could happen is that we end up with a more 
>>> > complicated query that still ultimately evaluates to false. Testing 
>>> the 
>>> > page with the feature enabled (with and without dark mode preference), 
>>> > their color switcher still works normally. 
>>> > 
>>> > That is just one site though, it's probably theoretically possible to 
>>> > write *something* that breaks. I did try to look at the "sample URLs" 
>>> > for the counters, but I couldn't actually reproduce the counters being 
>>> hit. 
>>>
>>>
>>> It's a thing that even Google DevRel people have recommended in the 
>>> past, ftr :) 
>>>
>>> https://web.dev/prefers-color-scheme/#supporting-dark-mode 
>>>
>>>
> Ouch ... 
>  
>
>> But if you have data to indicate this is not a problem in the wild I'd 
>>> be happy to implement it in Gecko after you ship this change. 
>>>
>>> Cheers, 
>>>
>>> -- Emilio 
>>>
>>

-- 
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/87a783d4-dbd7-4b0c-8ba1-7a118a87d759n%40chromium.org.

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Anders Hartvoll Ruud]

On Mon, Apr 11, 2022 at 7:45 PM Joe Medley  wrote:

> Are you aiming for 102?
>

That's branching very soon, so definitely not. I'm not really aiming for
any particular release. But if you want a prediction anyway, then likely
104.


>
> On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:
>
>>
>>
>> On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
>> > Ah, I'm not familiar with that way of doing compat research. What would
>> > we gain from doing that vs. regular use-counter + HTTP Archive?
>> >
>> > Do we expect those 0.1% to visibly break? (I guess that depends on
>> > what they're feature testing for..)
>> >
>> >
>> > I would not expect that at all based on the HTTP Archive query. If
>> > testing against "not all" was commonplace, I'd expect more results
>> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it
>> > happens mostly on features that actually *are* supported at the moment.
>> >
>> > Just as an example (and to show that "not all" testing isn't a myth),
>> > one of the few (non-Yandex-script) sites that did show up was
>> > https://ww.sapo.pt , which does the following:
>> >
>> > if(rule.mediaText.includes("not all") || ...)
>> >
>> > By the looks of it, it's an early-out related to the theme switching,
>> > which prevents the code from amending the query if prefers-color-scheme
>> > is not supported. Had we not supported prefers-color-scheme, then I
>> > think the worst that could happen is that we end up with a more
>> > complicated query that still ultimately evaluates to false. Testing the
>> > page with the feature enabled (with and without dark mode preference),
>> > their color switcher still works normally.
>> >
>> > That is just one site though, it's probably theoretically possible to
>> > write *something* that breaks. I did try to look at the "sample URLs"
>> > for the counters, but I couldn't actually reproduce the counters being
>> hit.
>>
>>
>> It's a thing that even Google DevRel people have recommended in the
>> past, ftr :)
>>
>> https://web.dev/prefers-color-scheme/#supporting-dark-mode
>>
>>
Ouch ...


> But if you have data to indicate this is not a problem in the wild I'd
>> be happy to implement it in Gecko after you ship this change.
>>
>> Cheers,
>>
>> -- Emilio
>>
>

-- 
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/CAKFBnUpmXok-Rt-8KjGa39OEX%2B0xrvA2ytnv3uUKUJP5WDd_%3DA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

['Joe Medley' via blink-dev]

Are you aiming for 102?

On Monday, April 11, 2022 at 7:17:45 AM UTC-7 Emilio Cobos Alvarez wrote:

>
>
> On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
> > Ah, I'm not familiar with that way of doing compat research. What would 
> > we gain from doing that vs. regular use-counter + HTTP Archive?
> > 
> > Do we expect those 0.1% to visibly break? (I guess that depends on
> > what they're feature testing for..)
> > 
> > 
> > I would not expect that at all based on the HTTP Archive query. If 
> > testing against "not all" was commonplace, I'd expect more results 
> > beyond the two Yandex scripts. Or, perhaps it is commonplace, but it 
> > happens mostly on features that actually *are* supported at the moment.
> > 
> > Just as an example (and to show that "not all" testing isn't a myth), 
> > one of the few (non-Yandex-script) sites that did show up was 
> > https://ww.sapo.pt , which does the following:
> > 
> > if(rule.mediaText.includes("not all") || ...)
> > 
> > By the looks of it, it's an early-out related to the theme switching, 
> > which prevents the code from amending the query if prefers-color-scheme 
> > is not supported. Had we not supported prefers-color-scheme, then I 
> > think the worst that could happen is that we end up with a more 
> > complicated query that still ultimately evaluates to false. Testing the 
> > page with the feature enabled (with and without dark mode preference), 
> > their color switcher still works normally.
> > 
> > That is just one site though, it's probably theoretically possible to 
> > write *something* that breaks. I did try to look at the "sample URLs" 
> > for the counters, but I couldn't actually reproduce the counters being 
> hit.
>
>
> It's a thing that even Google DevRel people have recommended in the 
> past, ftr :)
>
> https://web.dev/prefers-color-scheme/#supporting-dark-mode
>
> But if you have data to indicate this is not a problem in the wild I'd 
> be happy to implement it in Gecko after you ship this change.
>
> Cheers,
>
> -- Emilio
>

-- 
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/c3a38a8f-2029-4e05-a4f1-6f651f2fc5d1n%40chromium.org.

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Emilio Cobos Álvarez]

On 4/11/22 15:02, Anders Hartvoll Ruud wrote:
Ah, I'm not familiar with that way of doing compat research. What would 
we gain from doing that vs. regular use-counter + HTTP Archive?


Do we expect those 0.1% to visibly break? (I guess that depends on
what they're feature testing for..)


I would not expect that at all based on the HTTP Archive query. If 
testing against "not all" was commonplace, I'd expect more results 
beyond the two Yandex scripts. Or, perhaps it is commonplace, but it 
happens mostly on features that actually *are* supported at the moment.


Just as an example (and to show that "not all" testing isn't a myth), 
one of the few (non-Yandex-script) sites that did show up was 
https://ww.sapo.pt , which does the following:


if(rule.mediaText.includes("not all") || ...)

By the looks of it, it's an early-out related to the theme switching, 
which prevents the code from amending the query if prefers-color-scheme 
is not supported. Had we not supported prefers-color-scheme, then I 
think the worst that could happen is that we end up with a more 
complicated query that still ultimately evaluates to false. Testing the 
page with the feature enabled (with and without dark mode preference), 
their color switcher still works normally.


That is just one site though, it's probably theoretically possible to 
write *something* that breaks. I did try to look at the "sample URLs" 
for the counters, but I couldn't actually reproduce the counters being hit.



It's a thing that even Google DevRel people have recommended in the 
past, ftr :)


  https://web.dev/prefers-color-scheme/#supporting-dark-mode

But if you have data to indicate this is not a problem in the wild I'd 
be happy to implement it in Gecko after you ship this change.


Cheers,

 -- Emilio

--
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/2b4b966a-a842-39a4-34f1-dcad87ca1360%40mozilla.com.

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Anders Hartvoll Ruud]

On Mon, Apr 11, 2022 at 1:57 PM Yoav Weiss  wrote:

> Thanks for working on this!!
>
> On Mon, Apr 11, 2022 at 1:41 PM Anders Hartvoll Ruud 
> wrote:
>
>> Contact emails
>>
>>
>> *andr...@chromium.org kbabb...@microsoft.com
>> *Explainer
>>
>>
>>
>> *NoneThis article by Bramus
>> 
>> may be helpful.*Specification
>>
>>
>> *https://www.w3.org/TR/mediaqueries-4/#mq-range-context
>> *Summary
>>
>>
>>
>>
>> *Allows writing media queries using ordinary mathematical comparison
>> operators , and
>> adds support for or
>> , not
>> , nesting
>> , and the
>> special evaluation of “unknown”
>> 
>> features.Tiny example:Without this feature: @media (min-width: 100px)With
>> this feature: @media (width >= 100px)*Blink component
>>
>>
>> *Blink>CSS
>> *TAG
>> review
>>
>>
>> *Probably not needed(?)*TAG review status
>>
>>
>> *Not applicable*Risks
>>
>> Interoperability and Compatibility
>>
>>
>>
>>
>>
>>
>>
>> *Gecko: Shipped/Shipping
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=145
>> ) Except: - Support
>> for ``, due to concerns that are discussed below.- The
>> `  ` form, due to Issue 2791
>> , which was resolved as
>> no-change.WebKit: I sent an e-mail to webkit-dev just now. I’ll update
>> if/when I get a response. Related info: @container, which is implemented in
>> Safari TP, uses an almost identical syntax, so there appears to be no
>> fundamental objections, at least.Web developers: No signalsOther 
>> signals:*WebView
>> Application Risks
>>
>>
>>
>>
>>
>>
>> *Does this intent deprecate or change behavior of existing APIs, such
>> that it has potentially high risk for Android WebView-based
>> applications?One significant concern (raised by Emilio) is regarding the
>> “unknown”/ evaluation. Currently, a media query like
>> @media (unknown: 500kg) will parse to (and serialize as) “@media not all”.
>> (In mediaqueries-3, a media query with unknown parts doesn't fail parsing
>> in the normal sense, but instead becomes “not all”
>> ).
>> The concern is that authors compare the parsed result of a media query
>> condition against “not all” in order to detect features. For example:let
>> prefersContrastSupported = matchMedia("(prefers-contrast)").media != "not
>> all";With this I2S, prefers-contrast (and any other unknown feature
>> matching ) will appear to parse successfully, and won’t
>> be converted to “not all” anymore.To understand the impact of this, I added
>> some use-counters for various APIs which count whenever a media query that
>> would contain  is serialized:Window.matchMedia | ~0.1%
>> MediaList::mediaText
>> | ~0.1% *
>>
>
> Did you try turning these counters to UKM that would enable you to dig
> further in that usage?
>

Ah, I'm not familiar with that way of doing compat research. What would we
gain from doing that vs. regular use-counter + HTTP Archive?


> Do we expect those 0.1% to visibly break? (I guess that depends on what
> they're feature testing for..)
>

I would not expect that at all based on the HTTP Archive query. If testing
against "not all" was commonplace, I'd expect more results beyond the two
Yandex scripts. Or, perhaps it is commonplace, but it happens mostly on
features that actually *are* supported at the moment.

Just as an example (and to show that "not all" testing isn't a myth), one
of the few (non-Yandex-script) sites that did show up was https://ww.sapo.pt,
which does the following:

if(rule.mediaText.includes("not all") || ...)

By the looks of it, it's an early-out related to the theme switching, which
prevents the code from amending the query if prefers-color-scheme is not
supported. Had we not supported prefers-color-scheme, then I think the
worst that could happen is that we end up with a more complicated query
that still ultimately evaluates to false. Testing the page with the feature
enabled (with and without dark mode preference), their color switcher still
works normally.

That is just one site though, it's probably theoretically possible to write
*something* that breaks. I did try to look at the "sample URLs" for the
counters, but I couldn't actually reproduce the counters bein

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[一丝]

Does the current implementation support use in `@import`? For example:
`@import url('foo.css') screen and (width <= 1200px);`

在2022年4月11日星期一 UTC+8 19:57:12 写道：

> Thanks for working on this!!
>
> On Mon, Apr 11, 2022 at 1:41 PM Anders Hartvoll Ruud  
> wrote:
>
>> Contact emails
>>
>>
>> *and...@chromium.orgkbab...@microsoft.com*Explainer
>>
>>
>>
>> *NoneThis article by Bramus 
>> 
>>  
>> may be helpful.*Specification
>>
>>
>> *https://www.w3.org/TR/mediaqueries-4/#mq-range-context 
>> *Summary
>>
>>
>>
>>
>> *Allows writing media queries using ordinary mathematical comparison 
>> operators , and 
>> adds support for or 
>> , not 
>> , nesting 
>> , and the 
>> special evaluation of “unknown” 
>> 
>>  
>> features.Tiny example:Without this feature: @media (min-width: 100px)With 
>> this feature: @media (width >= 100px)*Blink component
>>
>>
>> *Blink>CSS 
>> *TAG
>>  
>> review
>>
>>
>> *Probably not needed(?)*TAG review status
>>
>>
>> *Not applicable*Risks
>>
>> Interoperability and Compatibility
>>
>>
>>
>>
>>
>>
>>
>> *Gecko: Shipped/Shipping 
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=145 
>> ) Except: - Support 
>> for ``, due to concerns that are discussed below.- The 
>> `  ` form, due to Issue 2791 
>> , which was resolved as 
>> no-change.WebKit: I sent an e-mail to webkit-dev just now. I’ll update 
>> if/when I get a response. Related info: @container, which is implemented in 
>> Safari TP, uses an almost identical syntax, so there appears to be no 
>> fundamental objections, at least.Web developers: No signalsOther 
>> signals:*WebView 
>> Application Risks
>>
>>
>>
>>
>>
>>
>> *Does this intent deprecate or change behavior of existing APIs, such 
>> that it has potentially high risk for Android WebView-based 
>> applications?One significant concern (raised by Emilio) is regarding the 
>> “unknown”/ evaluation. Currently, a media query like 
>> @media (unknown: 500kg) will parse to (and serialize as) “@media not all”. 
>> (In mediaqueries-3, a media query with unknown parts doesn't fail parsing 
>> in the normal sense, but instead becomes “not all” 
>> ).
>>  
>> The concern is that authors compare the parsed result of a media query 
>> condition against “not all” in order to detect features. For example:let 
>> prefersContrastSupported = matchMedia("(prefers-contrast)").media != "not 
>> all";With this I2S, prefers-contrast (and any other unknown feature 
>> matching ) will appear to parse successfully, and won’t 
>> be converted to “not all” anymore.To understand the impact of this, I added 
>> some use-counters for various APIs which count whenever a media query that 
>> would contain  is serialized:Window.matchMedia | ~0.1% 
>> MediaList::mediaText
>>  
>> | ~0.1% *
>>
>
> Did you try turning these counters to UKM that would enable you to dig 
> further in that usage? Do we expect those 0.1% to visibly break? (I guess 
> that depends on what they're feature testing for..)
>  
>
>>
>>
>>
>>
>>
>>
>>
>>
>> *CSSConditionRule.conditionText | ~0.007% 
>> Note: 
>> Chromestatus has a bug where the name does not show up for these counters.I 
>> then queried HTTP Archive for response bodies containing `not all` (in 
>> quotes) from sites that hit one of the above use-counters, and the results 
>> show that it’s almost entirely coming from the following two scripts [full 
>> data 
>> ]:
>>  
>> - https://mc.yandex.ru/metrika/tag.js 
>> - 
>> https://mc.yandex.ru/metrika/watch.js 
>> However, looking at the live version 
>> of those files in Chrome (Desktop), I can’t find “not all”. It would appear 
>> that they don’t use this technique anymore. (Or I’m not using the right 
>> headers/User-Agent in the request).This research is not perfect, e.g. there 
>> could be other ways of doing feature detection that does not involve “not 
>> all”, or people could be using .cssText,

Re: [blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Yoav Weiss]

Thanks for working on this!!

On Mon, Apr 11, 2022 at 1:41 PM Anders Hartvoll Ruud 
wrote:

> Contact emails
>
>
> *andr...@chromium.org kbabb...@microsoft.com
> *Explainer
>
>
>
> *NoneThis article by Bramus
> 
> may be helpful.*Specification
>
>
> *https://www.w3.org/TR/mediaqueries-4/#mq-range-context
> *Summary
>
>
>
>
> *Allows writing media queries using ordinary mathematical comparison
> operators , and
> adds support for or
> , not
> , nesting
> , and the
> special evaluation of “unknown”
> 
> features.Tiny example:Without this feature: @media (min-width: 100px)With
> this feature: @media (width >= 100px)*Blink component
>
>
> *Blink>CSS
> *TAG
> review
>
>
> *Probably not needed(?)*TAG review status
>
>
> *Not applicable*Risks
>
> Interoperability and Compatibility
>
>
>
>
>
>
>
> *Gecko: Shipped/Shipping
> (https://bugzilla.mozilla.org/show_bug.cgi?id=145
> ) Except: - Support
> for ``, due to concerns that are discussed below.- The
> `  ` form, due to Issue 2791
> , which was resolved as
> no-change.WebKit: I sent an e-mail to webkit-dev just now. I’ll update
> if/when I get a response. Related info: @container, which is implemented in
> Safari TP, uses an almost identical syntax, so there appears to be no
> fundamental objections, at least.Web developers: No signalsOther 
> signals:*WebView
> Application Risks
>
>
>
>
>
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?One
> significant concern (raised by Emilio) is regarding the
> “unknown”/ evaluation. Currently, a media query like
> @media (unknown: 500kg) will parse to (and serialize as) “@media not all”.
> (In mediaqueries-3, a media query with unknown parts doesn't fail parsing
> in the normal sense, but instead becomes “not all”
> ).
> The concern is that authors compare the parsed result of a media query
> condition against “not all” in order to detect features. For example:let
> prefersContrastSupported = matchMedia("(prefers-contrast)").media != "not
> all";With this I2S, prefers-contrast (and any other unknown feature
> matching ) will appear to parse successfully, and won’t
> be converted to “not all” anymore.To understand the impact of this, I added
> some use-counters for various APIs which count whenever a media query that
> would contain  is serialized:Window.matchMedia | ~0.1%
> MediaList::mediaText
> | ~0.1% *
>

Did you try turning these counters to UKM that would enable you to dig
further in that usage? Do we expect those 0.1% to visibly break? (I guess
that depends on what they're feature testing for..)


>
>
>
>
>
>
>
>
> *CSSConditionRule.conditionText | ~0.007%
> Note:
> Chromestatus has a bug where the name does not show up for these counters.I
> then queried HTTP Archive for response bodies containing `not all` (in
> quotes) from sites that hit one of the above use-counters, and the results
> show that it’s almost entirely coming from the following two scripts [full
> data
> ]:
> - https://mc.yandex.ru/metrika/tag.js
> -
> https://mc.yandex.ru/metrika/watch.js
> However, looking at the live version
> of those files in Chrome (Desktop), I can’t find “not all”. It would appear
> that they don’t use this technique anymore. (Or I’m not using the right
> headers/User-Agent in the request).This research is not perfect, e.g. there
> could be other ways of doing feature detection that does not involve “not
> all”, or people could be using .cssText, and I assume not the entire web is
> in the HTTP Archive. But overall I’m fairly confident that it’s not an
> exceedingly common practice. The risk seems worth the gain of avoiding
> future-proofing mistakes
> 
> for media queries.*Debuggability
>
>
>
> *The new syntax is 

[blink-dev] Intent to Ship: Media Queries Level 4 Syntax & Evaluation

[Anders Hartvoll Ruud]

Contact emails


*andr...@chromium.org kbabb...@microsoft.com
*Explainer



*NoneThis article by Bramus

may be helpful.*Specification


*https://www.w3.org/TR/mediaqueries-4/#mq-range-context
*Summary




*Allows writing media queries using ordinary mathematical comparison
operators , and
adds support for or
, not
, nesting
, and the
special evaluation of “unknown”

features.Tiny example:Without this feature: @media (min-width: 100px)With
this feature: @media (width >= 100px)*Blink component


*Blink>CSS
*TAG
review


*Probably not needed(?)*TAG review status


*Not applicable*Risks

Interoperability and Compatibility







*Gecko: Shipped/Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=145
) Except: - Support
for ``, due to concerns that are discussed below.- The
`  ` form, due to Issue 2791
, which was resolved as
no-change.WebKit: I sent an e-mail to webkit-dev just now. I’ll update
if/when I get a response. Related info: @container, which is implemented in
Safari TP, uses an almost identical syntax, so there appears to be no
fundamental objections, at least.Web developers: No signalsOther
signals:*WebView
Application Risks














*Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?One
significant concern (raised by Emilio) is regarding the
“unknown”/ evaluation. Currently, a media query like
@media (unknown: 500kg) will parse to (and serialize as) “@media not all”.
(In mediaqueries-3, a media query with unknown parts doesn't fail parsing
in the normal sense, but instead becomes “not all”
).
The concern is that authors compare the parsed result of a media query
condition against “not all” in order to detect features. For example:let
prefersContrastSupported = matchMedia("(prefers-contrast)").media != "not
all";With this I2S, prefers-contrast (and any other unknown feature
matching ) will appear to parse successfully, and won’t
be converted to “not all” anymore.To understand the impact of this, I added
some use-counters for various APIs which count whenever a media query that
would contain  is serialized:Window.matchMedia | ~0.1%
MediaList::mediaText
| ~0.1%
CSSConditionRule.conditionText
| ~0.007%
Note:
Chromestatus has a bug where the name does not show up for these counters.I
then queried HTTP Archive for response bodies containing `not all` (in
quotes) from sites that hit one of the above use-counters, and the results
show that it’s almost entirely coming from the following two scripts [full
data
]:
- https://mc.yandex.ru/metrika/tag.js
-
https://mc.yandex.ru/metrika/watch.js
However, looking at the live version
of those files in Chrome (Desktop), I can’t find “not all”. It would appear
that they don’t use this technique anymore. (Or I’m not using the right
headers/User-Agent in the request).This research is not perfect, e.g. there
could be other ways of doing feature detection that does not involve “not
all”, or people could be using .cssText, and I assume not the entire web is
in the HTTP Archive. But overall I’m fairly confident that it’s not an
exceedingly common practice. The risk seems worth the gain of avoiding
future-proofing mistakes

for media queries.*Debuggability



*The new syntax is automatically visible in devtools.*Is this feature fully
tested by web-platform-tests

?



*NoThe existing WPTs are not sufficient at the moment - I will complete the
coverage before shipping. Also some changes to existing tests will be
required in relation to the  handling: tests that verify
that some MQ parsed (or didn’t) will now (likely) always appear to have
parsed correctly due to . These tes