On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee <[email protected]> wrote:
> Hello Yoav and Mike, > > Thanks for the feedback! I replied inline. > On 9/23/22 22:18, Yoav Weiss wrote: > > > > On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor <[email protected]> > wrote: > >> Hi Byungwoo, >> >> On 9/23/22 4:34 AM, Byungwoo Lee wrote: >> >> Contact emails [email protected] >> >> Specification >> https://drafts.csswg.org/css-conditional-4/#support-definition-ext >> >> Summary >> >> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) If >> an argument of the functional selectors is unknown or invalid, the argument >> is dropped but the selector itself is not invalidated. To provide a way of >> detecting the unknown or invalid arguments in those functional selectors, >> this feature applies the CSS Working Group issue resolution: - @supports >> uses non-forgiving parsing for all selectors ( >> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187) >> >> Am I understanding correctly that content that now uses a functional > selector argument that's invalid may break as a result of this? > If so, do we have usecounters to that effect? > > Yes it can change the previous behavior. > > This changes the selector parsing behavior only for the selectors inside > @supports selector(). > > So if authors expected true for '@supports > selector(:is(:some-invalid-selector))', this feature will break it because > the return value will be changed to false after this feature is enabled. > > I'm not sure that we have the usecounters of the case: counting drop of > invalid selector inside @supports selector. > > If it doesn't exists but it is needed, I think we can add it. Will it be > better to add it to get use counters before ship it? > Yeah, knowing the order of magnitude of potential breakage would be good. > >> >> Blink component Blink >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >> >> TAG review >> >> TAG review status Not applicable >> >> Can you expand on why you think a TAG review is not needed here? >> > I thought that we don't need TAG review and the reason was > > - This is already specified in the spec: > https://drafts.csswg.org/css-conditional-4/#support-definition-ext > <https://drafts.csswg.org/css-conditional-4/#support-definition-ext> > > - Firefox already landed it: > https://bugzilla.mozilla.org/show_bug.cgi?id=1789248 > > Will it be better to change the TAG review status to 'Pending'? > > >> Risks >> >> >> Interoperability and Compatibility >> >> *Gecko*: Shipped/Shipping >> https://bugzilla.mozilla.org/show_bug.cgi?id=1789248 >> >> *WebKit*: Positive >> >> *Web developers*: Positive >> >> Can you please link to these signals? >> > > WebKit: > > - Explained about this in a blog post: > https://webkit.org/blog/13096/css-has-pseudo-class/ > > Web developers: > > - Thumbs ups in the CSSWG issue: > https://github.com/w3c/csswg-drafts/issues/7280 > > - jQuery applied the spec: > https://github.com/jquery/jquery/pull/5107 > > > thanks, >> Mike >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%40chromium.org?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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXTLU_5ii0mkYJ1wP08tajuB6tYFDjv-OfTKUUHwcnrpQ%40mail.gmail.com.
