- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 13 Aug 2025 16:26:07 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[cssom-view] `getClientRects()` should return a flattened list of child rects for `display: contents` ``. <details><summary>The full IRC log of that discussion</summary> <JoshT> florian: if you ask getClientRect on display: content, it returns nothng<br> <JoshT> ... if you return the pieces of it, that would be more useful<br> <oriol> q+<br> <JoshT> ... this is likely to be a breaking change. are we OK with breaking compat?<br> <astearns> ack oriol<br> <bkardell> it would be good to answer Oriol's questions in the issue<br> <JoshT> oriol: I'm not opposing. but was explaining in last comment, not sure if we should wait for Lea to defend proposal, but I can explain my reasoning<br> <JoshT> astearns: is your concern about the way it is to be resolved or the use case in general?<br> <JoshT> oriol: there are specific values where they can all be valid and it's not clear how we would do it regardless of the method. some authors would want a different behaviour<br> <JoshT> ... like should we include abspos children that are out of flow<br> <JoshT> ... should we include text children. they don't have clientRects<br> <emilio> +1 oriol<br> <JoshT> ... there is a proposal to support it for pseudo elements. would they be included?<br> <JoshT> ... in general, I think it seems useful, but a can of worms!<br> <emilio> q+<br> <JoshT> ... I think it's better if authors implement exactly what they want in JS<br> <JoshT> ... if the element has display contents, then I think producing an empty value is reasonable because it has no box of its own<br> <astearns> ack emilio<br> <JoshT> emilio: +1 to oriol. we already have some APIs for selection that behave like this<br> <JoshT> ... range.getClientRect is a thing<br> <JoshT> ... that pretty much does what Lea wants I think<br> <JoshT> ... for display: contents, it doesn't produce a box so it should return empty<br> <lea> q?<br> <JoshT> ... I don't think this would be web compat<br> <JoshT> lea: what's the alternative proposal, I've just joined<br> <JoshT> astearns: for authors using JS to work out which children they want to get the rect for<br> <JoshT> lea: anchor positioning?<br> <JoshT> ... it's been a while, but this came up with certain components that need to capture native elements<br> <JoshT> ... a solution for some things is to wrap a native element<br> <JoshT> ... there are two ways to style. either not style the button in the shadow dom and consumers use custom properties for basic styling<br> <JoshT> ... Or to display: contents on the host and then authors can style the button, for example<br> <JoshT> ... authors can apply bg and borders and whatever<br> <emilio> The alternative is implement what you want. which might be `let r = new Range(); r.selectNodeContents(thing); r.getClientRects();`<br> <JoshT> ... but makes it difficult to get getClientRect to work to return a union of the children<br> <JoshT> ... that might be more what authors expect<br> <JoshT> ... but what happens today if you use anchor pos and you have getClientRect<br> <JoshT> emilio: it doesn't work<br> <JoshT> lea: and it's also defined in terms of client rect. so I'm not married to fixing getClientRect<br> <JoshT> ... but if anchor positioning doesn't work here, that's a broader problem<br> <emilio> q+<br> <JoshT> TabAtkins: the element wouldn't exist here as far as the layout tree is concerned<br> <JoshT> lea: if there was a declarative way to declare which elements make the box might work. that would help with this use case<br> <JoshT> emilio: I understand the use case of wrapping a single element and wanting it to behave as the element<br> <JoshT> ... for that, all these questions have answers<br> <lea> q+<br> <astearns> ack emilio<br> <JoshT> ... I don't think we can make this generally work without answering a lot of really hard questions around chaining behaviour of these APIs<br> <JoshT> ... maybe the answer is you don't style the component itsself and you style the parts<br> <JoshT> lea: yeah that's the other alternative<br> <astearns> ack lea<br> <JoshT> emilio: that's what works now then. but I agree it would be useful for the specific use case you outlined<br> <JoshT> lea: this makes it confusing for users using parts. there's certain things you can't do. now you have to learn a new thing: the obvious thing doesn't work<br> <JoshT> ... this feels like a theoretical purity argument<br> <JoshT> ... it doesn't generate a box on its own but the descendents do<br> <florian> q?<br> <florian> q+<br> <JoshT> ... but I'm not sure there are any use cases where you would want an empty rect<br> <JoshT> emilio: could be places where intersection observers accidentally fire if we change this<br> <JoshT> ... I understand it would be nice if things were magic and transparent. but if you have to reach into the shadow dom and style that then ???<br> <JoshT> lea: I agree it's weird but the web platform doesn't supply another way to do this<br> <florian> q-<br> <JoshT> emilio: maybe we should extend built ins. but that's not related to display: contents<br> <bkardell> there is a separate issue on what Emilio just mentioned<br> <JoshT> astearns: we should take this back to the issue, but should have a new issue for display: contents on anchor positioning<br> <JoshT> TabAtkins: maybe we could but I'd like it to be consistent with something else on the web platform<br> <JoshT> lea: we could add a dom method that gets you the union of all these<br> <JoshT> emilio: the range API already exposes this. I don't think it's great, but it's already exposed<br> <JoshT> lea: are you suggested this is precident we could look at or we could already use range?<br> <JoshT> emilio: I don't think it would be what you want generally because it only works on a flat tree, but for most use cases it should work<br> <JoshT> ... as oriol said, there are many bounding boxes that could work here<br> <JoshT> ... so I don't see this working in a general way that is useful enough but maybe that's me<br> <JoshT> lea: I agree but think anything we do is more useful than the current situation<br> <JoshT> astearns: let's take it back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12040#issuecomment-3184600188 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 August 2025 16:26:08 UTC