Re: [csswg-drafts] [css-overflow-4] overflow-clip-margin's omitted default box (#13185)

The CSS Working Group just discussed `[css-overflow-4] overflow-clip-margin's omitted default box`, and agreed to the following:

* `RESOLVED: we spec what has been implemented for overflow-clip-margin, but open to creating a value if avoiding the issue is warranted`

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> emilio: overflow clip margin as a weird default value that cahnges whether it's a replaced element or not<br>
&lt;ydaniv> ... basically all browsers that shipped this, change the UA stylesheet that on replaced elements default to content-box<br>
&lt;ydaniv> ... I know it was intentional, I think it was done for compat reasons, and we got away with implementing something simpler, so maybe we should spec that<br>
&lt;ydaniv> astearns: seems reasonable<br>
&lt;ydaniv> emilio: this only matters if you specify OCM [missed]<br>
&lt;ydaniv> fantasai: I think we didn't know if something is replaced at style time<br>
&lt;ydaniv> emilio: yes<br>
&lt;ydaniv> fantasai: it's generated content and not captured<br>
&lt;astearns> s/[missed]/0px or initial/<br>
&lt;ydaniv> emilio: but got away with it<br>
&lt;ydaniv> astearns: so should we make this change? or we need more time to take a look at side effect of this?<br>
&lt;ydaniv> emilio: this is effectively specifying the Blink and FF behavior, so should be no risk<br>
&lt;ydaniv> ... rather do the simple thing<br>
&lt;ydaniv> astearns: if we have a value set to what we expect to be on the reaplced element, but get the fallback instead...<br>
&lt;ydaniv> emilio: the behavior that is implemented currently is that video/iframe/img have OCM: content-box, if it's not replaced it's padding-box<br>
&lt;ydaniv> ... it's definitely easier, less magic<br>
&lt;ydaniv> ... current spec is a magic value<br>
&lt;ydaniv> ... having a default of padding-box is a lot simpler, and speccing reallty makes sense if it's simple<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/7144#issuecomment-1235830910 magic proposed<br>
&lt;ydaniv> astearns: we can specify reality as suggested, and if there's a use-case for some better magic, where the UA rules are mis-applied, then we'd have a reason to go into the effort<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/7144#issuecomment-1431657225 magic resolved<br>
&lt;astearns> s/is a magic value/is a magic value but we don’t specify it/<br>
&lt;ydaniv> fantasai: added the links, should be fine to go with what we've got for now<br>
&lt;ydaniv> ... potentially clipping all texts, fine with not getting wrong clip for generated content<br>
&lt;ydaniv> PROPOSED RESOLUTION: we spec what has been implemented, but open to creating a value if avoiding the issue is warranted<br>
&lt;ydaniv> fantasai: should we consider using overflow auto so that all text gets clipped by defualt?<br>
&lt;fantasai> s/all/alt/<br>
&lt;ydaniv> astearns: I think it's not a good solution but may be a second issue<br>
&lt;ydaniv> fantasai: that was the main motivation for having a magic value<br>
&lt;ydaniv> astearns: objections that we specify OCM magic value as it's currently implemented?<br>
&lt;ydaniv> RESOLVED: we spec what has been implemented for overflow-clip-margin, but open to creating a value if avoiding the issue is warranted<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13185#issuecomment-3960591296 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 25 February 2026 16:48:25 UTC