With dual LGTM1 from Chris and Yoav, I'll jump directly to...

LGTM3

/Daniel

On 2022-06-22 17:58, Yoav Weiss wrote:
LGTM1

On Wednesday, June 15, 2022 at 11:54:30 PM UTC+2 Daniel Clark wrote:

    /> What's the feature detection/activation story here? Can
    developers use the feature while it's partially supported? What
    would be the implications of that?/

    Feature detection can be done by checking for the presence of
    CSS.highlights:

    function supportsHighlightAPI() {

    return !!CSS.highlights;

    }

    For use cases where the highlights are key to the user experience
    (e.g. when used for an app’s custom find-on-page implementation),
    developers should fall back to a polyfill for unsupported
    browsers. For use cases where highlights are only added for
    stylistic purposes, they could be omitted altogether when there
    isn’t support.

    A polyfill could be built for the feature that works by wrapping
    “highlighted” content in styled spans. This could get tricky to
    implement for cases involving many nested highlights (which is one
    thing that the API makes much easier), but it would work fine for
    most scenarios.

    /> We could send a ping notifying that Chromium is planning to ship./

    I pinged the mozilla/standards-positions thread about this last
    week, still waiting to hear back
    
https://github.com/mozilla/standards-positions/issues/482#issuecomment-1152601522
    
<https://github.com/mozilla/standards-positions/issues/482#issuecomment-1152601522>.
    @Emilio <mailto:emi...@mozilla.com>, is there anything you’d be
    able to share about this?

    /> Can you ask for an explicit signal to see what their plans are
    on that front? Is there an interop risk from their incomplete
    implementation?/

    I sent a mail
    <https://lists.webkit.org/pipermail/webkit-dev/2022-June/032303.html>
    to webkit-dev, awaiting response. I just took another look at
    their implementation, and they’ve done some work to bring it
    closer to the current state of the spec since last I checked. The
    remaining major difference I see is just the lack of support for
    live Ranges. I expect that they will close this gap prior to
    shipping the feature. If they don’t then the difference could also
    be feature-detected by polyfills:

    function supportsLiveRangeHighlights() {

    try {

    new Highlight(new Range());

    return true;

    } catch(ex) {

    return false;

    };

    }

    -- Dan

    *From:* Yoav Weiss <yoavwe...@chromium.org>
    *Sent:* Wednesday, June 15, 2022 1:32 AM
    *To:* blink-dev <blink-dev@chromium.org>
    *Cc:* Manuel Rego <r...@igalia.com>; Sanket Joshi (EDGE)
    <sa...@microsoft.com>; Fernando Fiori <ffi...@microsoft.com>; Bo
    Cupp <pc...@microsoft.com>; Luis Juan Sanchez Padilla
    <luis.snc...@microsoft.com>; Delan Azabani <dazab...@igalia.com>;
    Emilio Cobos Alvarez <emi...@mozilla.com>; Rick Byers
    <rby...@chromium.org>; flo...@rivoal.net <flor...@rivoal.net>;
    Daniel Clark <dan...@microsoft.com>
    *Subject:* Re: [blink-dev] Intent to Ship: Custom Highlight API

    On Thursday, June 9, 2022 at 6:55:06 AM UTC+2 Manuel Rego wrote:

        I'm biased here as I've been working on this feature myself,
        so I cannot
        give an official LGTM.

        Thanks for all the work since the previous intent thread, I
        believe this
        is now in a way better status to ship.

        I'd be fine giving a LGTM with the following caveats:
        * As mentioned at the end of the email,
        HighlightOverlayPainting flag
        gets enabled before shipping this (that flag fixes lots of bugs
        regarding paining of CSS highlight pseudos).
        * The following CSSWG issue gets resolved:
        https://github.com/w3c/csswg-drafts/issues/6774
        
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6774&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=FVgZmds%2BpoWNSGjSR1DFoh3G1dwFwes5vZD65iEDdtA%3D&reserved=0>

        It looks like there's an agreement already but it'd be nice to
        confirm
        it, as this might change behavior if a different decision is
        made.

        Other than that I've just some minor comments inline.

        On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
        > Risks
        >
        >
        > Interoperability and Compatibility
        >
        > Low risk: This feature received positive support from Safari
        and Firefox
        > at TPAC 2019. Safari is implementing it, Firefox has not yet
        made any
        > clear indication on implementation.

    What's the feature detection/activation story here? Can developers
    use the feature while it's partially supported? What would be the
    implications of that?


        >
        >
        >
        > /Gecko/: No clear signal
        > (https://github.com/mozilla/standards-positions/issues/482
        
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zEMcL5OP4APO1YKe2SGFBKlASHSGQOy1bi%2FreiGIBY4%3D&reserved=0>

        > <https://github.com/mozilla/standards-positions/issues/482
        
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zEMcL5OP4APO1YKe2SGFBKlASHSGQOy1bi%2FreiGIBY4%3D&reserved=0>>)


        We could send a ping notifying that Chromium is planning to ship.

        > /WebKit/: Positive. WebKit implemented the feature behind an
        > experimental flag in 99:
        >
        
https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API
        
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fsafari%2Ftechnology-preview%2Frelease-notes%2F%23%3A~%3Atext%3DAdded%2520support%2520for%2520rendering%2520highlights%2520specified%2520in%2520CSS%2520Highlight%2520API&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Afgj4HPaUxUdpB1KhwgAh4uq1%2B%2F9l1Nj29kGDfxjIWs%3D&reserved=0>

        >
        
<https://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API
        
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fsafari%2Ftechnology-preview%2Frelease-notes%2F%23%3A~%3Atext%3DAdded%2520support%2520for%2520rendering%2520highlights%2520specified%2520in%2520CSS%2520Highlight%2520API&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Afgj4HPaUxUdpB1KhwgAh4uq1%2B%2F9l1Nj29kGDfxjIWs%3D&reserved=0>>.


        I agree that it's positive WebKit has a WIP implementation.
        But just to
        clarify the status Safari has an old version of this spec
        implemented,
        and the implementation is not complete and not up to date
        regarding the
        spec (e.g. https://bugs.webkit.org/show_bug.cgi?id=229797
        
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.webkit.org%2Fshow_bug.cgi%3Fid%3D229797&data=05%7C01%7Cdaniec%40microsoft.com%7C7feca281f397491f36cc08da4ea98e04%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637908787402809854%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xrJWnSsyiHCIaUe193YhCB%2BbzwShWhZgjIYBE2kMfBY%3D&reserved=0>).

    Can you ask for an explicit signal to see what their plans are on
    that front? Is there an interop risk from their incomplete
    implementation?



        Cheers,
        Rego

--
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/5947b08e-67d2-45bf-a468-c78b619de02fn%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5947b08e-67d2-45bf-a468-c78b619de02fn%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/caf614ae-f018-89d2-a28b-b02425d49927%40gmail.com.

Reply via email to