CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 date: Wed, 16 Jul 2025 17:54:20 GMT content-type: text/html; charset=utf-8 content-length: 44010 last-modified: Wed, 16 Jul 2025 17:48:23 GMT access-control-allow-origin: * etag: W/"6877e5e7-37dd0" expires: Wed, 16 Jul 2025 18:04:20 GMT cache-control: max-age=600 content-encoding: gzip x-proxy-cache: MISS x-github-request-id: DB73:C1246:D2A0B:DA4FD:6877E74C accept-ranges: bytes age: 0 via: 1.1 varnish x-served-by: cache-sjc1000103-SJC x-cache: MISS x-cache-hits: 0 x-timer: S1752688461.844946,VS0,VE137 vary: Accept-Encoding x-fastly-request-id: 910efc641b8b103cb6041ade0a6df8df59739a41 strict-transport-security: max-age=31536000; includeSubDomains; preload expect-ct: enforce, max-age=2592000 alt-svc: h3=":443"; ma=86400 CSS Custom Highlight API Module Level 1

CSS Custom Highlight API Module Level 1

Editor’s Draft, 2 July 2025

Abstract

This CSS module describes a mechanism for styling arbitrary ranges of a document identified by script.

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, etc.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Please send feedback by filing issues in GitHub (preferred), including the spec code “css-highlight-api” in the title, like this: “[css-highlight-api] …summary of comment…”. All issues and comments are archived. Alternately, feedback can be sent to the (archived) public mailing list www-style@w3.org.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is non-normative.

The Custom Highlight API extends the concept of highlight pseudo-elements (see CSS Pseudo-Elements 4 § 3 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, or spellchecking frameworks.

The Custom Highlight API provides a programmatic way of adding and removing highlights that do not affect the underlying DOM structure, but instead applies styles to text based on range objects, accessed via the ::highlight() pseudo element.

The following code uses the ::highlight() pseudo-element to apply a yellow background and blue foreground color to the text One two. It does so by adding a Highlight to the HighlightRegistry (both of these are new concepts introduced by this specification). The Highlight will contain a Range whose boundary points surround the text One two.

<style>
  :root::highlight(example-highlight) {
    background-color: yellow;
    color: blue;
  }
</style>
<body><span>One </span><span>two </span><span>three…</span>
<script>
  let r = new Range();
  r.setStart(document.body, 0);
  r.setEnd(document.body, 2);
  CSS.highlights.set("example-highlight", new Highlight(r));
</script>

The result would look like:

One Two three…

2. Module Interactions

This module depends on the Infra Standard [INFRA] and on WebIDL [WebIDL].

It assumes general familiarity with CSS and with the DOM Standard [DOM], and specifically extends the mechanisms defined in CSS Pseudo-Elements Module Level 4 [css-pseudo-4] to handle highlight pseudo-elements. The Selectors Level 4 [selectors-4] specification defines how pseudo-elements work in general.

See References for a full list of dependencies.

Note: This draft is an early version. As it matures, the CSS-WG could decide to keep it as an independent module, or might prefer to fold it into [css-pseudo-4], or a later version of that module.

3. Setting up Custom Highlights

3.1. Creating Custom Highlights

A custom highlight is a collection of ranges representing portions of a document. They do not necessarily fit into the element tree, and can arbitrarily cross element boundaries without honoring its nesting structure. They can be used to affect the appearance of these portions of the document (see § 4 Styling Custom Highlights), or to handle to events associated with them (see § 7 Event Handling).

Custom highlights are represented by Highlight objects, setlike objects whose set entries are AbstractRange objects. Ranges can be added to a custom highlight either by passing them to its constructor, or by using the usual API of setlike objects to manipulate its set entries.

Note: As the ranges in a custom highlight are AbstractRange objects, authors can chose between using Range objects and StaticRange objects. See § 5.2 Range Updating and Invalidation for more details about this choice and its implications.

Note: When creating Range objects for use in custom highlights, it is suggested that authors avoid placing range endpoints in the middle of a grapheme, such as when a visible unit of text is comprised of multiple Unicode code points. Doing so can create undesirable highlighting effects, such as highlighting only part of an Indic syllable. In addition, care needs to be taken to avoid placing an endpoint in the middle of a supplementary character.

enum HighlightType {
  "highlight",
  "spelling-error",
  "grammar-error"
};
[Exposed=Window]
interface Highlight {
  constructor(AbstractRange... initialRanges);
  setlike<AbstractRange>;
  attribute long priority;
  attribute HighlightType type;
};

See § 4.2.5 Priority of Overlapping Highlights for more information on the priority attribute.

See § 4.2.6 Highlight types for more information on the type attribute.

When the Highlight(AbstractRange... initialRanges) constructor is invoked, run the following steps:

Let highlight be the new Highlight object.
Set highlight’s priority to 0.
Set highlight’s type to highlight.
For each range of initialRanges, let rangeArg be the result of converting range to an ECMAScript value, then run the steps for a built-in setlike add function, with highlight as the this value, and rangeArg as the argument.
Return highlight.

3.2. Registering Custom Highlights

In order to have any effect, custom highlights need to be registered into the highlight registry.

The highlight registry is accessed via the highlights attribute of the CSS namespace, and represents all the custom highlights registered for the current global object’s associated Document. It is a maplike, and can be updated using the usual methods. It’s map entries is initially empty.

A custom highlight is said to be registered if it is in the highlight registry. It stops being registered if it is later removed.

partial namespace CSS {
  readonly attribute HighlightRegistry highlights;
};
[Exposed=Window]
interface HighlightRegistry {
  maplike<DOMString, Highlight>;
};

To register a custom highlight, invoke the set method of the highlight registry which will run the steps for a built-in maplike set function, with the highlight registry as the this value, the passed-in custom highlight name as keyArg, and the passed-in highlight as valueArg.

The custom highlight name assigned to a custom highlight when it is registered is used to identify the highlight during styling (see § 4 Styling Custom Highlights).

Note: When registering a custom highlight, authors are advised to use a custom highlight name that is a valid CSS identifier. Using a name that is not a valid identifier can make the highlight hard, and in some cases impossible, to style via CSS.

Note: It is possible to register a custom highlight with more than one custom highlight name. However, using more than one name to style a highlight will assign the highlight multiple different sets of styles, without a way to control the stacking order of conflicting styles within these sets during painting. This could be limiting for authors and could cause confusing painting behavior (see the example below for more context). Therefore, authors are advised to only use one name per highlight during styling.

<style>
  div::highlight(bar) {
    color: red;
  }
  div::highlight(foo) {
    color: green;
  }
</style>
<body><div>abc</div>
<script>
  let div = document.body.firstChild;
  let r = new Range();
  r.setStart(div, 0);
  r.setEnd(div, 1);
  let h = new Highlight(r);
  CSS.highlights.set('foo', h);
  CSS.highlights.set('bar', h);
</script>

In the example above, the same custom highlight object is registered under the names foo and bar. Since each of the style rules target the same highlight and have the same specificity, authors might expect the last rule to win in cascading order and the highlighted content to be green. However, each highlight name gets an independent set of highlight styles, and the highlight will be painted once per name. In this case, because foo was registered before bar, the highlight will be first painted with foo’s color (green) and then with bar’s color (red). As a result, the highlighted content will appear red.

4. Styling Custom Highlights

4.1. The Custom Highlight Pseudo-element: ::highlight()

The ::highlight() pseudo-element (also known as the custom highlight pseudo-element) represents the portion of a document that is being contained or partially contained in all the ranges of the registered custom highlight with the custom highlight name specified as its argument.

4.2. Processing Model

4.2.1. Applicable Properties

Custom highlight pseudo-elements, like the built-in highlight pseudo-elements, can only be styled with a limited set of properties. See CSS Pseudo-Elements 4 § 3.2 Styling Highlights for the full list.

4.2.2. Default Styles

UAs must not define any default UA stylesheet rules or paired default highlight colors for any custom highlight pseudo-elements. In other words, when some content is highlighted by an unstyled custom highlight, its presentation must not change.

4.2.3. Cascading and Inheritance

The cascading and inheritance of custom highlight pseudo-elements is handled identically to that of the built-in highlight pseudo-elements, as defined in CSS Pseudo-Elements 4 § 3.5 Cascading and Per-Element Highlight Styles.

4.2.4. Painting

The painting of custom highlights is also handled identically to that of the built-in highlight pseudo-elements, as specified in CSS Pseudo-Elements 4 § 3.4 Area of a Highlight and CSS Pseudo-Elements 4 § 3.6 Painting the Highlight, with the following clarifications:

Collapsed ranges are not rendered.

Overlapping ranges within a single custom highlight are rendered as if a single range representing the union of the overlapping ones had been specified.

The following example renders in a single highlight with semi-transparent blue background, not two overlapping ones which can be seen through each other.

<style>
  ::highlight(sample) { background-color: rgba(0, 0, 255, 0.3); }
</style>
<body>Lorem Ipsum.
<script>
  let textNode = document.body.firstChild;
  let r1 = new Range();
  r1.setStart(textNode, 1);
  r1.setEnd(textNode, 5);
  let r2 = new Range();
  r2.setStart(textNode, 3);
  r2.setEnd(textNode, 7);
  CSS.highlights.set("sample", new Highlight(r1, r2));
</script>

In other words, this rendering would be correct:

Lorem Ipsum.

However, this one would be incorrect:

Lorem Ipsum.

The highlight overlays of the custom highlights are below those of the built-in highlight pseudo-elements in the stacking order described in CSS Pseudo-Elements 4 § 3.6 Painting the Highlight.
The relative stacking order of the highlight overlays of multiple custom highlights is defined by their priority (see § 4.2.5 Priority of Overlapping Highlights).

4.2.5. Priority of Overlapping Highlights

A custom highlight’s priority attribute defines its priority. This is used to determine the stacking order of the corresponding highlight overlay during painting operations (see § 4.2.4 Painting). A higher priority results in being above in the stacking order. A custom highlight will have a default numerical priority of 0 if its priority attribute has not been explicitly set.

When two or more custom highlights have the same numerical priority, the one most recently registered has the higher effective priority.

<style>
  :root::highlight(foo) {
    color:blue;
    background-color:yellow;
  }
  :root::highlight(bar) {
    background-color:orange;
  }
</style>
<body>Some text
<script>
  let textNode = document.body.firstChild;
  let r1 = new Range();
  r1.setStart(textNode, 0);
  r1.setEnd(textNode, 6);
  let r2 = new Range();
  r2.setStart(textNode, 3);
  r2.setEnd(textNode, 9);
  let h1 = new Highlight(r1);
  let h2 = new Highlight(r2);
  CSS.highlights.set("foo", h1);
  CSS.highlights.set("bar", h2);
</script>

As there are no priorities set (i.e. there is a tie between h1 and h2), the custom highlights' styles are stacked in order of insertion into the highlight registry. The rendered results will have "Som" with blue text on yellow background, "e t" with blue text on orange background, and "ext" with the default color on orange background.

Some text

Setting h1.priority = 1; would cause h1 to stack higher than h2, which would result in "Some t" being blue on yellow, and "ext" being default color on orange.

Some text

4.2.6. Highlight types

A custom highlight’s type attribute is used by authors to specify the semantic meaning of the highlight. This allows assistive technologies to include this meaning when exposing the highlight to users.

A custom highlight will have a default type of highlight if its type attribute has not been explicitly set.

Note: Authors are advised to set a custom highlight’s type to spelling-error when that custom highlight is being used to emphasize misspelled content. Authors are advised to set a custom highlight’s type to grammar-error when that custom highlight is being used to emphasize content that is grammatically incorrect. For all other use cases type is best left as highlight.

UAs should make custom highlights available to assistive technologies. When exposing a highlight using a given platform accessibility API, UAs should expose the semantic meaning of the highlight as specified by its type attribute with as much specificity as possible for that accessibility API.

Note: For example, if a platform accessibility API has the capability to express spelling errors and grammar errors specifically, then UAs is expected to use these capabilities to convey the semantics for highlights with spelling-error and spelling-error. If an accessibility API only has the capability to express spelling errors, then UAs would be expected to convey both highlights with spelling-error and with grammar-error using spelling error semantics. If an accessibility API has support for expressing neither spelling errors nor grammar errors, then UAs would expose all highlights as generic highlight regardless of their actual type.

Note: 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.

5. Responding to Changes

5.1. Repaints

The addition or removal of a custom highlight in the highlight registry, or of a range in a registered custom highlight, must cause the user agent to reevaluate the rendering, and to repaint if appropriate.

The user agent must also repaint highlights as needed in response to changes by the author to the priority, or to the boundary points of Ranges of a registered custom highlight.

This repaint is asynchronous, and the APIs mentioned above must not block while waiting for the repaint to happen.

5.2. Range Updating and Invalidation

Authors can build custom highlights using either Ranges or StaticRanges.

The resulting custom highlight represents the same parts of the document, and can be styled identically. However, the behavior is different in case the underlying document is modified.

Ranges are live ranges. The user agent will adjust the boundary points of Ranges in response to DOM changes overlapping the range or at its boundary, and repaint accordingly. Boundary points of live ranges can also be changed by the author.

On the other hand, the user agent must not adjust the boundary points of StaticRanges in response to DOM changes, nor can they be modified by the author after creation. The user agent is expected to store the actual StaticRanges, rather than backing them up with live Ranges.

Updating all Range objects as the DOM is modified has a significant performance cost. Authors who intend to observe DOM changes and react to them by adjusting or recreating the ranges in their custom highlights are strongly encouraged to use StaticRanges in order to avoid this costly but unnecessary step.

Conversely, authors who use StaticRanges should observe and react to DOM changes, by discarding stale ranges or custom highlights and recreating new ones.

When computing how to render a document, if start node or end node of any range in the highlight registry associated with that document’s window refer to a Node whose shadow-including root is not that document, the user agent must ignore that range. If any StaticRange in the highlight registry associated with that document’s window is not valid, the user agent must ignore that range.

6. Interacting with Custom Highlights

The highlightsFromPoint(x, y, options) method allows developers to build scenarios involving user interaction with custom highlights. The method returns a sequence containing HighlightHitResult objects which encapsulate the custom highlights and their ranges that are hit at a given x, y coordinate. This sequence is ordered by descending order of priority of its HighlightHitResult’s highlights. By default, custom highlights in a shadow tree are not returned, but the developer has the possibility to pass in an optional options dictionary with a shadowRoots property containing a sequence of ShadowRoot objects. Highlights contained within a shadow tree provided in this way will be returned.

The following example shows a way to use highlightsFromPoint to interact with mouse click events.

<style>
  :root::highlight(foo) {
    background-color:yellow;
  }
  :root::highlight(bar) {
    color:red;
  }
</style>
<body>abcd
<script>
  document.addEventListener('click', (event) => {
    const mouseX = event.clientX;
    const mouseY = event.clientY;
    console.log(CSS.highlights.highlightsFromPoint(mouseX, mouseY));
  });
  let textNode = document.body.firstChild;
  let r1 = new Range();
  r1.setStart(textNode, 0);
  r1.setEnd(textNode, 2);
  let r2 = new Range();
  r2.setStart(textNode, 1);
  r2.setEnd(textNode, 2);
  let r3 = new Range();
  r3.setStart(textNode, 3);
  r3.setEnd(textNode, 4);
  let h1 = new Highlight(r1, r3);
  let h2 = new Highlight(r2);
  h1.priority = 1;
  h2.priority = 2;
  CSS.highlights.set("foo", h1);
  CSS.highlights.set("bar", h2);
</script>

The code above will display the following styled text, note that "b" is affected by both highlights h1 and h2, whereas "a" and "d" are only affected by h1:

abcd

In this example there’s an event listener set on click events that logs the custom highlights and their ranges present at the point where the click was made. The following sequences are some examples of what will be printed to console after a click:

[ HighlightHitResult {highlight: h1, ranges: [r1]} ], if the user clicks on character "a". Note that only r1 is included in the HighlightHitResult returned since that’s the only range in h1 that was hit.
[ HighlightHitResult {highlight: h2, ranges: [r2]}, HighlightHitResult {highlight: h1, ranges: [r1]} ], if the user clicks on character "b", as h2 has higher priority than h1.
[], if the user clicks on character "c".
[ HighlightHitResult {highlight: h1, ranges: [r3]} ], if the user clicks on character "d".

The method highlightsFromPoint is defined as part of the HighlightRegistry interface as follows:

partial interface HighlightRegistry {
  sequence<HighlightHitResult> highlightsFromPoint(float x, float y, optional HighlightsFromPointOptions options = {});
};
dictionary HighlightHitResult {
  Highlight highlight;
  sequence<AbstractRange> ranges;
};
dictionary HighlightsFromPointOptions {
  sequence<ShadowRoot> shadowRoots = [];
};

The highlightsFromPoint(x, y, options) method must return the result of running these steps:

If any of the following are true, return the empty sequence:
- x is negative
- y is negative
- x is greater than the viewport width excluding the size of a rendered scroll bar (if any)
- y is greater than the viewport height excluding the size of a rendered scroll bar (if any)
- The topmost box in the viewport in paint order that would be a target for hit testing at coordinates x,y when applying the transforms that apply to the descendants of the viewport, has an element associated to it that’s in a shadow tree whose shadow root is not contained by options.shadowRoots.
Otherwise, let results be an empty sequence.
For each Highlight highlight in this HighlightRegistry:
1. Let result be a new HighlightHitResult with highlight set to highlight.
2. For each AbstractRange abstractRange in highlight:
  1. If abstractRange is an invalid StaticRange, then continue.
  2. Let range be a new Range whose start node and end node are set to abstractRange’s start node and end node respectively, and start offset and end offset are set to abstractRange’s start offset and end offset respectively.
  3. If the coordinates x,y fall inside at least one of the DOMRects returned by calling getClientRects() on range, then append abstractRange to result.ranges.
    
    Note: The specifics of hit testing are out of scope of this specification and therefore the exact details of highlightsFromPoint() are too. Hit testing will hopefully be defined in a future revision of CSS or HTML.
3. If result.ranges is not empty, append result to results.
Sort results by descending order of priority of its HighlightHitResults' highlight attributes.
Return results.

7. Event Handling

Section on Events TBD, based on https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/events-explainer.md

should custom highlights have a dedicated event handling mechanism, or should that be added to pseudo-elements in general?

Appendix A. Privacy Considerations

This section is non-normative.

This specification is not thought to introduce any new privacy concern. Anyone suspecting that this is not accurate is encouraged to get in touch with the CSS Working Group or the co-editors.

Appendix B. Security Considerations

This section is non-normative.

This specification is not thought to introduce any new security concern. Anyone suspecting that this is not accurate is encouraged to get in touch with the CSS Working Group or the co-editors.

Appendix C. Acknowledgements

This section is non-normative.

Acknowledge people (other than editors) who deserve credit for this.

Appendix D. Changes

This section is non-normative.

Changes since the 15 December 2021 Working Draft

In addition to various editorial improvements and minor tweaks, the main changes are:

Added a highlightsFromPoint method to HighlightRegistry. (See Issue 7513)
Specified that highlight repainting has to be done asynchronously. (See Issue 6987)
Clarify that UAs cannot specify paired default highlight colors for custom highlights. (See Issue 6665)
Clarify that there is no restriction on custom highlights crossing containment boundaries. (See Issue 4598)
Added an I18N warning about placement of range endpoints in the middle of a grapheme or supplementary character.

Changes since the 8 December 2020 Working Draft

In addition to various editorial improvements and minor tweaks, the main changes are:

Renamed HighlightsRegister to HighlightRegistry
Removed the redundant add() method from HighlightRegistry. (See Issue 6092)
Make custom highlight overlays stack below native highlight overlays. (See Issue 4595)
Handle highlight priority with integers rather than floats. (See Issue 4592)
Define the default value for highlight priority to be 0. (See Issue 6136)
Made HighlightRegistry maplike (rather than setlike) and remove name property from Highlight. (See Issue 5910)
Clarified that ranges from the wrong window are not painted. (See Issue 6417)
Specify that custom highlights have no UA styles. (See Issue 6375)
Deferred to the [DOM] specification for range invalidation (See Issue 4597)
Added a type attribute to Highlight to give clearer semantics to different highlights, in support of exposing highlights to accessibility tools. (See Issue 6498)

Changes since the 22 October 2020 Working Draft

There have been only editorial changes since the 22 October 2020 Working Draft; see diffs.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Advisements are normative sections styled to evoke special attention and are set apart from other normative text with <strong class="advisement">, like this: UAs MUST provide an accessible alternative.

Tests

Tests relating to the content of this specification may be documented in “Tests” blocks like this one. Any such block is non-normative.

Conformance classes

Conformance to this specification is defined for three conformance classes:

style sheet: A CSS style sheet.
renderer: A UA that interprets the semantics of a style sheet and renders documents that use them.
authoring tool: A UA that writes a style sheet.

A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.

A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)

An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.

Partial implementations

So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.

Implementations of Unstable and Proprietary Features

To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.

Non-experimental implementations

Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.

To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.

Further information on submitting testcases and implementation reports can be found from on the CSS Working Group’s website at https://www.w3.org/Style/CSS/Test/. Questions should be directed to the public-css-testsuite@w3.org mailing list.

Index

Terms defined by this specification

constructor(), in § 3.1
constructor(...initialRanges), in § 3.1
custom highlight, in § 3.1
custom highlight name, in § 3.2
custom highlight pseudo-element, in § 4.1
"grammar-error", in § 3.1
"highlight", in § 3.1
Highlight, in § 3.1
highlight, in § 6
Highlight(), in § 3.1
HighlightHitResult, in § 6
Highlight(...initialRanges), in § 3.1
highlight registry, in § 3.2
HighlightRegistry, in § 3.2
highlights, in § 3.2
HighlightsFromPointOptions, in § 6
highlightsFromPoint(x, y), in § 6
highlightsFromPoint(x, y, options), in § 6
HighlightType, in § 3.1
priority
- attribute for Highlight, in § 3.1
- definition of, in § 4.2.5
ranges, in § 6
registered, in § 3.2
shadowRoots, in § 6
"spelling-error", in § 3.1
type, in § 3.1

