Skip to content

[css-pseudo][css-highlight-api] Highlight painting over replaced elements #14108

Description

@ffiori

Summary

css-pseudo-4 defines how highlights treat replaced content generically, both the overlay's area (§3.4 Area of a Highlight) and its painting as a semi-transparent wash (§3.6 → Replaced Elements), but it never says which replaced boxes qualify. So when a highlight is painted over replaced elements, it's unclear whether "replaced content" means every replaced box, or the narrower set that ::selection is typically painted over. This affects all
highlight pseudo-elements (::selection, ::target-text, ::highlight(), etc.).

Two questions follow: (1) which replaced boxes are covered, and (2) whether the §3.6 wash rule (written for the UA's ::selection) is the right painting model for author-controlled ::highlight(), which specifies background-color directly.

What the spec says today

§3.4:

Each box owns the piece of the overlay corresponding to any text or replaced
content
directly contained by the box.
[…]

  • 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.

And §3.6 → Replaced Elements says how that overlay is painted onto replaced content:

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.

Both clauses are written generically for all highlight pseudo-elements and neither restricts which replaced boxes are covered.

css-highlight-api-1 §4.2.4 Painting defers entirely to the css-pseudo-4 painting model, so whatever is decided here also governs custom ::highlight().

Question 1 — which replaced boxes are covered?

The spec says 'replaced content' without narrowing which replaced elements it means, so it reads as applying to all of them. In practice not every replaced box seems like it should receive a highlight tint.

Proposal: It seems desirable to mirror the set of replaced boxes that UAs already paint ::selection over, and therefore to exclude replaced boxes that paint their own contents, e.g.:

  • <canvas> and the root of an inline <svg> (replaced, but scripted/structured content that ::selection does not tint),
  • <video> rendering UA controls, and
  • <object> rendering fallback content.

Concretely:

<style>::highlight(h){ background:rgba(200,0,0,.5); }</style>
<img id="img">      <!-- should be tinted -->
<canvas id="c"></canvas>  <!-- should NOT be tinted? -->
<script>
  const r = new StaticRange({startContainer:document.body,startOffset:0,
                             endContainer:document.body,endOffset:2});
  CSS.highlights.set("h", new Highlight(r));
</script>
  1. Is the intended reading of "replaced content" (in both §3.4 and §3.6) the same
    set of replaced boxes that ::selection is painted over? Note the spec doesn't
    define that set either, "replaced content" is used uniformly, with no
    carve-outs, so which replaced boxes are covered is currently UA-defined.
  2. Should the spec state more precisely which replaced boxes are and are not
    covered, so it's interoperable?

Question 2 — does the §3.6 "wash" rule fit custom highlights?

§3.6 reads as a ::selection-oriented UA default: for the UA's own selection highlight, the UA coats replaced content with a semi-transparent wash (and "may adjust the alpha channel") so the content shows through, using the specified color when background-color is transparent.

For author-controlled ::highlight(), the author specifies background-color (and its alpha) directly, so the wash model is awkward:

  • Alpha: "the UA may adjust the alpha channel" would override the author's chosen opacity. For custom highlights the specified alpha should presumably be honored, e.g. background-color: rgba(200,0,0,.5) paints at 0.5.
  • color fallback: tinting a replaced element with the highlight's color when no background-color is set is surprising, "no background-color, no tint" seems more natural.
  • Wording: the rule is phrased in terms of "the selection".

Because css-highlight-api-1 §4.2.4 defers wholesale to this painting model, it's unclear whether custom highlights are meant to follow the wash rule or to paint the author-specified background-color as given. Painting the specified background-color directly seems preferable for ::highlight().

Proposed resolutions

  • Which boxes: the painted set is text plus the replaced boxes that UAs paint ::selection over (e.g. images and embedded content, but not <canvas>, SVG roots, <video> with controls, or <object> fallback).
  • How: treat the §3.6 wash (UA alpha adjustment, color fallback) as a ::selection UA default, and have ::highlight() paint its specified background-color directly, honoring the author's alpha, with no color fallback and no tint when transparent.

Feedback welcome on whether those are the right proposals.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions