On Mon, Mar 11, 2024 at 5:57 AM Domenic Denicola <dome...@chromium.org> wrote:
> Thanks Dan for raising the compat concerns here. It seems like a mistake > that the original Intent says "None" for that, > Good point, I updated it. > 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? > > Will do both and come back with results. > > 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/CAJn%3DMYaC%3DJfBCg-2j_aqJg8FDULOJcG3uPA50PEXtiAnRrpnmw%40mail.gmail.com.
