- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 May 2025 16:52:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders-4] Consider constraining radii for concave corner-shape when opposite corners overlap`, and agreed to the following: * `RESOLVED: Reduce all radii in order to avoid overlap of shapes` <details><summary>The full IRC log of that discussion</summary> <fantasai> noamr: Right now we constrain radius when there is a corner overalp<br> <fantasai> noamr: but we don't constrain for diagonals, because these can't overlap in convex shapes<br> <fantasai> noamr: but for concave shapes they can<br> <fantasai> noamr: so question is how do we constrain these?<br> <fantasai> noamr: Right now shrinking is all corners by a ratio<br> <fantasai> noamr: enough to avoid overlap of radii<br> <fantasai> noamr: Here I'm doing the same thing. If the shapes intersect, I shrink both so that they don't touch<br> <fantasai> noamr: Here proposal is in green<br> <fantasai> noamr: Both corners shrink by same ratio, and aspect ratios ar emaintained<br> <TabAtkins> "Hull" here is defined by the tangent at the center point intersecting the horizontal/vertical?<br> <Rossen8> ack flackr<br> <Rossen8> ack fantasai<br> <TabAtkins> fantasai: [missed] all the principles that led to the original conflict formula<br> <TabAtkins> fantasai: probably want to shrink all the radiuses, not just the two intersecting<br> <TabAtkins> fantasai: [missed more]<br> <TabAtkins> q+<br> <Rossen8> ack TabAtkins<br> <fantasai> noamr: Keeps the shape, I like that<br> <fantasai> TabAtkins: but we don't do that with current case<br> <TabAtkins> TabAtkins: We don't do that for adjacent overlaps, so I"m not sure why we'd shrink everything in a diagonal overlap<br> <smfr> q+<br> <fantasai> https://www.w3.org/TR/css-backgrounds-3/#corner-overlap<br> <fantasai> fantasai: You reduce all of the radii<br> <fantasai> "When the sum of any two adjacent border radii exceeds the size of the border box, UAs must proportionally reduce the used values of all border radii until none of them overlap."<br> <fantasai> ALL radii<br> <Rossen8> ack smfr<br> <fantasai> smfr: If you have convex and concave shapes, then you have some complex constraints<br> <fantasai> smfr: how do you do that<br> <TabAtkins> I'm wrong, fantasai is right, we do shirnk all of them<br> <fantasai> noamr: First constrain adjacent ones, then constrain the opposite ones<br> <TabAtkins> https://software.hixie.ch/utilities/js/live-dom-viewer/saved/13807<br> <fantasai> smfr: Maybe that works, yeah<br> <flackr> q+<br> <Rossen8> ack flackr<br> <fantasai> flackr: another possibility would be that we don't shrink and the border becomes a straight line<br> <TabAtkins> So we should shrink all of them, and jsut use the largest necessary factor between all four adjacent pairs and two diagonal pairs<br> <smfr> q+<br> <TabAtkins> q+<br> <fantasai> noamr: wanted something consistent with adjacent borders<br> <Rossen8> ack smfr<br> <fantasai> smfr: I don't think we should, the math is already super complicated<br> <smfr> q-<br> <fantasai> TabAtkins: fantasai was right, we do shrink all of the corners if one pair is too large<br> <fantasai> TabAtkins: see demo ^<br> <Rossen8> ack TabAtkins<br> <fantasai> TabAtkins: so we should be consistent, find the shrink factors necessary for all four adjacent corners and the diagonal corners ,and just apply the largest one to all the corners<br> <TabAtkins> fantasai: the reason we did it this way was to preserve the shape as much as possible. anything else distorts the shape<br> <fantasai> PROPOSED: Reduce all radii in order to avoid overlap<br> <fantasai> RESOLVED: Reduce all radii in order to avoid overlap of shapes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12098#issuecomment-2898621830 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 May 2025 16:53:00 UTC