subject:"Re\: \[blink\-dev\] Intent to Ship\: Custom Highlight API"

RE: [blink-dev] Intent to Ship: Custom Highlight API

2022-07-15 Thread 'Fernando Fiori' via blink-dev

This is awesome! Thank you and congrats to everyone who has been working on it 
to make it happen 😊

From: Daniel Clark 
Sent: Friday, July 15, 2022 2:07 PM
To: Delan Azabani ; blink-dev 
Cc: Delan Azabani ; jme...@google.com 
; Daniel Bratell ; 
yoav...@chromium.org ; blink-dev 
; Manuel Rego ; Sanket Joshi (EDGE) 
; Fernando Fiori ; Bo Cupp 
; Luis Juan Sanchez Padilla ; 
rby...@chromium.org ; flo...@rivoal.net 

Subject: RE: [blink-dev] Intent to Ship: Custom Highlight API

Thanks for following through with that fix and reland! Highlight API has 
shipped: 
https://chromium-review.googlesource.com/c/chromium/src/+/3718885<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromium%2Fsrc%2F%2B%2F3718885&data=05%7C01%7Cffiori%40microsoft.com%7C69a7ef1f069c4befa24308da66a5f2dc%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637935160213585018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JjcGYrHxPO62GyTPgAgaOJq9CGXP0WQOFKjkeajTeAE%3D&reserved=0>

From: Delan Azabani mailto:de...@azabani.com>>
Sent: Friday, July 15, 2022 1:16 AM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Delan Azabani mailto:dazab...@igalia.com>>; 
jme...@google.com<mailto:jme...@google.com> 
mailto:jmed...@google.com>>; Daniel Bratell 
mailto:bratel...@gmail.com>>; 
yoav...@chromium.org<mailto:yoav...@chromium.org> 
mailto:yoavwe...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Manuel Rego 
mailto:r...@igalia.com>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>; Fernando Fiori 
mailto:ffi...@microsoft.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; Luis Juan Sanchez Padilla 
mailto:luis.snc...@microsoft.com>>; 
rby...@chromium.org<mailto:rby...@chromium.org> 
mailto:rby...@chromium.org>>; 
flo...@rivoal.net<mailto:flo...@rivoal.net> 
mailto:flor...@rivoal.net>>; Daniel Clark 
mailto:dan...@microsoft.com>>
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

You don't often get email from de...@azabani.com<mailto:de...@azabani.com>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
On Friday, 24 June 2022 at 3:42:07 pm UTC+8 Delan Azabani wrote:
I think all of the blocking spec issues are now resolved or at consensus, so 
the only thing left is the Chromium OS performance regression in bug 
1335762<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrbug.com%2F1335762&data=05%7C01%7Cffiori%40microsoft.com%7C69a7ef1f069c4befa24308da66a5f2dc%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637935160213585018%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WSykmtfSCLxEzCsIXap7scc3e7T2WulEnaONqYOndWo%3D&reserved=0>.
 It’s hard to give a time estimate on that until we figure out the root cause 
though.

We’ve fixed the regression and rebumped HighlightOverlayPainting to stable, so 
we should be good to go!

-- 
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/DM6PR00MB06351A861DBD2A7298FA3436DC8B9%40DM6PR00MB0635.namprd00.prod.outlook.com.

RE: [blink-dev] Intent to Ship: Custom Highlight API

2022-07-15 Thread 'Daniel Clark' via blink-dev

Thanks for following through with that fix and reland! Highlight API has 
shipped: https://chromium-review.googlesource.com/c/chromium/src/+/3718885

From: Delan Azabani 
Sent: Friday, July 15, 2022 1:16 AM
To: blink-dev 
Cc: Delan Azabani ; jme...@google.com 
; Daniel Bratell ; 
yoav...@chromium.org ; blink-dev 
; Manuel Rego ; Sanket Joshi (EDGE) 
; Fernando Fiori ; Bo Cupp 
; Luis Juan Sanchez Padilla ; 
rby...@chromium.org ; flo...@rivoal.net 
; Daniel Clark 
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

You don't often get email from de...@azabani.com<mailto:de...@azabani.com>. 
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
On Friday, 24 June 2022 at 3:42:07 pm UTC+8 Delan Azabani wrote:
I think all of the blocking spec issues are now resolved or at consensus, so 
the only thing left is the Chromium OS performance regression in bug 
1335762<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrbug.com%2F1335762&data=05%7C01%7Cdaniec%40microsoft.com%7C0cb3aed559eb4b47684808da663a35d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637934698062933175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=DMiXt%2FWBzhmjwHoe6mzfwEc59grcDYNzzIO03jE7wZs%3D&reserved=0>.
 It's hard to give a time estimate on that until we figure out the root cause 
though.

