- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Aug 2021 16:27:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `overflow-clip-margin + border-radius continuity`, and agreed to the following: * `RESOLVED: overflow-clip-margin uses the same corner-adjustment formula as margin/etc` * `RESOLVED: Accept dbaron's editorial feedback about making the "accidental" case more explicit.` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: overflow-clip-margin + border-radius continuity<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5896#issuecomment-892995385<br> <TabAtkins> ScribeNick: TabAtkins<br> <TabAtkins> fantasai: I think dbaron's comments are mostly editorial<br> <TabAtkins> fantasai: So I'll ask the main question<br> <TabAtkins> fantasai: Do we want to accept that the overflow-clip-margin follows the same corner-adjustment rules as margin/border/padding edges (so pointy corners stay pointy, round corners stay round)<br> <TabAtkins> fantasai: When you have a curved border edge, and we calculate the equivalent padding or content-box edges, we subtract the border/padding widths, flooring at zero.<br> <TabAtkins> fantasai: Similarly when you're going out to the margin edge or box shadows, we *add* the margin/shadow size to the radius, but with a special adjustment that keeps zero radius at zero.<br> <TabAtkins> fantasai: Some math keeps it continuous between the two cases without causing noticeable changes in most cases<br> <TabAtkins> dbaron[m]: Another complexity is that a corner might be an inset on one side and outset on the other. already possible with negativemargins<br> <TabAtkins> dbaron[m]: This probably makes that case more common, since it's an offset from the padding edge<br> <fantasai> https://drafts.csswg.org/css-backgrounds-3/#corner-shaping<br> <TabAtkins> dbaron[m]: I think the spec actually does something reasonble for this right now, but it's by accident. I think it's right, tho<br> <fantasai> https://drafts.csswg.org/css-backgrounds-3/spread-radius<br> <TabAtkins> dbaron[m]: It probably should look more intentional to make sure impls think about that case<br> <TabAtkins> fantasai: I just posted the testcase we used when we were figuring out the continuity formula<br> <TabAtkins> fantasai: So proposal is to use the same formula for overflow-clip-margin<br> <TabAtkins> astearns: Any othe ropinions?<br> <TabAtkins> [no objections]<br> <TabAtkins> RESOLVED: overflow-clip-margin uses the same corner-adjustment formula as margin/etc<br> <TabAtkins> astearns: Should we also resolve about being more clear about the positive-and-negative margin case?<br> <TabAtkins> fantasai: sure<br> <TabAtkins> astearns: So proposal is to accept dbaron's feedback, making the "accidental" correctness more explicit.<br> <TabAtkins> RESOLVED: Accept dbaron's editorial feedback about making the "accidental" case more explicit.<br> <TabAtkins> dbaron[m]: I don't think there's more to discuss, but I did raise more substantive editorial issues that I think could confused implementors.<br> <TabAtkins> dbaron[m]: Do think we need to deal with those, but don't think we need group time for them.<br> <TabAtkins> astearns: So fantasai you'll go thru those and either ipmlement or bring back to the group if necessary?<br> <fantasai> yes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5896#issuecomment-901254956 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 August 2021 16:27:42 UTC