- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 03 Apr 2025 20:22:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Support Cross-Origin iframe use case`, and agreed to the following: * `RESOLVED: View timelines whose subject is the root element are always inactive (with the expectation we'll give them more behavior later)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: with view timelines, you can create an effect when the subject is visible within its nearest ancestor scroller<br> <TabAtkins> flackr: but in some of the use-cases with our partners, they wanted to do something like intersection observer, where it was looking at its frames' visibility in the outer frame. view-timeline doesn't let you do that<br> <TabAtkins> flackr: so should it? a view-timeline based on your frame root, giving you the intersection with your embedding frame<br> <fantasai> TabAtkins: simple example, you haven iframe<br> <fantasai> TabAtkins: It wants to run a view-timeline-animation based on the iframe's position in the outer page<br> <fantasai> TabAtkins: relative to the scroller its in<br> <TabAtkins> fantasai: so basically passing the timeline from outside the iframe into the iframe<br> <TabAtkins> flackr: this can be cross-origin, so it's not striclty passing "objects"<br> <TabAtkins> flackr: you are allowed to know when you're intersecting the viewport, via IntersectionObserve33r<br> <TabAtkins> flackr: maybe we don't want to allow it since it does technically expose more info than IO, at least a single IO<br> <TabAtkins> flackr: but you can get this information to some granularity by creating several IOs with different offsets<br> <TabAtkins> fantasai: i can't comment from a security perspective<br> <TabAtkins> fantasai: from how to do it, maybe say view timelines on the root element are about the root's position in the outer scroller<br> <TabAtkins> flackr: yeah, that's my thought<br> <TabAtkins> flackr: if your subject is the root you're observing its psoiition in an outer frame's scroller<br> <TabAtkins> flackr: but we'd still ahve to figure out if it's okay from a security perspective<br> <TabAtkins> astearns: so rob's proposal in the issue is to punt for now<br> <TabAtkins> fantasai: if we think we want to do this, we might want to define that a view-timeline on the root has no effect<br> <TabAtkins> fantasai: bc in theory you could define a root element with lots of margins and padding and observe its transit across the viewport<br> <TabAtkins> fantasai: suspect not used<br> <TabAtkins> flackr: yeah, if you have a root subject and "contain", it's using the root's scroll timeline basically<br> <TabAtkins> (i think i got that right)<br> <TabAtkins> flackr: but i'd be supportive of reserving this, today you'd get a timeline that's always inactive<br> <TabAtkins> TabAtkins: so do the reservation now, punt the feature to after security review<br> <TabAtkins> fantasai: proposed: view timelines defined on the root element are always inactive<br> <TabAtkins> flackr: whose subject is the root element<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: View timelines whose subject is the root element are always inactive (with the expectation we'll give them more behavior later)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4344#issuecomment-2776836246 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 3 April 2025 20:22:50 UTC