We've fixed the regression and rebumped HighlightOverlayPainting to stable, so 
we should be good to go!

-- 
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/MW2PR00MB0441ECC40E388EE533E923F8C58B9%40MW2PR00MB0441.namprd00.prod.outlook.com.

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-07-15 Thread Delan Azabani

On Friday, 24 June 2022 at 3:42:07 pm UTC+8 Delan Azabani wrote:

> I think all of the blocking spec issues are now resolved or at consensus, 
> so the only thing left is the Chromium OS performance regression in bug 
> 1335762 . It’s hard to give a time estimate on 
> that until we figure out the root cause though.


We’ve fixed the regression and rebumped HighlightOverlayPainting to stable, 
so we should be good to go!

-- 
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/4459bbf3-0bb8-4368-b7f6-bfb71c7f3008n%40chromium.org.

RE: [blink-dev] Intent to Ship: Custom Highlight API

2022-07-14 Thread 'Daniel Clark' via blink-dev

These are both good points, thanks for bringing them up. I won't plan to block 
shipping for these but I'll follow up for both.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1344685 to track 
the addition of the console warning.
I filed https://github.com/w3c/csswg-drafts/issues/7499 to track clarification 
of the printing behavior.

Thanks,
Dan

-Original Message-
From: Manuel Rego Casasnovas  
Sent: Thursday, July 14, 2022 4:31 AM
To: Daniel Clark ; blink-dev 
Cc: Sanket Joshi (EDGE) ; Fernando Fiori 
; Bo Cupp ; Luis Juan Sanchez 
Padilla ; Delan Azabani ; 
Emilio Cobos Álvarez ; Rick Byers ; 
Florian Rivoal 
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

One comment about this feature and legacy layout.

It seems ::highlight customization is only supported in LayoutNG for most 
properties (only background-color works in legacy).

I'm wondering if we should add some kind of console warning message, like for 
Container Queries [*], so if people see some differences in some cases they can 
know the reason why.


Another thing that I noticed is that highlight pseudos are not being printed, I 
guess that was on purpose for things like ::selection or ::target-text, but 
should we allow printing ::highlight? Should we open a spec issue about that so 
it's properly defined (I didn't find anything on the specs regarding printing)?

I don't mean this is a blocker for shipping, but if this is not properly 
defined, maybe it's time to clarify things regarding printing.

Cheers,
  Rego

[*] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium-review.googlesource.com%2Fc%2Fchromium%2Fsrc%2F%2B%2F3706582&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b984e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637933950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jQM8QtQRPqgZls%2F9HsfJrCfZgyS27G6dNHZeFIDr2sc%3D&reserved=0

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> 
> Contact emails
> 
> dan...@microsoft.com <mailto:dan...@microsoft.com>, 
> sa...@microsoft.com <mailto:sa...@microsoft.com>, ffi...@microsoft.com 
> <mailto:ffi...@microsoft.com>, lusan...@microsoft.com 
> <mailto:lusan...@microsoft.com>, pc...@microsoft.com 
> <mailto:pc...@microsoft.com>,
> 
> 
> Explainer
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2F
> explainer.md&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b984
> e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63793
> 3950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gltxN5Ppd
> jpK2hmy9YOvzmv4JCoBz5fEy6VKu8r5wvI%3D&reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2
> Fexplainer.md&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b98
> 4e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379
> 33950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=gltxN5Pp
> djpK2hmy9YOvzmv4JCoBz5fEy6VKu8r5wvI%3D&reserved=0>
> 
> 
> Specification
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdraf
> ts.csswg.org%2Fcss-highlight-api-1%2F&data=05%7C01%7Cdaniec%40micr
> osoft.com%7Ce900e8a35b984e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d7
> cd011db47%7C1%7C0%7C637933950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7C&sdata=cx9ESC489CebPDKkllktvpHmsUei2QQBKAwG3m16%2Fw4%3D&r
> eserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdra
> fts.csswg.org%2Fcss-highlight-api-1%2F&data=05%7C01%7Cdaniec%40mic
> rosoft.com%7Ce900e8a35b984e0378ea08da658c4bd3%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637933950515742925%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> %7C%7C&sdata=cx9ESC489CebPDKkllktvpHmsUei2QQBKAwG3m16%2Fw4%3D&
> reserved=0>
> 
> 
> Design docs
> 
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> .google.com%2Fdocument%2Fd%2F1vaWiPLA9opz0AObbObuRj3P5zqzoM2ldy0pHkZkJ
> yxo&data=05%7C01%7Cdaniec%40microsoft.com%7Ce900e8a35b984e0378ea08
> da658c4bd3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63793395051574
> 2925%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLC

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-07-14 Thread Manuel Rego Casasnovas

One comment about this feature and legacy layout.

It seems ::highlight customization is only supported in LayoutNG for
most properties (only background-color works in legacy).

