CSS Custom Highlight API Module Level 1

CSS Custom Highlight API Module Level 1
CSS Custom Highlight API Module Level 1
Editor’s Draft
9 January 2026
More details about this document
This version:
Latest published version:
Previous Versions:
Feedback:
CSSWG Issues Repository
Inline In Spec
Editors:
Dan Clark
Microsoft Corporation
Fernando Fiori
Microsoft Corporation
Florian Rivoal
On behalf of Bloomberg
Megan Gardner
Apple Inc.
Former Editor:
Sanket Joshi
Microsoft Corporation
Suggest an Edit for this Spec:
GitHub Editor
World Wide Web Consortium
W3C
liability
trademark
and
permissive document license
rules apply.
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
18 August 2025 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
new
Range
();
setStart
document
body
);
setEnd
document
body
);
CSS
highlights
set
"example-highlight"
new
Highlight
));
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
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
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.
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
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
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
new
Range
();
setStart
div
);
setEnd
div
);
let
new
Highlight
);
CSS
highlights
set
'foo'
);
CSS
highlights
set
'bar'
);
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
255
0.3
);
style
body
Lorem Ipsum.
script
let
textNode
document
body
firstChild
let
r1
new
Range
();
r1
setStart
textNode
);
r1
setEnd
textNode
);
let
r2
new
Range
();
r2
setStart
textNode
);
r2
setEnd
textNode
);
CSS
highlights
set
"sample"
new
Highlight
r1
r2
));
script
In other words, this rendering would be correct:
orem I
psum.
However, this one would be incorrect:
or
em
psum.
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
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
);
r1
setEnd
textNode
);
let
r2
new
Range
();
r2
setStart
textNode
);
r2
setEnd
textNode
);
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.
Som
e t
ext
Setting
h1
priority
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 t
ext
4.2.6.
Highlight types
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 highlight
s 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
Range
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
Range
s or
StaticRange
s.
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.
Range
s are
live ranges
The user agent will adjust the
boundary points
of
Range
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
StaticRange
in response to DOM changes,
nor can they be modified by the author after creation.
The user agent is expected to store the actual
StaticRange
s, rather than backing
them up with live
Range
s.
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
StaticRange
in order to avoid this costly but unnecessary step.
Conversely, authors who use
StaticRange
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
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
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
);
r1
setEnd
textNode
);
let
r2
new
Range
();
r2
setStart
textNode
);
r2
setEnd
textNode
);
let
r3
new
Range
();
r3
setStart
textNode
);
r3
setEnd
textNode
);
let
h1
new
Highlight
r1
r3
);
let
h2
new
Highlight
r2
);
h1
priority
h2
priority
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
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
float
optional
HighlightsFromPointOptions
options
= {});
};
dictionary
HighlightHitResult
Highlight
highlight
sequence
AbstractRange
ranges
};
dictionary
HighlightsFromPointOptions
sequence
ShadowRoot
shadowRoots
= [];
};
The
highlightsFromPoint(
options
method must return the result of running these steps:
If any of the following are true, return the empty
sequence
is negative
is negative
is greater than the
viewport
width excluding the size of a rendered scroll bar (if any)
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
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
Let
result
be a new
HighlightHitResult
with
highlight
set to
highlight
For each
AbstractRange
abstractRange
in
highlight
If
abstractRange
is an
invalid
StaticRange
, then
continue
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.
If the coordinates
fall inside at least one of the
DOMRect
s 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.
If
result
ranges
is not empty, append
result
to
results
Sort
results
by descending order of
priority
of its
HighlightHitResult
s'
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

, 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
CSS
style sheet
renderer
UA
that interprets the semantics of a style sheet and renders
documents that use them.
authoring tool
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
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:
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:
pseudo-elements
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:
[CSS-CASCADE-6]
Elika Etemad; Miriam Suzanne; Tab Atkins Jr..
CSS Cascading and Inheritance Level 6
. URL:
[CSS-DISPLAY-4]
Elika Etemad; Tab Atkins Jr..
CSS Display Module Level 4
. URL:
[CSS-PSEUDO-4]
Elika Etemad; Alan Stearns.
CSS Pseudo-Elements Module Level 4
. URL:
[CSS2]
Bert Bos; et al.
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification
. URL:
[CSSOM-1]
Daniel Glazman; Emilio Cobos Álvarez.
CSS Object Model (CSSOM)
. URL:
[CSSOM-VIEW-1]
Simon Fraser; Emilio Cobos Álvarez.
CSSOM View Module
. URL:
[DOM]
Anne van Kesteren.
DOM Standard
. Living Standard. URL:
[GEOMETRY-1]
Sebastian Zartner; Yehonatan Daniv.
Geometry Interfaces Module Level 1
. URL:
[HTML]
Anne van Kesteren; et al.
HTML Standard
. Living Standard. URL:
[INFRA]
Anne van Kesteren; Domenic Denicola.
Infra Standard
. Living Standard. URL:
[RFC2119]
S. Bradner.
Key words for use in RFCs to Indicate Requirement Levels
. March 1997. Best Current Practice. URL:
[SELECTORS-4]
Elika Etemad; Tab Atkins Jr..
Selectors Level 4
. URL:
[WebIDL]
Edgar Chen; Timothy Gu.
Web IDL Standard
. Living Standard. URL:
Non-Normative References
[CSS-SYNTAX-3]
Tab Atkins Jr.; Simon Sapin.
CSS Syntax Module Level 3
. URL:
[CSS-VALUES-4]
Tab Atkins Jr.; Elika Etemad.
CSS Values and Units Module Level 4
. URL:
[I18N-GLOSSARY]
Richard Ishida; Addison Phillips.
Internationalization Glossary
. URL:
IDL Index
enum
HighlightType
"highlight"
"spelling-error"
"grammar-error"
};