- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Mar 2026 17:45:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui-3] Check edits since publication as REC`, and agreed to the following: * `RESOLVED: Keep edits that makes resize apply to scroll containers` * `RESOLVED: Remove the comment` * `RESOLVED: Keep spec as-is, outline-width snaps like border-width` <details><summary>The full IRC log of that discussion</summary> <emilio> florian: was reviewing [css-ui-3] since it was published as REC<br> <emilio> ... couple commits without resolution<br> <emilio> ... so let's either accept or revisit it<br> <emilio> ... issue has the comments, let's take them 1 by 1<br> <emilio> ... first one is effectively editorial<br> <emilio> https://github.com/w3c/csswg-drafts/commit/8f5f6832b2206001a271021bc294a317dc054509<br> <emilio> florian: we used to have applies to overflow != visible and was changed to scroll container<br> <emilio> ... same for the other<br> <emilio> q+<br> <emilio> ... safari allows resizing elements with overflow: clip<br> <Rossen> ack emilio<br> <emilio> emilio: I think this text probably predates overflow: clip<br> <emilio> ... so the intention was probably to use scroll containers<br> <emilio> ... slight preference to keep spec as is<br> <flackr> +1<br> <emilio> ... I'd be surprised if safari allowed resizing replaced elements with overflow: clip etc<br> <emilio> smfr: I don't recall if that was a deliberate impl decision<br> <emilio> ... seems fine for webkit to follow the other browsers<br> <fantasai> +1, makes sense to restrict to [=scroll containers=]<br> <emilio> PROPOSED: Keep edits that makes resize apply to scroll containers<br> <emilio> RESOLVED: Keep edits that makes resize apply to scroll containers<br> <Rossen> Applies to: 8f5f683<br> <emilio> https://github.com/w3c/csswg-drafts/commit/29b1dae509aa2e2690b8f8a36810e0bc4a0bc246<br> <emilio> florian: this one goes the other way, commented out piece of text<br> <emilio> ... spec says that text-overflow applies to an overflow value != visible<br> <emilio> ... there's a comment that says overflow: clip should not be included<br> <emilio> ... but browsers disagree<br> <emilio> ... they agree with the actual spec text<br> <emilio> dbaron: Given the situation that's probably the right way to go<br> <emilio> ... my memory of the design of overflow: clip was that it was meant to be a visual rather than layout effect<br> <emilio> ... this makes it a layout effect<br> <emilio> q+<br> <emilio> ... is this the only thing that makes it a layout effect?<br> <emilio> ... or did we mess up in other places<br> <Rossen> ack emilio<br> <Rossen> ack dbaron<br> <fantasai> scribe+<br> <fantasai> emilio: I think if this works in Gecko, it's mostly because text-overflow is implemented as a visual effect, which is wrong in some ways<br> <fantasai> emilio: Like it doesn't deal well with breaking between ligatures<br> <fantasai> emilio: So I think I agree with dbaron<br> <fantasai> emilio: I'm surprised we handle clip, actually<br> <dbaron> (though it's also possible I'm misremembering how text-overflow works)<br> <fantasai> florian: Don't care either way, just want us to be clear on what we're doing<br> <fantasai> Rossen: Do we need more time on this one? If the intent was visual and reality is it's layout.<br> <fantasai> emilio: I'd like to check history a little better. But wouldn't disagree with speccing reality.<br> <fantasai> florian: Maybe let's reconfirm how it's specced, and open a new issue later<br> <fantasai> florian: For now the implementations and the spec all agree.<br> <fantasai> florian: Inclined to keep that agreement unless there's an issue.<br> <fantasai> emilio: OK with resolving. Just checked the code. We probably support it accidentally since forever<br> <fantasai> "Ellipsing only affects rendering and must not affect layout nor dispatching of pointer events:" -- spec<br> <fantasai> emilio: So let's resolve on current spec text.<br> <fantasai> dbaron: I'm ok also. Rereading it, and it does seem to be defined as a paint-time effect.<br> <fantasai> dbaron: I know we went back and forth on it.<br> <fantasai> emilio: Surprising, but ok.<br> <emilio> PROPOSED: Remove the comment<br> <emilio> RESOLVED: Remove the comment<br> <emilio> https://github.com/w3c/csswg-drafts/commit/29b1dae509aa2e2690b8f8a36810e0bc4a0bc246<br> <emilio> florian: we had a resolution for introducing things being snapped as border-width<br> <emilio> ... didn't find a resolution for outline-width<br> <emilio> ... I think it's good but if there's no resolution we should resolve<br> <dbaron> +1 to applying this to outline-width<br> <emilio> +1<br> <kbabbitt> +1<br> <TabAtkins> +1<br> <fantasai> +1<br> <emilio> Pretty sure we resolved on doing this for column-rule-width too<br> <fantasai> Implied by https://github.com/w3c/csswg-drafts/issues/12906<br> <TabAtkins> yeah everything that uses <line-width> should do the same<br> <flackr> +1<br> <emilio> PROPOSED: Keep spec as-is, outline-width snaps like border-width<br> <emilio> RESOLVED: Keep spec as-is, outline-width snaps like border-width<br> <emilio> Rossen: do we need resolution for publications?<br> <emilio> florian: let me come back about this, will take an action item to make sure we're in the right spot<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13019#issuecomment-3999133553 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 March 2026 17:45:47 UTC