Thanks Dan for raising the compat concerns here. It seems like a mistake
that the original Intent says "None" for that, and I think we need to get
that section of the Chrome Status entry fleshed out before considering
approvals here.

What I'm hearing so far is that we think the compat risks might be small
because Gecko and WebKit are already using strict parsing. That's
something, but can we do better? For example:

   - Is there any upper bound on the potential number of broken page views?
   Ideally we'd have a use counter for how many times the lenient parsing is
   triggered, but for an upper bound even just a use counter for how many
   times these arguments are supplied to getComputedStyle()/new
   KeyframeEffect() would help.
   - Can we do an HTTP archive analysis of some sort?


On Sun, Mar 10, 2024 at 5:55 PM Noam Rosenthal <nrosent...@chromium.org>
wrote:

>
>
> On Fri, Mar 8, 2024 at 11:56 PM 'Dan Clark' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Am I correct in understanding that Gecko already mostly matches the
>> behavior in the spec? I see that Firefox also fails most of the WPTs at
>> https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo-with-argument.html?label=master&label=experimental&aligned,
>> but I guess that's because they haven't shipped ::highlight() pseudos.
>
> Correct, it's because of ::highlight. It passes most of the tests in
> https://wpt.fyi/results/css/cssom/getComputedStyle-pseudo.html?label=master&label=experimental&aligned
> .
>
>
>> How are you thinking about the compatibility risk? If we're making the
>> parsing stricter in certain ways, presumably sites depending on that
>> behavior could break. Omitting the ":" seems like it could be a
>> particularly easy mistake to make. On the other hand the fact that WebKit
>> (and I guess Gecko) already did it is an encouraging signal.
>>
>
> Correct. Also, intending to keep current behavior for old pseudos that
> support single-colon in regular CSS (before, after, first-line,
> first-letter). If there are other exceptions with a lot of existing code we
> can consider adding them here.
>
> The way I'm thinking about this from a compat perspective is that if we
> keep supporting single-colon/no-colon for all pseudos, there would be more
> non-spec-compliant code written with those, that would seem to work in
> chrome while developing and then not work in other browsers. So aligning
> with the spec now is hopefully cleaner.
>
> However, if there are reasons to keep some of the parsing more lenient
> here I'm happy to hear and find the best solution for the web platform.
>
>
>
> --
> 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/CAJn%3DMYbLLqWEjSNYnt6Pw%2BcV75%3DryQ%3DbsDM%3DAXtktKW6C__kkQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbLLqWEjSNYnt6Pw%2BcV75%3DryQ%3DbsDM%3DAXtktKW6C__kkQ%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/CAM0wra_Q9TN8H2OwyJazYmyUk0SF2c4dVacHW0_hEEnEW7eOZA%40mail.gmail.com.

Reply via email to