- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Jan 2025 16:47:58 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-5] Can we relax size containment on ::scroll-marker-group?`, and agreed to the following: * `RESOLVED: ::scroll-marker-group applies containment when it is in-flow only` <details><summary>The full IRC log of that discussion</summary> <andreubotella> flackr: the :scroll-marker-group pseudoclass is spec'd to have size containment to avoid cycles in the number of established scroll markers<br> <andreubotella> flackr: but that's a common pitfall for authors, since if they forget to set an explicit size, it doesn't behave as expected<br> <andreubotella> flackr: can we relax that?<br> <andreubotella> flackr: the common case, you are making a target group out of (...) and the size doesn't affect the scroll container<br> <emilio> q+<br> <andreubotella> flackr: can we make the containment conditional on whether it's out-of-flow positioned?<br> <andreubotella> florian: I don't have an issue, the whole point of containment is to make it easier to reason about this, and this doesn't make it easier<br> <andreubotella> florian: I'm not familiar enough, but don't you need layout containment as well?<br> <andreubotella> flackr: you need it to not affect the size of the container<br> <andreubotella> florian: if its size doesn't change but it's not an IFC and you have a float poking out of it, and the float's size changes, it could jumble the content around it<br> <andreubotella> florian: so i suspect you also need layout containment<br> <andreubotella> florian: making size (and possibly layout) containment conditional on out-of-flow sounds good to me<br> <andreubotella> florian: but even if your position not changing is fine, is it a problem if your content scrolls too far and causes scrollbars to appear?<br> <andreubotella> flackr: not a problem, once scrollbars appear we don't remove them<br> <andreubotella> florian: you could have subtle interactions that break what you thought was a guarantee<br> <astearns> ack emilio<br> <astearns> q+ astearns<br> <andreubotella> emilio: what's the use case for getting them in flow? if 99% of use cases require them to be out of flow, shouldn't we always have containment?<br> <andreubotella> flackr: you need it to be in-flow if you want to put your scroll marker group in a grid area, and have it have the correct size, which is relatively common<br> <andreubotella> flackr: i could see leaving that as an open question<br> <andreubotella> flackr: maybe resolve to do this switch, but consider if there are legitimate use cases for in-flow position<br> <andreubotella> emilio: we can do this magic to force containment if not abpos, and contain is already a magic property with interactions<br> <andreubotella> astearns: if the problem is that the size containment is unexpected for authors, then having it be unexpected only in abspos makes the problem worse<br> <astearns> ack astearns<br> <andreubotella> florian: but for in-flow, it's unexpected and unnecessary<br> <andreubotella> PROPOSED RESOLUTION: scroll-marker-group applies containment when it is in-flow only<br> <andreubotella> RESOLVED: ::scroll-marker-group applies containment when it is in-flow only<br> <andreubotella> astearns: as for whether we also need layout containment, we'll have another issue if that is a problem<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11166#issuecomment-2607753417 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 January 2025 16:47:59 UTC