Repository navigation
[css-pseudo] Geometry methods for CSSPseudoElement #12373
Description
Not an issue, but rather a discussion about support for geometry methods (e.g. getBoundingClientRect()) for CSSPseudoElement?
One use case is an ability to getBoundingClientRect() for old and new view transitions and do something about it.
Activity
bramus commentedon Jun 20, 2025
I’d definitely be in favor of adding
getBoundingClientRecttoCSSPseudoElement. This would also be useful for (tree-abiding) pseudos such as the carousel or the view-transitions pseudos.In #11559 I listed the following:
As for use-cases: for VTs specifically this would unlock building retargettable (~interruptible) VTs in userland. In this CodePen I have such a POC: Because I cannot know where the subject is mid-VT, I need to run an animation on a cloned (real) element in parallel and do a
getBoundingClientRecton that clone. IfgetBoundingClientRectwere available onCSSPseudoElementI would not need all that orchestration.css-meeting-bot commentedon May 6, 2026
The CSS Working Group just discussed
[css-pseudo] Geometry methods for CSSPseudoElement.The full IRC log of that discussion
<ydaniv> sakhapov: this proposal is about supporting something like gBR for this that it allows some useful use-cases<ydaniv> astearns: only for tree-abiding pseudo elements?
<ydaniv> sakhapov: yes
<ydaniv> ... there's a discussion about the rest about for future
<astearns> ack fantasai
<ydaniv> fantasai: when the style position is outside we don't know some stuff, ...
<fantasai> We don't know the bounds of ::marker when it is list-style-position: outside, because its layout is not yet well-defined. THat's why you can't have backgrounds on it.
<ydaniv> astearns: the marker does have this CSSPseuodoElement available, but in this case we want to be able to show the rect and return null?
<ydaniv> fantasai: we should make it only applyable to stylable pseudo-elements
<ydaniv> sakhapov: yes we could some with some hierarchy of elements that support it
<ydaniv> iank_: does CSSPseudoElements work like :first-line? or not?
<ydaniv> sakhapov: currently not, is it tree-abiding?
<ydaniv> ... last week we agreed to support tree-abiding
<ydaniv> fantasai: do we want to change that resolution and make it full-stylable? or only tree-abiding?
<ydaniv> sakhapov: markers should probably be preserved, you can click your marker to know if it's been clicked
<ydaniv> fantasai: but if we don't know where the boundry of the marker is how do we know that?
<ydaniv> sakhapov: good question
<ydaniv> fantasai: the layout of marker has less compat issues, so maybe safe
<fantasai> s/layout/hit testing/
<ydaniv> astearns: my question is where we make the distinction between these elements? do we have separate interfaces for each category? or do we have a single CSSPseudoElements which does different thing for each element
<ydaniv> ... naively a separate interface is more ergonomic
<flackr> +1 that's my intuition as well
<astearns> s/a sepatate/a single/
<ydaniv> fantasai: some not-fully-stylable elements may be in the future,
<kbabbitt> think I agree with one interface across all pseudos as well
<ydaniv> ... it would be good not to use JS for those cases
<ydaniv> ... is there a way for gBCR to know someting like that?
<kbabbitt> q+
<ydaniv> sakhapov: currently it retun a list, we could return an empty list?
<astearns> ack kbabbitt
<ydaniv> kbabbitt: what does gBCR returns for [missed]?
<kbabbitt> s/[missed]/an element that's display:none/
<kbabbitt> (looking for a precedent)
<smfr> looks like it returns an empty rectangle
<ydaniv> flackr: looks like CH returns 0x0
<ydaniv> ... not ideal, but it's a precedent
<ydaniv> sakhapov: we could first discuss some tree hierarchy before?
<flackr> q+
<astearns> ack flackr
<ydaniv> astearns: we could resolve we have a single interface and resolve to different types in different cases, so that geometry would return something for fully-stylable and something else for not
<ydaniv> flackr: would be nice have a single interface, and when run into some property that doesn't fit we could specialize that case
<ydaniv> astearns: shall we leave this here with intent to have a single interface? and list out the rest of the geometry method for pseudo elements?
<ydaniv> sakhapov: sounds good
<ydaniv> astearns: seems more clear to me to have a single interface that may work differently depending on the element
<ydaniv> ... better than a hierarchy of interfaces of elements with longer and longer names that try to disambiguate that stuff
<weinig> q+
<ydaniv> astearns: agree, so let's say there's a common interface
<ydaniv> s/astearns/sakhapov
<astearns> ack weinig
<ydaniv> weinig: wanna challange the idea of hierarchy as bad idea
<ydaniv> ... when things mistirously work or not it's challanging
<ydaniv> ... and if you want to detect what's not working, it's challange, like when something is falsy
<ydaniv> astearns: so let's continue on whether we want a single interface or hierarchy