Terms defined by reference

[CSS-CASCADE-5] defines the following terms:
- inheritance
[CSS-CASCADE-6] defines the following terms:
- cascade
[CSS-DISPLAY-4] defines the following terms:
- box
[CSS-PSEUDO-4] defines the following terms:
- ::grammar-error
- ::selection
- ::spelling-error
- highlight overlay
- highlight pseudo-element
- paired default highlight colors
[CSS-SYNTAX-3] defines the following terms:
- style rule
[CSS-VALUES-4] defines the following terms:
- identifier
[CSS2] defines the following terms:
- pseudo-elements
- viewport
[CSSOM-1] defines the following terms:
- CSS
[CSSOM-VIEW-1] defines the following terms:
- getClientRects()
- transforms
[DOM] defines the following terms:
- AbstractRange
- Node
- Range
- ShadowRoot
- StaticRange
- boundary point
- collapsed
- contained
- end node
- end offset
- event
- event listener
- live ranges
- partially contained
- range
- shadow root
- shadow tree
- shadow-including root
- start node
- start offset
- valid
[GEOMETRY-1] defines the following terms:
- DOMRect
[HTML] defines the following terms:
- associated Document
- current global object
[I18N-GLOSSARY] defines the following terms:
- grapheme
- supplementary character
- unicode code point
[INFRA] defines the following terms:
- contain
- continue
[SELECTORS-4] defines the following terms:
- specificity
[WebIDL] defines the following terms:
- DOMString
- Exposed
- converted to an ECMAScript value
- dictionary
- float
- long
- map entries
- maplike
- sequence
- set entries
- setlike

References

Normative References

[CSS-CASCADE-5]: Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 5. URL: https://drafts.csswg.org/css-cascade-5/
[CSS-CASCADE-6]: Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. CSS Cascading and Inheritance Level 6. URL: https://drafts.csswg.org/css-cascade-6/
[CSS-DISPLAY-4]: Elika Etemad; Tab Atkins Jr.. CSS Display Module Level 4. URL: https://drafts.csswg.org/css-display/
[CSS-PSEUDO-4]: Elika Etemad; Alan Stearns. CSS Pseudo-Elements Module Level 4. URL: https://drafts.csswg.org/css-pseudo-4/
[CSS2]: Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. URL: https://drafts.csswg.org/css2/
[CSSOM-1]: Daniel Glazman; Emilio Cobos Álvarez. CSS Object Model (CSSOM). URL: https://drafts.csswg.org/cssom/
[CSSOM-VIEW-1]: Simon Pieters. CSSOM View Module. URL: https://drafts.csswg.org/cssom-view/
[DOM]: Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[GEOMETRY-1]: Simon Pieters; Chris Harrelson. Geometry Interfaces Module Level 1. URL: https://drafts.fxtf.org/geometry/
[HTML]: Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]: Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]: S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SELECTORS-4]: Elika Etemad; Tab Atkins Jr.. Selectors Level 4. URL: https://drafts.csswg.org/selectors/
[WebIDL]: Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

Informative References

[CSS-SYNTAX-3]: Tab Atkins Jr.; Simon Sapin. CSS Syntax Module Level 3. URL: https://drafts.csswg.org/css-syntax/
[CSS-VALUES-4]: Tab Atkins Jr.; Elika Etemad. CSS Values and Units Module Level 4. URL: https://drafts.csswg.org/css-values-4/
[I18N-GLOSSARY]: Richard Ishida; Addison Phillips. Internationalization Glossary. URL: https://w3c.github.io/i18n-glossary/

IDL Index

enum HighlightType {
  "highlight",
  "spelling-error",
  "grammar-error"
};
[Exposed=Window]
interface Highlight {
  constructor(AbstractRange... initialRanges);
  setlike<AbstractRange>;
  attribute long priority;
  attribute HighlightType type;
};
partial namespace CSS {
  readonly attribute HighlightRegistry highlights;
};
[Exposed=Window]
interface HighlightRegistry {
  maplike<DOMString, Highlight>;
};
partial interface HighlightRegistry {
  sequence<HighlightHitResult> highlightsFromPoint(float x, float y, optional HighlightsFromPointOptions options = {});
};
dictionary HighlightHitResult {
  Highlight highlight;
  sequence<AbstractRange> ranges;
};
dictionary HighlightsFromPointOptions {
  sequence<ShadowRoot> shadowRoots = [];
};

Issues Index

Section on Events TBD, based on https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/events-explainer.md ↵

should custom highlights have a dedicated event handling mechanism, or should that be added to pseudo-elements in general? ↵

Acknowledge people (other than editors) who deserve credit for this. ↵

⚠MDN

CSS/highlights_static

In only one current engine.

FirefoxNoneSafariNoneChrome105+

Opera?Edge105+

Edge (Legacy)?IENone

Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?

⚠MDN

::highlight

In only one current engine.

FirefoxNoneSafariNoneChrome105+

Opera?Edge105+

Edge (Legacy)?IENone

Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?

Original Source | Taken Source