Abstract

This CSS module defines pseudo-elements, abstract elements that represent portions of the CSS render tree that can be selected and styled.

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 section describes the status of this document at the time of
its publication. Other documents may supersede this document. A list of
current W3C publications and the latest revision of this technical report
can be found in the W3C technical reports
index at https://www.w3.org/TR/.

Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.

GitHub Issues are preferred for discussion of this specification.
When filing an issue, please put the text “css-pseudo” in the title,
preferably like this:
“[css-pseudo] …summary of comment…”.
All issues and comments are archived,
and there is also a historical archive.

1. Introduction

This section is informative.

Pseudo-elements represent abstract elements of the document
beyond those elements explicitly created by the document language.
Since they are not restricted to fitting into the document tree,
they can be used to select and style portions of the document
that do not necessarily map to the document’s tree structure.
For instance, the ::first-line pseudo-element can
select content on the first formatted line of an element after text wrapping,
allowing just that line to be styled differently
from the rest of the paragraph.

Each pseudo-element is associated with an originating element and has syntax of the form ::name-of-pseudo.
This module defines the pseudo-elements that exist in CSS
and how they can be styled.
For more information on pseudo-elements in general,
and on their syntax and interaction with other selectors,
see [SELECTORS4].

<P>This is a somewhat long HTML
paragraph that will be broken into several
lines. The first line will be identified
by a fictional tag sequence. The other lines
will be treated as ordinary lines in the
paragraph.</P>

The lines might be broken as follows:

THIS IS A SOMEWHAT LONG HTML PARAGRAPH THAT
will be broken into several lines. The first
line will be identified by a fictional tag
sequence. The other lines will be treated as
ordinary lines in the paragraph.

This paragraph might be “rewritten” by user agents
to include a fictional tag sequence to represent ::first-line.
This fictional tag sequence helps to show how properties are inherited.

<P><P::first-line> This is a somewhat long HTML
paragraph that </P::first-line> will be broken into several
lines. The first line will be identified
by a fictional tag sequence. The other lines
will be treated as ordinary lines in the
paragraph.</P>

If a pseudo-element breaks up a real element,
the desired effect can often be described by a fictional tag sequence that closes and then re-opens the element.

Thus, if we mark up the previous paragraph with a span element encompassing the first sentence:

<P><SPAN class="test"> This is a somewhat long HTML
paragraph that will be broken into several
lines.</SPAN> The first line will be identified
by a fictional tag sequence. The other lines
will be treated as ordinary lines in the
paragraph.</P>

<P><P::first-line><SPAN class="test"> This is a somewhat long HTML
paragraph that will </SPAN></P::first-line><SPAN class="test"> be broken into several
lines.</SPAN> The first line will be identified
by a fictional tag sequence. The other lines
will be treated as ordinary lines in the
paragraph.</P>

2.1.1. Finding the First Formatted Line

In CSS, the ::first-line pseudo-element
can only have an effect when attached to a block container.
The first formatted line of an element
must occur inside a block-level descendant in the same flow
(i.e., a block-level descendant that is not out-of-flow due to floating or positioning).

For example, the first line of the DIV in <DIV><P>This line...</P></DIV> is the first line of the P (assuming that both P and DIV are blocks).

The first line of a table-cell or inline-block
cannot be the first formatted line of an ancestor element.
Thus, in <DIV><P STYLE="display: inline-block">Hello<BR>Goodbye</P> etcetera</DIV> the first formatted line of the DIV is not the line "Hello".

Note: Note that the first line of the p in this fragment: <p><br>First... doesn’t contain any letters (assuming the default style for br).
The word "First" is not on the first formatted line.

A user agent must act as if the fictional start tags of a ::first-line pseudo-element
were nested just inside the innermost enclosing block-level element.

