@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!

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

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.

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

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?

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

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.

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.

Huh, did the minutes here get lost?

Discussion starts here in the logs

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

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

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/

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.