I'm wondering if we should add some kind of console warning message,
like for Container Queries [*], so if people see some differences in
some cases they can know the reason why.


Another thing that I noticed is that highlight pseudos are not being
printed, I guess that was on purpose for things like ::selection or
::target-text, but should we allow printing ::highlight? Should we open
a spec issue about that so it's properly defined (I didn't find anything
on the specs regarding printing)?

I don't mean this is a blocker for shipping, but if this is not properly
defined, maybe it's time to clarify things regarding printing.

Cheers,
  Rego

[*] https://chromium-review.googlesource.com/c/chromium/src/+/3706582

On 08/06/2022 19:42, 'Daniel Clark' via blink-dev wrote:
> 
> Contact emails
> 
> dan...@microsoft.com , sa...@microsoft.com
> , ffi...@microsoft.com
> , lusan...@microsoft.com
> , pc...@microsoft.com
> ,
> 
> 
> Explainer
> 
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/explainer.md
> 
> 
> 
> Specification
> 
> https://drafts.csswg.org/css-highlight-api-1/
> 
> 
> 
> Design docs
> 
> 
> https://docs.google.com/document/d/1vaWiPLA9opz0AObbObuRj3P5zqzoM2ldy0pHkZkJyxo
> 
> 
> 
> Summary
> 
> The custom highlight API provides a way for web developers to style the
> text of arbitrary ranges. This is useful in a variety of scenarios,
> including editing frameworks that wish to implement their own selection,
> find-on-page over virtualized documents, multiple selections to
> represent online collaboration, or spellchecking frameworks.
> 
> 
> Blink component
> 
> Blink>Editing
> 
> 
> 
> Search tags
> 
> Custom Highlight API
> , Highlight
> API 
> 
> 
> TAG review
> 
> https://github.com/w3ctag/design-reviews/issues/584
> 
> 
> 
> TAG review status
> 
> Issues addressed
> 
> 
> 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.
> 
> 
> 
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482
> )
> 
> /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
> .
> 
> /Web developers/: Strongly positive
> (https://github.com/w3c/csswg-drafts/issues/4307
> ). Multiple use cases
> have been pointed out in this issue. CKEditor has also shown support
> from the first highlight API explainer.
> 
> /Other signals/:
> 
> 
> Ergonomics
> 
> Highlight API will be the first use case for constructible StaticRanges,
> which the API permits as an alternative to Iive Ranges because they do
> not incur cost during DOM mutations.
> 
> 
> 
> 
> Activation
> 
> No. Web developers should be able to use the feature as-is. It is also
> easy to feature detect (checking for the existence of CSS.highlights).
> 
> 
> 
> 
> WebView application risks
> 
> None.
> 
> 
> Debuggability
> 
> DevTools shows ::highlight pseudo elements in the style pane. This
> includes inherited pseudos per the highlight inheritance model
>  used by
> custom highlights.
> 
> 
> 
> 
> Will this feature be supported on all six Blink platforms
> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
> 
> Yes
> 
> 
> Is this feature fully tested by web-platform-tests
> 
> ?
> 
> Yes
> https://github.com/web-platform-tests/wpt/tree/master/css/css-highlight-api
>

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-24 Thread Delan Azabani

On 2022-06-22 19:36, Daniel Clark wrote:

> Shipping in 105 seems like a good target (branch date Thu, Jul 21, 2022). We 
> still need HighlightOverlayPainting 
> (https://chromium-review.googlesource.com/c/chromium/src/+/3640642) to reland 
> first. I believe @Delan Azabani/@Manuel Rego Casasnovas are driving that 
> change and may have a better idea of the timeline. I'll follow up with the CL 
> to enable Highlight API as soon as that lands.

I think all of the blocking spec issues are now resolved or at
consensus, so the only thing left is the Chromium OS performance
regression in bug 1335762 [1]. It's hard to give a time estimate on that
until we figure out the root cause though. 

Cheers,
Delan Azabani
Igalia // web platform 

Links:
--
[1] https://crbug.com/1335762

-- 
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/eb6ea2255b5333625c657936eccdaf31%40igalia.com.

RE: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-22 Thread 'Daniel Clark' via blink-dev

Thanks all!

Shipping in 105 seems like a good target (branch date Thu, Jul 21, 2022). We 
still need HighlightOverlayPainting 
(https://chromium-review.googlesource.com/c/chromium/src/+/3640642) to reland 
first. I believe @Delan Azabani<mailto:dazab...@igalia.com>/@Manuel Rego 
Casasnovas<mailto:r...@igalia.com> are driving that change and may have a 
better idea of the timeline. I'll follow up with the CL to enable Highlight API 
as soon as that lands.

-- Dan

From: Joe Medley 
Sent: Wednesday, June 22, 2022 10:18 AM
To: Daniel Bratell 
Cc: Yoav Weiss ; blink-dev ; 
Daniel Clark ; Manuel Rego ; Sanket 
Joshi (EDGE) ; Fernando Fiori ; Bo 
Cupp ; Luis Juan Sanchez Padilla 
; Delan Azabani ; Rick Byers 
; flo...@rivoal.net 
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | 
jmed...@google.com<mailto:jmed...@google.com> | 816-678-7195
If an API's not documented it doesn't exist.

On Wed, Jun 22, 2022 at 9:26 AM Daniel Bratell 
mailto:bratel...@gmail.com>> wrote:

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmozilla%2Fstandards-positions%2Fissues%2F482%23issuecomment-1152601522&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=glPRb8BtUD524TxbWkwV8PzP3ezVSpXEifMfgz5CWwE%3D&reserved=0>.
 @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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.webkit.org%2Fpipermail%2Fwebkit-dev%2F2022-June%2F032303.html&data=05%7C01%7Cdaniec%40microsoft.com%7C3ab8d4cef9a44046d14808da547349d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637915151411080842%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g68jJFyer6AjIVgtvzsUQeszBscscIldSZupfTrO2Mk%3D&reserved=0>
 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 mailto:yoavwe...@chromium.org>>
Sent: Wednesday, June 15, 2022 1:32 AM
To: blink-dev mailto:blink-dev@chromium.org>>
Cc: Manuel Rego mailto:r...@igalia.com>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>; Fernando Fiori 
mailto:ffi...@microsoft.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; Luis Juan Sanchez Padilla 
mailto:luis.snc...@microsoft.com>>; Delan Azabani 
mailto:dazab...@igalia.com>>; Emilio Cobos Alvarez 
mailto:emi...@mozilla.com>>; Rick Byers 
mailto:rby...@chromium.org>>; 
flo...@rivoal.net<mailto:flo...@rivoal.net> 
mailto:flor...@rivoal.net>>; Daniel Clark 
mailto:dan...@microsoft.com>>
Subject:

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-22 Thread 'Joe Medley' via blink-dev

When do you hope to ship?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Wed, Jun 22, 2022 at 9:26 AM Daniel Bratell  wrote:

> 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.
>> @Emilio , 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 
>> *Sent:* Wednesday, June 15, 2022 1:32 AM
>> *To:* blink-dev 
>> *Cc:* Manuel Rego ; Sanket Joshi (EDGE) <
>> sa...@microsoft.com>; Fernando Fiori ; Bo Cupp <
>> pc...@microsoft.com>; Luis Juan Sanchez Padilla <
>> luis.snc...@microsoft.com>; Delan Azabani ; Emilio
>> Cobos Alvarez ; Rick Byers ;
>> flo...@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%2BpoWNSGjSR

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-22 Thread Daniel Bratell

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 
*Sent:* Wednesday, June 15, 2022 1:32 AM
*To:* blink-dev 
*Cc:* Manuel Rego ; Sanket Joshi (EDGE)
; Fernando Fiori ; Bo
Cupp ; Luis Juan Sanchez Padilla
; Delan Azabani ;
Emilio Cobos Alvarez ; Rick Byers
; flo...@rivoal.net ;
    Daniel Clark 
    *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?

>
>
>
> /Gec

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-22 Thread 'Chris Harrelson' via blink-dev

LGTM2 then. :(

On Wed, Jun 22, 2022 at 8:58 AM 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.
>> @Emilio , 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 
>> *Sent:* Wednesday, June 15, 2022 1:32 AM
>> *To:* blink-dev 
>> *Cc:* Manuel Rego ; Sanket Joshi (EDGE) <
>> sa...@microsoft.com>; Fernando Fiori ; Bo Cupp <
>> pc...@microsoft.com>; Luis Juan Sanchez Padilla <
>> luis.snc...@microsoft.com>; Delan Azabani ; Emilio
>> Cobos Alvarez ; Rick Byers ;
>> flo...@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 inlin

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-22 Thread Chris Harrelson

LGTM1

On Wed, Jun 15, 2022 at 2:54 PM 'Daniel Clark' via blink-dev <
blink-dev@chromium.org> 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.
> @Emilio , 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 
> *Sent:* Wednesday, June 15, 2022 1:32 AM
> *To:* blink-dev 
> *Cc:* Manuel Rego ; Sanket Joshi (EDGE) <
> sa...@microsoft.com>; Fernando Fiori ; Bo Cupp <
> pc...@microsoft.com>; Luis Juan Sanchez Padilla ;
> Delan Azabani ; Emilio Cobos Alvarez <
> emi...@mozilla.com>; Rick Byers ; flo...@rivoal.net <
> flor...@rivoal.net>; Daniel Clark 
> *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 impli

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-22 Thread Yoav Weiss

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.
>  
> @Emilio , 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  
> *Sent:* Wednesday, June 15, 2022 1:32 AM
> *To:* blink-dev 
> *Cc:* Manuel Rego ; Sanket Joshi (EDGE) <
> sa...@microsoft.com>; Fernando Fiori ; Bo Cupp <
> pc...@microsoft.com>; Luis Juan Sanchez Padilla ; 
> Delan Azabani ; Emilio Cobos Alvarez <
> emi...@mozilla.com>; Rick Byers ; flo...@rivoal.net <
> flor...@rivoal.net>; Daniel Clark 
> *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 pa

RE: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-15 Thread 'Daniel Clark' via blink-dev

> 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.
 @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 
Sent: Wednesday, June 15, 2022 1:32 AM
To: blink-dev 
Cc: Manuel Rego ; Sanket Joshi (EDGE) ; 
Fernando Fiori ; Bo Cupp ; Luis Juan 
Sanchez Padilla ; Delan Azabani 
; Emilio Cobos Alvarez ; Rick Byers 
; flo...@rivoal.net ; Daniel Clark 

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%7C0

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-15 Thread Yoav Weiss



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 
> 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 
> > ) 
>
> 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://developer.apple.com/safari/technology-preview/release-notes/#:~:text=Added%20support%20for%20rendering%20highlights%20specified%20in%20CSS%20Highlight%20API>.
>  
>
>
> 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).


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/47e226a2-d00a-42fd-a846-6f506969228an%40chromium.org.

Re: [blink-dev] Intent to Ship: Custom Highlight API

2022-06-08 Thread Manuel Rego Casasnovas

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
  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.
> 
> 
> 
> /Gecko/: No clear signal
> (https://github.com/mozilla/standards-positions/issues/482
> )

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
> .

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).

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/46053910-a5af-bd87-60f9-f9ef21934fb7%40igalia.com.

