- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 06 May 2026 16:49:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-pseudo] Geometry methods for CSSPseudoElement`. <details><summary>The full IRC log of that discussion</summary> <ydaniv> sakhapov: this proposal is about supporting something like gBR for this that it allows some useful use-cases<br> <ydaniv> astearns: only for tree-abiding pseudo elements?<br> <ydaniv> sakhapov: yes<br> <ydaniv> ... there's a discussion about the rest about for future<br> <astearns> ack fantasai<br> <ydaniv> fantasai: when the style position is outside we don't know some stuff, ...<br> <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.<br> <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?<br> <ydaniv> fantasai: we should make it only applyable to stylable pseudo-elements<br> <ydaniv> sakhapov: yes we could some with some hierarchy of elements that support it<br> <ydaniv> iank_: does CSSPseudoElements work like :first-line? or not?<br> <ydaniv> sakhapov: currently not, is it tree-abiding?<br> <ydaniv> ... last week we agreed to support tree-abiding<br> <ydaniv> fantasai: do we want to change that resolution and make it full-stylable? or only tree-abiding?<br> <ydaniv> sakhapov: markers should probably be preserved, you can click your marker to know if it's been clicked<br> <ydaniv> fantasai: but if we don't know where the boundry of the marker is how do we know that?<br> <ydaniv> sakhapov: good question<br> <ydaniv> fantasai: the layout of marker has less compat issues, so maybe safe<br> <fantasai> s/layout/hit testing/<br> <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<br> <ydaniv> ... naively a separate interface is more ergonomic<br> <flackr> +1 that's my intuition as well<br> <astearns> s/a sepatate/a single/<br> <ydaniv> fantasai: some not-fully-stylable elements may be in the future,<br> <kbabbitt> think I agree with one interface across all pseudos as well<br> <ydaniv> ... it would be good not to use JS for those cases<br> <ydaniv> ... is there a way for gBCR to know someting like that?<br> <kbabbitt> q+<br> <ydaniv> sakhapov: currently it retun a list, we could return an empty list?<br> <astearns> ack kbabbitt<br> <ydaniv> kbabbitt: what does gBCR returns for [missed]?<br> <kbabbitt> s/[missed]/an element that's display:none/<br> <kbabbitt> (looking for a precedent)<br> <smfr> looks like it returns an empty rectangle<br> <ydaniv> flackr: looks like CH returns 0x0<br> <ydaniv> ... not ideal, but it's a precedent<br> <ydaniv> sakhapov: we could first discuss some tree hierarchy before?<br> <flackr> q+<br> <astearns> ack flackr<br> <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<br> <ydaniv> flackr: would be nice have a single interface, and when run into some property that doesn't fit we could specialize that case<br> <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?<br> <ydaniv> sakhapov: sounds good<br> <ydaniv> astearns: seems more clear to me to have a single interface that may work differently depending on the element<br> <ydaniv> ... better than a hierarchy of interfaces of elements with longer and longer names that try to disambiguate that stuff<br> <weinig> q+<br> <ydaniv> astearns: agree, so let's say there's a common interface<br> <ydaniv> s/astearns/sakhapov<br> <astearns> ack weinig<br> <ydaniv> weinig: wanna challange the idea of hierarchy as bad idea<br> <ydaniv> ... when things mistirously work or not it's challanging<br> <ydaniv> ... and if you want to detect what's not working, it's challange, like when something is falsy<br> <ydaniv> astearns: so let's continue on whether we want a single interface or hierarchy<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12373#issuecomment-4390215286 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 May 2026 16:49:40 UTC