During CSS inheritance, the portion of a child element that occurs on the first line
only inherits properties applicable to the ::first-line pseudo-element
from the ::first-line pseudo-element.
For all other properties inheritance is
from the non-pseudo-element parent of the first line pseudo element.
(The portion of a child element that does not occur on the first line
always inherits from the parent of that child.)

As explained in [CSS3TEXT],
a typographic letter unit can include more than one Unicode codepoint.
For example, combining characters must be kept with their base character.
Also, languages may have additional rules
about how to treat certain letter combinations.
In Dutch, for example, if the letter combination "ij" appears at the beginning of an element,
both letters should be considered within the ::first-letter pseudo-element. [UAX29] The UA should tailor its definition of typographic letter unit to reflect the first-letter traditions of the ::first-letter pseudo-element’s containing block’s content language.

Note: Note that the first typographic letter unit may in fact
be a digit, e.g., the “6” in “67 million dollars is a lot of money.”

If the characters that would form the ::first-letter are not in the same element, such as ‘T in <p>‘<em>T...,
the user agent may create a ::first-letter pseudo-element
from one of the elements, both elements, or simply not create a pseudo-element.
Additionally, if the first letter(s) of the block
are not at the start of the line (for example due to bidirectional reordering),
then the user agent need not create the pseudo-element(s).

2.2.1. Finding the First Letter

The first letter must occur on the first formatted line.
For example, in this HTML fragment: <p><br>First... the first line doesn’t contain any letters
and ::first-letter doesn’t match anything.
In particular, it does not match the “F” of “First”.

In CSS, the ::first-letter pseudo-element
only applies to block containers. A future version of this specification
may allow this pseudo-element to apply to more display types. The ::first-letter pseudo-element can be used
with all such elements that contain text,
or that have a descendant in the same flow that contains text.
A user agent should act as if the fictional start tag
of the ::first-letter pseudo-element
is just before the first text of the element,
even if that first text is in a descendant.

In CSS the first letter of a table-cell or inline-block
cannot be the first letter of an ancestor element.
Thus, in <DIV><P STYLE="display: inline-block">Hello<BR>Goodbye</P> etcetera</DIV> the first letter of the DIV is not the letter "H".
In fact, the DIV doesn’t have a first letter.
If an element is a list item (display: list-item),
the ::first-letter applies
to the first letter in the principal box after the marker.
User-Agents may ignore ::first-letter on list items with list-style-position: inside.
If an element has ::before or ::after content,
the ::first-letter applies to the first letter of the
element including that content.

Example:
After the rule p::before {content: "Note: "}, the
selector p::first-letter matches the "N" of "Note".

any other properties defined to apply to ::first-letter by their respective specifications

User agents may apply other properties as well.

Note: In previous levels of CSS,
User Agents were allowed to choose a line height, width and height based on the shape of the letter,
approximate font sizes,
or to take the glyph outline into account when formatting.
This possibility has been intentionally removed,
as it proved to be a poor solution for the intended use case (Drop Caps),
yet caused interoperability problems.

Example:
This CSS and HTML example shows a possible rendering of an initial cap.
Note that the fictional start tag of the first letter
is inside the span,
and thus the font weight of the first letter is normal,
not bold as the span:

<P>
<SPAN>
<P::first-letter>
T
</P::first-letter>he first
</SPAN>
few words of an article in the Economist.
</P>

Note that the ::first-letter pseudo-element tags abut the
content (i.e., the initial character), while the ::first-line
pseudo-element start tag is inserted right after the start tag of the
block element.

3. Highlight Pseudo-elements

The highlight pseudo-elements represent portions of a document that have been given a particular status
and are typically styled differently to indicate that status to the user.
For example,
selected portions of the document are typically highlighted
(given alternate background and foreground colors, or a color wash)
to indicate their selected status.
The following highlight pseudo-elements are defined:

::selection

::inactive-selection

The ::selection and ::inactive-selection pseudo-elements represent
the portion of a document that has been selected
as the target or object of some possible future user-agent operation(s).
They apply, for example, to selected text within an editable text field,
which would be copied by a copy operation or replaced by a paste operation.