Re: [blink-dev] Intent to Ship: Custom Highlight API

2021-09-07 Thread Rick Byers

Thanks for all the additional discussion and context. I wasn't aware
of what a shaky ground we were on here today. I agree with the conclusion
that we should firm it up somewhat before shipping this new API. So
consider my LGTM rescinded for now. But please come back once you feel the
highlighting foundation is solid enough to be safe to build upon.

On Thu, Sep 2, 2021 at 7:09 AM Manuel Rego Casasnovas 
wrote:

>
>
> On 18/08/2021 18:15, Delan Azabani wrote:
> > I think it was a mistake for Blink to ship ::target-text in this kind of
> > state, and given the wider range of use cases that ::highlight aims to
> > solve, I think it would be at least as much of a mistake here.
>
> I agree with this.
>
> ::target-text has a bunch of known issues, but sadly it's already shipped.
>
> But this is a way bigger API, that will allow web authors to add
> highlights all over the page. It's a really nice one, but even limiting
> it to color and background-color properties, there are a bunch of issues
> that we should solve before shipping. Otherwise people could start to
> depend on behaviors that are going to change (like inheritance), or find
> that the API is not useful for some simple cases and discard it, or
> whatever.
>
> We've collected examples that have issues in the current highlight
> implementation: 
>
> Delan has been working on adding support for ::spelling|grammar-error.
> These pseudos have many of the same issues, as they use DocumentMarkers
> like custom highlights. She has been fixing some of them, but the work
> is still ongoing. Anyway probably not all the issues need to be fixed
> before shipping.
>
> If you're interested, we've started writing a design doc that explores
> the topic in more detail:
> <
> https://docs.google.com/document/d/1Rfelx4qv-RhQYHUJ74QBU5MjEbmb9Wol9gvyjkywqgE
> >
>
> 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/ed2ddcce-228e-94a4-7a6b-2ed3e1c52fed%40igalia.com
> .
>

-- 
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/CAFUtAY_0D1%3Dz-H%2B9fWST1J4_X80RVQseh_8axB0qEwZ%3DiGkkjw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Custom Highlight API

2021-09-02 Thread Manuel Rego Casasnovas

On 18/08/2021 18:15, Delan Azabani wrote:
> I think it was a mistake for Blink to ship ::target-text in this kind of
> state, and given the wider range of use cases that ::highlight aims to
> solve, I think it would be at least as much of a mistake here.

I agree with this.

::target-text has a bunch of known issues, but sadly it's already shipped.

But this is a way bigger API, that will allow web authors to add
highlights all over the page. It's a really nice one, but even limiting
it to color and background-color properties, there are a bunch of issues
that we should solve before shipping. Otherwise people could start to
depend on behaviors that are going to change (like inheritance), or find
that the API is not useful for some simple cases and discard it, or
whatever.

We've collected examples that have issues in the current highlight
implementation:

Delan has been working on adding support for ::spelling|grammar-error.
These pseudos have many of the same issues, as they use DocumentMarkers
like custom highlights. She has been fixing some of them, but the work
is still ongoing. Anyway probably not all the issues need to be fixed
before shipping.

If you're interested, we've started writing a design doc that explores
the topic in more detail:

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/ed2ddcce-228e-94a4-7a6b-2ed3e1c52fed%40igalia.com.

Re: [blink-dev] Intent to Ship: Custom Highlight API

2021-08-18 Thread Florian Rivoal



> On Aug 19, 2021, at 1:15, Delan Azabani  wrote:
> 
> I’m also excited to see this feature ship, as it’s pretty relevant to our 
> work at Igalia, but I feel I must share and expand on Florian’s concerns 
> about our current behaviour.
> 
> On Wednesday, August 18, 2021 at 12:27:04 AM UTC+8 Daniel Clark wrote:
> Our thinking on this is that this first version of the Highlight API is 
> mainly useful for scenarios like custom find-on-page where highlights use 
> simple formatting (like background-color and color), and overlapping 
> highlight ranges are not common. So, we don’t expect the discrepancies 
> between the Chromium implementation and the highlight pseudos specs to be a 
> big issue. For example, many of these longstanding highlight painting issues 
> exist with the browser’s current find-on-page implementation, but in practice 
> they are minimally disruptive. […] Thus I’m hesitant to conclude that this 
> reworking of the highlight painting code should be a blocker for shipping the 
> API.
> 
> Note that it’s not just paint that’s broken, but style too, primarily because 
> we don’t yet impl highlight inheritance. Also, surely even the proposed 
> subset of background-color and color would have uses beyond find-on-page, 
> like multiple selections for online collaboration?
> 
> It’s one thing to ship with missing features that we can easily add later 
> (such as text-decoration support, more or less), or with bugs of minor 
> consequence (such as  >). But do we really want to be the first engine 
> to ship this feature, with an impl that’s broken under the spec’s very first 
> example [0][1], color on ligature-heavy scripts (despite working in 
> ::selection) [2], and even ancient features like ::first-letter [3]?
> 
> Each of these bugs, if shipped and fixed later, has some impact — however 
> small — on things like compat, author confidence, and even tutorial content. 
> For example, strictly speaking, impl’ing highlight inheritance will break 
> what [4] has to say about text-shadow. Fixing them after the fact in 
> ::selection (currently a separate impl) has proven painful, because chipping 
> away at a big problem over multiple patches has caused regressions [5].

I suspect that shipping with some amount of paint bugs is probably tolerable 
(although I would prefer if we could deal with the worst offenders), but that 
we really ought to block on fixing the style part. Otherwise, the API is pretty 
much unusable as soon as you want to start writing styles that apply to less 
than the whole page (or if you manage to work around the limitations, you'll 
end up with content that breaks once we fix the implementation).


> I think it was a mistake for Blink to ship ::target-text in this kind of 
> state, and given the wider range of use cases that ::highlight aims to solve, 
> I think it would be at least as much of a mistake here.
> 
> [0] https://drafts.csswg.org/css-highlight-api-1/#intro-ex 
> 
> [1] https://bucket.daz.cat/work/igalia/1/1.html 
> 
> [2] https://bucket.daz.cat/work/igalia/1/2.html 
> 
> [3] https://bucket.daz.cat/work/igalia/1/3.html 
> 
> [4] https://css-tricks.com/almanac/selectors/s/selection/ 
> 
> [5] https://crrev.com/c/2925295 
> 
> Cheers,
> Delan Azabani
> Igalia // 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/9420eb48-1c02-4c47-af02-bf932be55c05n%40chromium.org
>  
> .

-- 
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/45DF60C5-3AEA-41C4-9580-26CF95771367%40rivoal.net.

Re: [blink-dev] Intent to Ship: Custom Highlight API

2021-08-18 Thread Delan Azabani

I’m also excited to see this feature ship, as it’s pretty relevant to our 
work at Igalia, but I feel I must share and expand on Florian’s concerns 
about our current behaviour.

On Wednesday, August 18, 2021 at 12:27:04 AM UTC+8 Daniel Clark wrote:

> Our thinking on this is that this first version of the Highlight API is 
> mainly useful for scenarios like custom find-on-page where highlights use 
> simple formatting (like background-color and color), and overlapping 
> highlight ranges are not common. So, we don’t expect the discrepancies 
> between the Chromium implementation and the highlight pseudos specs to be a 
> big issue. For example, many of these longstanding highlight painting 
> issues exist with the browser’s current find-on-page implementation, but in 
> practice they are minimally disruptive. […] Thus I’m hesitant to conclude 
> that this reworking of the highlight painting code should be a blocker for 
> shipping the API.

