[csswg-drafts] [css-highlight-api][css-pseudo] Highlight Types (#13375)

Crissov has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-highlight-api][css-pseudo] Highlight Types ==
#6498 has previous discussion and resolutions on [`HighlightType`](https://drafts.csswg.org/css-highlight-api-1/#enumdef-highlighttype):

~~~~ C
enum HighlightType {
  "highlight",
  "spelling-error",
  "grammar-error"
};
~~~~

The [prose](https://drafts.csswg.org/css-highlight-api-1/#highlight-types) says the predefined values are modeled after [_highlight pseudo-elements_ in css-pseudo](https://drafts.csswg.org/css-pseudo/#highlight-pseudos) and are intended for improved accessibility.

Only the `::grammar-error` and `::spelling-error` pseudos currently have equivalent types defined, `::selection`, `::search-text` and `::target-text` do not. 
If I understand the reason for this correctly, it is that selecting, searching and targeting text should remain under the central control of the browser, not the script author. I would not disagree with that, although it _might_ still make sense to provide respective types, even if discouraged.

Other types for use case scenarios of custom highlights, which generic selectors could never handle, have not yet been specified either.

The relevant note in the spec reads:

> This initial set of types was chosen because they are expected to be popular use cases for Highlight API and there is some existing support for expressing their semantics in platform accessibility APIs today. Accessibility APIs currently don’t have any way to express the specific semantics of other expected Highlight API use cases. More types could later be added to `HighlightType` as accessibility APIs gain support for expressing additional popular use cases of Highlight API.

Other highlighting use cases for this API include, among others:

- syntax elements (keywords, identifiers, comments, delimiters etc.) of computer code
- levels and grouping by matching open/close characters, e.g. parentheses, or by nesting/indentation
- differences between versions or alternatives: additions/insertions, removals/deletions, reordering/positional changes, renaming/word changes, increments …
- places of editorial remarks like existing orthography and grammar checks, e.g. typographic or stylistic failures, errors, mistakes, warnings, notes, but also for code linters and prettifiers 
- cross references beyond simple URL targets, e.g. for headings and captions or labels and addresses like for spreadsheet cells etc.
- points for informational annotation that can be derived from sources outside the host document, e.g. conversions, translations and resolutions, or from text-internal but non-deterministic locations, e.g. expansions

I think it may make sense to split the _type_ attribute into two, one for the general highlighting purpose and one for the specific highlight category. Rough examples:

- `::grammar-error`: _language + error_, but _grammar_ could be a more specific alias of _language_
- `::spelling-error`: _language + error_, but _error_ here really covers all kinds and levels of probable mistakes, custom ones could be more nuanced 
- `::selection`: _interaction + mark_
- `::search-text`: _interaction + match_
- `::target-text`: _reference + match_
- `::highlight(word-choice)`: _language + mistake_
- `::highlight(code-comment)`: _structure + note_
- `::highlight(matching-bracket)`: _structure + match_
- `::highlight(diff-del)`: _comparison + warning_
- `::highlight(cell-headers)`: _reference + match_
- `::highlight(isbn)`: _annotation + note_

This may be over-engineering it, though. Perhaps a couple of additional types would suffice, but I strongly believe the spec should not wait for them to be reflected in accessibility APIs first, instead should be guided by actual use (but not misuse) of this API.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13375 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 21 January 2026 11:57:53 UTC