::selection applies to active selections,
whereas ::inactive-selection applies to inactive selections
(e.g. when the document window is inactive and therefore not receiving events).

::spelling-error

The ::spelling-error pseudo-element represents
a portion of text that has been flagged by the user agent as misspelled.

::grammar-error

The ::grammar-error pseudo-element represents
a portion of text that has been flagged by the user agent as grammatically incorrect.

The highlight pseudo-elements do not necessarily fit into the element tree,
and can arbitrarily cross element boundaries without honoring its nesting structure.

The color property specifies the color of both the text
and all line decorations (underline, overline, line-through)
and emphasis marks (text-emphasis)
applied to the text
by the originating element and its ancestors and descendants.

Note: Historically (and at the time of writing)
only color and background-color have been interoperably supported.

For text, the corresponding overlay must cover at least the entire em box
and may extend further above/below the em box to the line box edges.
Spacing between two characters may also be part of the overlay area,
in which case it belongs to the innermost element that contains both characters
and is selected when both characters are selected.

For replaced content, the associated overlay must cover at least the entire replaced object,
and may extend outward to include the element’s entire content box.

The overlay may also include other other areas within the border-box of an element;
in this case, those areas belong to the innermost such element that contains the area.

Not sure if this is the correct way of describing the way things work.

3.4. Cascading and Per-Element Highlight Styles

Each element draws its own active portions of the highlight overlays,
which receives the styles specified by
the corresponding highlight pseudo-element styles
for which that element is the originating element.
When multiple styles conflict,
the winning style is determined by the cascade.
When any supported property is not given a value by the cascade,
it’s value is determined by inheritance from
the corresponding highlight pseudo-element of its originating element’s parent element
(regardless of whether that property is an inherited property).

The selection highlight would be green throughout,
with yellow text outside the <em> element
and orange text inside it.

Authors wanting multiple selections styles should use :root::selection for their document-wide selection style,
since this will allow clean overriding in descendants. ::selection alone applies to every element in the tree,
overriding the more specific styles of any ancestors.

The highlight would be blue over “very important information”
because the <strong> element´s ::selection also matches the ::selection { background: blue; } rule.
(Remember that * is implied when a tag selector is missing.)
The style rules that would give the intended behavior
(red highlight within p.warning, blue elsewhere) are

Note: This paired-cascading behavior
does not allow using the normal cascade
(i.g. :root::selection rules in the UA style sheet)
to represent the OS default selection colors.
However it has been interoperably implemented in browsers
and is thus probably a Web-compatibility requirement.

A highlight pseudo-element also suppresses the drawing of any selected text
(and any text decorations applied to that text).
Instead the topmost active highlight overlay redraws that text
(and its decorations)
over the highlight overlay backgrounds
using its own color,
with currentColor on its color property representing the color of the next highlight pseudo-element layer below,
falling back finally to that of the originating element (the colors that would otherwise be used).
Any text decorations introduced by each highlight pseudo-element are stacked in the same order as their backgrounds
over the text’s original decorations
and are all drawn, in their own colors.

What should happen with text shadows?
Drawing them in their original color is disconcerting if that color is not a shade of gray.
Maybe if the overlay has a background, suppress any text shadows below it?

For non-replaced content, the UA must honor the color and background-color (including their alpha channels) as specified.
However, for replaced content, the UA should create a semi-transparent wash
to coat the content so that it can show through the selection.
This wash should be of the specified background-color if that is not transparent,
else of the specified color;
however the UA may adjust the alpha channel.

3.6. Security and Privacy Considerations

Because the styling of spelling and grammar errors
can leak information about the contents of a user’s dictionary
(which can include the user’s name and even includes the contents of his/her address book!)
UAs that implement ::spelling-error and ::grammar-error must prevent pages from being able to read
the styling of such highlighted segments.

When their computed content value is not none,
these pseudo-elements generate boxes
as if they were immediate children of their originating element,
and can be styled exactly like any normal document-sourced element in the document tree.

For example, the following rule inserts the string “Note: ”
before the content of every <p> element
whose class attribute has the value note:

p.note::before {content:"Note: "}

Since the initial value of display is inline,
this will generate an inline box.
Like other inline children of <p>,
it will participate in <p>’s inline formatting context,
potentially sharing a line with other content.

The ::placeholder pseudo-element represents
placeholder text in an input field:
text that represents the input
and provides a hint to the user on how to fill out the form.
For example, a date-input field
might have the placeholder text “YYYY/MM/DD”
to clarify that numeric dates are to be entered in year-month-day order.

Note: There also exists a :placeholder-shown pseudo-class,
which applies to (real) elements while they are showing placeholder text,
and can be used to style such elements specially. ::placeholder specifically selects
a pseudo-element representing the placeholder text,
and is thus relatively limited in its abilities.

In interactive media, placeholder text is often hidden once the user has entered input;
however this is not a requirement, and both the input value and the placeholder text may be visible simultaneously.
The exact behavior is UA-defined.
Note that in static media (such as print)
placeholder text will be present even after the user has entered input.

Note: It’s been requested that ::placeholder also refer to
a placeholder which has a corresponding element in the element tree.
It’s not clear how this should work, but it may be worth doing.
See Issue 2417.

5. Overlapping Pseudo-element Interactions

Recall that

the contents of ::before and ::after are selected
exactly as if they were normal elements in the document source tree

the ::first-letter boundaries are tightly wrapped around the first letter text,
and ::first-letter is constrained to exist solely on the first formatted line.

the ::first-line start is inserted just inside the containing block’s element boundary,
and its end after the close of all content on the line

The following CSS and HTML example
illustrates how overlapping pseudo-elements interact:

Note: This interface may be extended in the future
to other pseudo-element types
and/or to allow setting style information
through a CSSStyleDeclarationstyle attribute.
The current functionality is limited
to that which is needed to support [web-animations-1].

The pseudo(CSSOMString type) method
is used to retrieve the CSSPseudoElement instance
created by the element of the type matching type.
Its return value is a CSSPseudoElement,
potentially null if no such pseudo-element exists.

Pseudo-elements of unsupported types are considered to simply not exist;
unrecognized type values are not an error.

The identity, lifetime, and nullness of the return value
(and potential error cases)
of the pseudo() method is still under discussion.
See Issue 3607 and Issue 3603.

7. Compatibilitiy Syntax

For compatibility with existing style sheets written against CSS Level 2 [CSS21],
user agents must also accept the previous one-colon notation
(:before, :after, :first-letter, :first-line)
for the ::before, ::after, ::first-letter, and ::first-line pseudo-elements.

Acknowledgements

The editors would like to thank the following individuals for their
contributions, either during the conception of the specification or during
its development and specification review process:
Tab Atkins,
David Baron,
Razvan Caliman,
Chris Coyier,
Anders Grimsrud,
Vincent Hardy.

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.

Conformance classes

Conformance to this specification
is defined for three conformance classes:

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.

Requirements for Responsible Implementation of CSS

The following sections define several conformance requirements
for implementing CSS responsibly,
in a way that promotes interoperability in the present and future.

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 property 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

Implementations of CR-level Features

Once a specification reaches the Candidate Recommendation stage,
implementers should release an unprefixed implementation
of any CR-level feature they can demonstrate
to be correctly implemented according to spec,
and should avoid exposing a prefixed variant of that feature.

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.

Issues Index

Not sure if this is the correct way of describing the way things work. ↵

What should happen with text shadows?
Drawing them in their original color is disconcerting if that color is not a shade of gray.
Maybe if the overlay has a background, suppress any text shadows below it? ↵