Note that it’s not just paint that’s broken, but style too, primarily 
because we don’t yet impl highlight inheritance. Also, surely even the 
proposed subset of background-color and color would have uses beyond 
find-on-page, like multiple selections for online collaboration?

It’s one thing to ship with missing features that we can easily add later 
(such as text-decoration support, more or less), or with bugs of minor 
consequence (such as ). But do we really want to 
be the first engine to ship this feature, with an impl that’s broken under 
the spec’s very first example [0][1], color on ligature-heavy scripts 
(despite working in ::selection) [2], and even ancient features like 
::first-letter [3]?

Each of these bugs, if shipped and fixed later, has some impact — however 
small — on things like compat, author confidence, and even tutorial 
content. For example, strictly speaking, impl’ing highlight inheritance 
will break what [4] has to say about text-shadow. Fixing them after the 
fact in ::selection (currently a separate impl) has proven painful, because 
chipping away at a big problem over multiple patches has caused regressions 
[5].

I think it was a mistake for Blink to ship ::target-text in this kind of 
state, and given the wider range of use cases that ::highlight aims to 
solve, I think it would be at least as much of a mistake here.

[0] https://drafts.csswg.org/css-highlight-api-1/#intro-ex
[1] https://bucket.daz.cat/work/igalia/1/1.html
[2] https://bucket.daz.cat/work/igalia/1/2.html
[3] https://bucket.daz.cat/work/igalia/1/3.html
[4] https://css-tricks.com/almanac/selectors/s/selection/
[5] https://crrev.com/c/2925295

Cheers,
Delan Azabani
Igalia // 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/9420eb48-1c02-4c47-af02-bf932be55c05n%40chromium.org.

RE: [blink-dev] Intent to Ship: Custom Highlight API

2021-08-17 Thread 'Daniel Clark' via blink-dev

Thanks Rick!

Yes, I definitely think that the browser's built-in find-on-page could be 
redefined using this. In Chromium at least they are already implemented using 
some of the same structures (DocumentMarker for keeping track of highlight 
positions). I think further down the line it could be worthwhile to look at 
fully transitioning things like find-on-page to Highlight API.

-- Dan

From: Rick Byers 
Sent: Friday, August 13, 2021 8:58 AM
To: Daniel Clark 
Cc: emi...@mozilla.com; blink-dev@chromium.org; Fernando Fiori 
; Bo Cupp ; Sanket Joshi (EDGE) 

Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

LGTM1 - looks great to me!

"Explaining" and exposing magic rendering properties of the platform like 
highlighting is super valuable, thank you! Out of curiosity, if this gets broad 
support do you think there's an opportunity to redefine things like 
find-in-page highlights to be built (conceptually if not physically) on top of 
this primitive?

Rick

On Thu, Aug 12, 2021 at 6:36 PM 'Daniel Clark' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Oh, you're right, I hadn't realized they still have it off by default.
So my mail should have said that WebKit has implemented it but not shipped it.

-Original Message-
From: Emilio Cobos Álvarez mailto:emi...@mozilla.com>>
Sent: Thursday, August 12, 2021 3:13 PM
To: Daniel Clark mailto:dan...@microsoft.com>>; 
blink-dev@chromium.org<mailto:blink-dev@chromium.org>
Cc: Fernando Fiori mailto:ffi...@microsoft.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; Sanket Joshi (EDGE) 
mailto:sa...@microsoft.com>>
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

Is Safari actually shipping it? What I see is that they implement it as a 
(default off) experimental feature, which I don't think qualifies as "shipping" 
by any means.

  -- Emilio

On 8/12/21 23:23, 'Daniel Clark' via blink-dev wrote:
>
> Contact emails
>
> sa...@microsoft.com<mailto:sa...@microsoft.com> 
> <mailto:sa...@microsoft.com<mailto:sa...@microsoft.com>>, 
> ffi...@microsoft.com<mailto:ffi...@microsoft.com>
> <mailto:ffi...@microsoft.com<mailto:ffi...@microsoft.com>>, 
> pc...@microsoft.com<mailto:pc...@microsoft.com>
> <mailto:pc...@microsoft.com<mailto:pc...@microsoft.com>>, 
> dan...@microsoft.com<mailto:dan...@microsoft.com>
> <mailto:dan...@microsoft.com<mailto:dan...@microsoft.com>>
>
>
> Explainer
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fub.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804496490%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GQj24GD%2BFjutpQYag0Q4S5%2B4ndi8dr%2BZD0p54tJW0aY%3D&reserved=0>%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2F
> explainer.md&data=04%7C01%7Cdaniec%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804506485%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=huqr%2FszxQBvjZssaIlgK7%2Bjaig%2BkqYhHdqVKnHqWnU4%3D&reserved=0>%7C18a8e4ed1ccc4
> 482d4dc08d95dde6345%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764
> 4032020524159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FZClTeCRozA8x8hx
> 1c0AodwctVLfVg5Fi7QhZz7RadI%3D&reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> hub.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhub.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804506485%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rcr%2FDBezOImPeo9xN7ZFWWcCiB3ghdJPAv7ULdEsUe0%3D&reserved=0>%2FMicrosoftEdge%2FMSEdgeExplainers%2Fblob%2Fmain%2Fhighlight%2
> Fexplainer.md&data=04%7C01%7Cdaniec%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Cdaniec%40microsoft.com%7Ca71f75ba2d2e48fc292f08d95e731cc4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644670804516478%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BpYfYENfdVVYqd4PbkkaxL63we5%2FxOIznBvm8XcysIs%3D&reserved=0>%7C18a8e4ed1ccc
> 4482d4dc08d95

