On 9/24/22 00:40, Yoav Weiss wrote:


On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee <b...@igalia.com> 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
    <miketa...@chromium.org> wrote:

        Hi Byungwoo,

        On 9/23/22 4:34 AM, Byungwoo Lee wrote:


                Contact emails

        b...@igalia.com


                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.
I landed a CL to add the use counter:
https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216

It counts the drop of invalid selector while forgiving selector parsing inside @supports selector(). We can see the stats with CSSAtSupportsDropInvalidWhileForgivingParsing(4361):
https://chromestatus.com/metrics/feature/timeline/popularity/4361

This will be in 108 version so hopefully we can get the use counter after the version is released.

 * beta (Oct 27)
 * stable (Nov 29)

I'll share the stats when it released.

Thanks!



                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/Shippinghttps://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 blink-dev+unsubscr...@chromium.org.
        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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6742d462-388f-8bda-8063-314203d4a143%40igalia.com.

Reply via email to