- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 08 Oct 2025 16:23:05 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom-view-1] offsetParent spec says that we return elements from open shadow trees, no browser does.`, and agreed to the following: * `RESOLVED: Make offsetParent spec match reality` * `ACTION: flackr to open issue on making scrollParent a function` * `ACTION: dbaron to open an issue on replacements for offsetParent` <details><summary>The full IRC log of that discussion</summary> <fantasai> scribe+<br> <lea> q?<br> <emilio> flackr: As I was implementing scrollParent I discovered that the spec for offsetParent claims we should expose elements within open shadow trees yet no impl does that<br> <lea> q+<br> <emilio> ... I'd like to resolve to change it to match implementations and do the same for scrollParent<br> <emilio> q+<br> <astearns> ack lea<br> <emilio> lea: is there a reason for what browsers do?<br> <lea> q+<br> <fantasai> emilio: implementation-wise it's the same, but I don't think any DOM API distinguishes between both<br> <fantasai> emilio: DOM event targetting etc. works the same in open vs closed shadow root<br> <masonf> +1<br> <fantasai> emilio: So I think it's best to not differentiate here either<br> <fantasai> emilio: for APIs where you might want to get things from shadow roots, we've added option to pass shadow roots to have access to<br> <fantasai> emilio: that way you can access both closed and open shadow roots depending on what you have access to<br> <emilio> lea: what do they actually return?<br> <astearns> ack lea<br> <emilio> ... do they return the host or do they skip that element?<br> <emilio> flackr: they skip to the shadow host but it might traverse further up if the shadow host doesn't meet the requirements<br> <emilio> lea: the current behavior seems more useful<br> <emilio> ... wondering if we could also add a corresponding property that does the right thing<br> <emilio> q+<br> <oriol> q+<br> <astearns> ack emilio<br> <astearns> ack oriol<br> <fantasai> emilio: Could add an argument to do it consistently in the DOM, but I don't think it should be specific to offsetParent APIs<br> <flackr> +1<br> <lea> s/lea: the current behavior seems more useful/lea: the current behavior seems more useful, but I also understand the web compat argument of speccing what browsers already do/<br> <emilio> oriol: I think scrollParent should be a function to allow eventual extensions?<br> <astearns> ack dbaron<br> <lea> +1 oriol<br> <emilio> dbaron: I think we should be looking at offset* as a legacy API<br> <emilio> ... I think the implementation of these existed well before the spec did<br> <emilio> ... in general we want to bias towards specifying what's implemented<br> <emilio> ... to some degree we have various APIs that are trying to replace them<br> <emilio> ... some of that is implemented like getBoundingClientRect and other pieces in the geometry spec?<br> <masonf> examples: innerHTML --> getHTML(), getRangeAt() --> getComposedRanges(), etc.<br> <emilio> ... not sure what the state of all of them are?<br> <lea> q?<br> <lea> q+<br> <emilio> ... I would not try and improve offset*<br> <emilio> ... I'd try and build the API we want more generally<br> <astearns> ack lea<br> <emilio> q+<br> <emilio> lea: I agree these are weird and fine to treat them as legacy<br> <emilio> ... but not sure what'd be the replacement<br> <emilio> ... is there an API that could replace them today?<br> <astearns> ack emilio<br> <fantasai> emilio: [missed]<br> <fantasai> emilio: The consistent thing to do is to not distinguish between open and closed shadow roots<br> <lea> many scripts were written before shadows were a thing and use these properties for positioning and ideally should not break too badly when dropped into a page that has shadow roots<br> <masonf> q+<br> <fantasai> emilio: We can decide to use a function for scoped parent or add a new function for passing list of shadow roots or whatever<br> <astearns> s/[missed]/yes these things were implemented before being specced, but shadow root came after the spec<br> <fantasai> emilio: but big +1 to spec what's implemented for offsetParent because it's the right thing to do<br> <astearns> ack masonf<br> <Kurt> +1 emilio<br> <fantasai> emilio: consistent with the way it works elsewhere in DOM<br> <lea> q?<br> <lea> q+<br> <emilio> masonf: I commented with some precedent on the DOM side (innerHTML / getHTML() / etc)<br> <astearns> ack lea<br> <emilio> ... not a technical issue, just a consistency argument<br> <emilio> lea: Fine to spec what's implemented, but we should work to close the gap because there's no way of doing what the spec says<br> <emilio> dbaron: yeah it'd be good to have some element-to-element coord space conversion<br> <emilio> PROPOSED: Fix offsetParent by spec-ing reality, but work into a way to opt into looking into shadow roots<br> <emilio> q+<br> <kbabbitt> +1<br> <lea> (though hopefully anchor positioning renders many of the use cases for these properties obsolete)<br> <masonf> +1<br> <lea> +1<br> <astearns> ack emilio<br> <fantasai> emilio: We should definitely update offsetParent.<br> <oriol> It's implemented in Blink and Servo<br> <fantasai> emilio: scrollParent is not implemented anywhere, so maybe we can make it functional already<br> <fantasai> flackr: We have an implementation, but not shipped yet<br> <fantasai> emilio: fair<br> <emilio> RESOLVED: Make offsetParent spec match reality<br> <dbaron> I think some of what I'm thinking of was for a time in a GeometryUtils interface in https://drafts.fxtf.org/geometry/#geometryutils<br> <emilio> astearns: if we make scrollParent a function we can allow passing a list of shadow roots<br> <emilio> flackr: I see<br> <emilio> astearns: we should file an issue for that<br> <fantasai> ACTION: flackr to open issue on making scrollParent a function<br> <emilio> astearns: we should look into whether appropriate replacements for offsetParent exist<br> <fantasai> ACTION: dbaron to open an issue on replacements for offsetParent<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12392#issuecomment-3382322405 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 October 2025 16:23:06 UTC