RE: [blink-dev] Intent to Ship: Custom Highlight API

2021-08-17 Thread 'Daniel Clark' via blink-dev

Thanks Florian for your thoughts on this!

> We have a few open issues on the spec. 
> https://github.com/w3c/csswg-drafts/labels/css-highlight-api-1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Flabels%2Fcss-highlight-api-1&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086310969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kOB6Y3bLCEaYvmAwr%2BjZmgm9FeF%2ByR5uxTM2WSBcRWA%3D&reserved=0>

Makes sense, we'll work on driving down these issues in CSSWG before shipping, 
and we'll make sure that we have at least a clearer plan regarding 
accessibility for the API. I'll update this thread when more progress has been 
made here.

> The custom highlights defined by this API are highlights, as defined in 
> https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrafts.csswg.org%2Fcss-pseudo-4%2F%23highlight-pseudos&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086330959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BVOmsUayTL3qxgka8VSBDABT%2BmxAfv%2BUHpORvSCK5Kg%3D&reserved=0>,
>  and Chrome's current behavior is actually far from spec compliant here.

Our thinking on this is that this first version of the Highlight API is mainly 
useful for scenarios like custom find-on-page where highlights use simple 
formatting (like background-color and color), and overlapping highlight ranges 
are not common. So, we don't expect the discrepancies between the Chromium 
implementation and the highlight pseudos specs to be a big issue. For example, 
many of these longstanding highlight painting issues exist with the browser's 
current find-on-page implementation, but in practice they are minimally 
disruptive.

So our thinking is that fixing these highlight painting issues in the future 
would not cause significant breakage for sites built using the current 
capabilities of the API. Thus I'm hesitant to conclude that this reworking of 
the highlight painting code should be a blocker for shipping the API.

From: Florian Rivoal 
Sent: Friday, August 13, 2021 2:32 PM
To: Daniel Clark 
Cc: blink-dev@chromium.org; Fernando Fiori ; Bo Cupp 
; Sanket Joshi (EDGE) ; Delan Azabani 

Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API

Hi all!

Being one of the co-editors of this spec, I'm super happy about this getting 
traction... but I think shipping is a little bit premature:

* We have a few open issues on the spec. 
https://github.com/w3c/csswg-drafts/labels/css-highlight-api-1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Flabels%2Fcss-highlight-api-1&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086310969%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kOB6Y3bLCEaYvmAwr%2BjZmgm9FeF%2ByR5uxTM2WSBcRWA%3D&reserved=0>
 Most of them should be pretty easy, and I'm happy to prioritize them. It seems 
better to get the API / behavior to be stable and then ship rather than the 
other way around.

* One of the open issues is possibly not easy, but important: it has not yet 
been determined how this was supposed to work with screen-readers and other 
assistive technologies. I think this ought to be given serious thoughts, and 
probably should be solved before shipping 
https://github.com/w3c/csswg-drafts/issues/6498<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F6498&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086320974%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z66L%2B19E5Pyg9UZbTyKMAs9xSuoatkoBlVOZbECKxX4%3D&reserved=0>
 / 
https://github.com/w3c/csswg-drafts/issues/4601<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fcsswg-drafts%2Fissues%2F4601&data=04%7C01%7Cdaniec%40microsoft.com%7C6113ef857bf7463196a308d95ea1bf59%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637644871086330959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6hi9DlbJQ9IjrqE95nNcSYMLyiW%2B84jbIDNv8IKaBgI%3D&reserved=0>

* The custom highlights defined by this API are highlights, as defined in 
https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdrafts.csswg.org%

RE: [blink-dev] Intent to Ship: Custom Highlight API

RE: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

RE: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

RE: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

RE: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

Re: [blink-dev] Intent to Ship: Custom Highlight API

RE: [blink-dev] Intent to Ship: Custom Highlight API

RE: [blink-dev] Intent to Ship: Custom Highlight API

21 matches

Site Navigation

Mail list logo

Footer information