sa...@microsoft.com, ffi...@microsoft.com, pc...@microsoft.com, dan...@microsoft.com
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/highlight/explainer.md
https://drafts.csswg.org/css-highlight-api-1/
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.
Custom Highlight API, Highlight API
https://github.com/w3ctag/design-reviews/issues/584
Issues addressed
Low: This feature received positive support from Safari and Firefox at TPAC 2019. Safari has implemented the feature.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/482)
WebKit: Shipped/Shipping (https://developer.apple.com/safari/technology-preview/release-notes/)
Highlight API listed in Release 99 notes.
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.
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).
DevTools shows ::highlight pseudo elements, in the same way that it shows other pseudo elements.
Yes
https://wpt.fyi/results/css/css-highlight-api?label=master&label=experimental&aligned&q=css
https://wpt.fyi/results/css/css-highlight-api/painting?label=master&label=experimental&aligned&q=css
--enable-blink-features=HighlightAPI
False
Comments:
https://chromestatus.com/feature/5436441440026624
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ix2u8NHG5Po/m/jjMjWIHXAQAJ
This intent message was generated by Chrome Platform Status.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SN6PR00MB04484770F08C2680983FAC60C5F99%40SN6PR00MB0448.namprd00.prod.outlook.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL0PR00MB0435222C2F1E0F4BC013388FC5F99%40BL0PR00MB0435.namprd00.prod.outlook.com.
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
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, 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 <flo...@rivoal.net>
Sent: Friday, August 13, 2021 2:32 PM
To: Daniel Clark <dan...@microsoft.com>
Cc: blin...@chromium.org; Fernando Fiori <ffi...@microsoft.com>; Bo Cupp <pc...@microsoft.com>; Sanket Joshi (EDGE) <sa...@microsoft.com>; Delan Azabani <daza...@igalia.com>
Subject: Re: [blink-dev] Intent to Ship: Custom Highlight API
Hi all!
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 <rby...@chromium.org>
Sent: Friday, August 13, 2021 8:58 AM
To: Daniel Clark <dan...@microsoft.com>
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.
On Aug 19, 2021, at 1:15, Delan Azabani <daza...@igalia.com> 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 <https://crbug.com/1179938>). 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.htmlCheers,Delan AzabaniIgalia // 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+...@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+...@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.