Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-pseudo-4] Proposal: Highlight API #4307

Closed
sanketj opened this issue Sep 14, 2019 · 13 comments
Closed

[css-pseudo-4] Proposal: Highlight API #4307

sanketj opened this issue Sep 14, 2019 · 13 comments

Comments

@sanketj
Copy link
Member

@sanketj sanketj commented Sep 14, 2019

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:

Requested amount of time: 30 minutes

@sanketj
Copy link
Member Author

@sanketj sanketj commented Sep 14, 2019

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

Loading

@sanketj
Copy link
Member Author

@sanketj sanketj commented Sep 15, 2019

Loading

@dbaron
Copy link
Member

@dbaron dbaron commented Sep 15, 2019

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.

Loading

@AmeliaBR
Copy link
Contributor

@AmeliaBR AmeliaBR commented Sep 16, 2019

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

Loading

@tabatkins
Copy link
Member

@tabatkins tabatkins commented Sep 16, 2019

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?

Loading

@marisademeglio
Copy link

@marisademeglio marisademeglio commented Sep 16, 2019

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

Loading

@sanketj
Copy link
Member Author

@sanketj sanketj commented Sep 16, 2019

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.

Loading

@sanketj
Copy link
Member Author

@sanketj sanketj commented Sep 17, 2019

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.

Loading

@emilio
Copy link
Collaborator

@emilio emilio commented Sep 23, 2019

Huh, did the minutes here get lost?

Loading

@astearns
Copy link
Member

@astearns astearns commented Sep 28, 2019

Loading

@astearns
Copy link
Member

@astearns astearns commented Sep 28, 2019

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

Loading

@c-smile
Copy link

@c-smile c-smile commented Oct 5, 2019

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:

Loading

@sanketj
Copy link
Member Author

@sanketj sanketj commented Oct 7, 2019

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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet