[css-pseudo-4] Proposal: Highlight API

[sanketj]

Link to existing highlight pseudo element spec: https://www.w3.org/TR/css-pseudo-4/#highlight-pseudos
Link to highlight API explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/explainer.md

Short summary of the concept (first paragraph from highlight API explainer):
The Highlight API extends the concept of CSS Highlight Pseudo-elements by providing a way for web developers to style the text of arbitrary Range objects, rather than being limited to the user-agent defined ::selection, ::inactive-selection, ::spelling-error, and ::grammar-error. 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 selection to represent online collaboration, and spellchecking frameworks.

I would like to discuss this proposal with the CSS WG at TPAC 2019. Creating this issue to track that request.

Hoped outcomes from CSS WG discussion at TPAC:

• Familiarize CSS WG with the highlight API and take initial feedback
• Get approval to write an editor's draft and declare intent to publish a FPWD
• Discuss (and hopefully resolve) issues listed below

Issues to discuss:

• Status of implementer interest in existing highlight pseudo elements
• Relation between HighlightRange#priority and other highlight pseudo elements (Relation between HighlightRange#priority and other highlight pseudo elements MicrosoftEdge/MSEdgeExplainers#71)
• How should inline highlight range group styles with 'inherit' values be treated? (How should inline highlight range group styles with 'inherit' values be treated? MicrosoftEdge/MSEdgeExplainers#110)

Requested amount of time: 30 minutes

[sanketj]

@atanassov, could you please add the 'Agenda+' label to this issue and include it in the CSS WG agenda for TPAC? I don't have permission to do so myself. Thanks!

[sanketj]

Full list of existing Highlight API issues: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues?q=is%3Aissue+is%3Aopen+label%3A%22Highlight+API%22

[dbaron]

I'm happy to see this moving forward; I've wanted an API like this for a while.

A few thoughts:

• I'm inclined to think that the naming should use existing terms in the web platform (probably "range") rather than inventing a new one ("highlight")
• I'm a little worried about the ergonomics of the API for adding a range to a particular named group when the caller is not sure if that group already exists. It would be useful to see an example of that in the explainer -- I suspect it's a bit difficult and could be improved, but I'm not sure.

[AmeliaBR]

should use existing terms in the web platform (probably "range") rather than inventing a new one ("highlight")

We already use "highlight" in CSS, although the name isn't exposed to authors. ::selection, ::inactive-selection, ::spelling-error, and ::grammar-error are highlight pseudo-elements
https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos

[tabatkins]

I'm a little worried about the ergonomics of the API for adding a range to a particular named group when the caller is not sure if that group already exists.

Yeah, it'd be:

if(!CSS.highlights.has("foo")) {
  CSS.highlights.set("foo", new HighlightRangeGroup);
}
CSS.highlights.get("foo").add(myRange);

This is assuming that the HighlightRangeGroup is live and immediately responds to changes. Depending on semantics, it might be more like TypedOM and require you to re-set it before it sees the change, in which case the code could look like:

CSS.highlights.set("foo",
  (CSS.highlights.get("foo") || new HighlightRangeGroup)
  .add(anotherRange));

So yeah, a little painful.

---

That said, in practice, I'm not sure why a page would run into this situation. If they're doing highlighting, presumably they'd create and register the highlight group sometime early in the page lifecycle, and just hold onto it and modify the set as they need to change things?

[marisademeglio]

Hi CSS WG!

I'm writing from the sync media in publications CG. We are working on a synchronized narration format, intended for use with standalone HTML documents and also with publications. Both the concept and format have precedent with DAISY books and EPUB media overlays: playback of content with text phrase highlight synchronized with audio clip playback.

Have a look at our new demo.

One perennial issue for us is referencing elements in an HTML file -- ID fragments have historically been the go-to, but something non-destructive would be ideal. Perhaps the highlight API can help?

Anyone at TPAC this week and want to chat, I'd love to :)

[sanketj]

I'm a little worried about the ergonomics of the API for adding a range to a particular named group when the caller is not sure if that group already exists.

Yeah, it'd be:

if(!CSS.highlights.has("foo")) {
  CSS.highlights.set("foo", new HighlightRangeGroup);
}
CSS.highlights.get("foo").add(myRange);

This is assuming that the HighlightRangeGroup is live and immediately responds to changes. Depending on semantics, it might be more like TypedOM and require you to re-set it before it sees the change, in which case the code could look like:

CSS.highlights.set("foo",
  (CSS.highlights.get("foo") || new HighlightRangeGroup)
  .add(anotherRange));

So yeah, a little painful.

That said, in practice, I'm not sure why a page would run into this situation. If they're doing highlighting, presumably they'd create and register the highlight group sometime early in the page lifecycle, and just hold onto it and modify the set as they need to change things?

The HighlightsMap is a maplike object, so I would expect it to behave just like the JS Map in this regard. So this should work:

if(!CSS.highlights.has("foo")) {
  CSS.highlights.set("foo", new HighlightRangeGroup);
}
CSS.highlights.get("foo").add(myRange);

Here's an example of how this may be used: A spellchecking extension like Grammarly creates a highlight group for its spellcheck highlights when it first parses the page, and adds the group to the CSS.highlights map. (The extension may call .has to ensure there are no name conflicts before calling .set on the highlights map.) The extension will hold onto the group's name or the group itself. Subsequently, as the user types, a new misspelling is created. In response, the extension will create a range to surround the new spelling error and add the range to the group, either by directly calling .add if it was holding onto the group itself or via CSS.highlight.get(...).add(...) if it was holding onto the name.

[sanketj]

Hi CSS WG!

I'm writing from the sync media in publications CG. We are working on a synchronized narration format, intended for use with standalone HTML documents and also with publications. Both the concept and format have precedent with DAISY books and EPUB media overlays: playback of content with text phrase highlight synchronized with audio clip playback.

Have a look at our new demo.

One perennial issue for us is referencing elements in an HTML file -- ID fragments have historically been the go-to, but something non-destructive would be ideal. Perhaps the highlight API can help?

Anyone at TPAC this week and want to chat, I'd love to :)

@marisademeglio: I'm at TPAC the whole week, so would be happy to chat. We could sync up during a coffee break and find some time.

[emilio]

Huh, did the minutes here get lost?

[astearns]

Discussion starts here in the logs

https://logs.csswg.org/irc.w3.org/css/2019-09-15/#e1235420

[astearns]

And from the end https://logs.csswg.org/irc.w3.org/css/2019-09-15/#e1235420

RESOLVED: Adopt css-highlight-api as ED with sanketj, florian , and hober as editors; add issue into css-pseudo-4 for where it might be integrated pointing at the ED

[c-smile]

Just in case: I've implemented highlights in Sciter engine 3 years ago and have quite possitive experience with them so far.

Primary usage: spell checker highlights and syntax colorization.

The only major difference from the Highlight API spec is that I am using ::mark(...) pseudo element rather than ::highlight(...)

Yet it would be very benificial I think to allow ::highlight(...) to be applied to content of <textarea> and <input> elements:

textarea::mark(number) { color: brown; }
textarea::mark(number-unit) { color: brown; }
textarea::mark(string) { color: teal; }
textarea::mark(keyword) { color: blue; }
textarea::mark(symbol) { color: brown; }
textarea::mark(literal) { color: brown; }
textarea::mark(comment) { color: green; }

So these can be used as code editors.

Some details and samples:

• https://sciter.com/tokenizer-mark-syntax-colorizer/
• https://sciter.com/mark-feature-is-comming/

[sanketj]

Thanks @c-smile. We have an open issue to make highlights work inside textarea and inputs: MicrosoftEdge/MSEdgeExplainers#78. I think we also need to make them work well with closed web components.

We were tracking the highlight API in the MSEdgeExplainer repo before, but it will soon be moved over to this repo.