- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Jan 2025 18:37:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shapes-2][css-borders-4] Add a way to change an element's shape`, and agreed to the following:
* `RESOLVED: corner-shape and border-shape are independent properties`
* `RESOLVED: border-shape overrides corner-shape / border-radius`
* `RESOLVED: border-shape is a non-layout affecting property`
* `RESOLVED: default stroke width / color get taken from existing border props, specifics TBD`
<details><summary>The full IRC log of that discussion</summary>
<emilio> noamr: I can give a bit of a recap<br>
<emilio> ... we resolved at TPAC on having a draft for border-shape<br>
<emilio> ... I started working on that and discovered some questions<br>
<emilio> ... one of them is how it relates to corner-shape<br>
<emilio> ... other one is how it works with border-width etc<br>
<emilio> ... so wanted smfr to demo what he has<br>
<emilio> ... and then talk demos<br>
<emilio> smfr: [shows prototype]<br>
<emilio> ... uses border-shape with the recent `shape()` function<br>
<emilio> ... so it effectively takes over the rendering of the rounded rect<br>
<emilio> ... and replace it with effectively two shapes<br>
<emilio> ... one for the inside of the rect, one for the outside<br>
<emilio> ... actually first outside, second inside<br>
<emilio> ... it uses two different beziers, and it shows background-clip: border-area, and also box-shadow which both follow those shapes<br>
<emilio> ... the way I think about this is replacing the rendering of the radius<br>
<emilio> s/radius/border/<br>
<emilio> ... it follows the same rules regarding clipping of the content etc, just like border-radius<br>
<emilio> ... that's the two-shape version of this<br>
<emilio> ... [switches demo]<br>
<emilio> ... this one is the one-shape version, with a hole<br>
<noamr> q+<br>
<emilio> ... I think I used border-top-width for the line width<br>
<emilio> ... but single-shape has issues re. that interaction<br>
<emilio> ... a separate draft of mine just specifies effectively a stroke width<br>
<emilio> ... interpolating seems hard<br>
<emilio> ... also this is purely decorative. Affects clipping and ink overflow, but layout still uses the general box model<br>
<emilio> q+<br>
<emilio> ... what that means is that you might specify shape that allow the inside edge to project outside of the border-box<br>
<emilio> ... which exposes things like extra background area or what not which are a bit weird<br>
<TabAtkins> q+<br>
<astearns> ack noamr<br>
<emilio> ... one other thing I wanted to mention the connection between this and corner-shape is that this breaks assumptions<br>
<emilio> noamr: one of the oddities is how it interacts with border-width<br>
<emilio> ... with border-radius it kinda works<br>
<emilio> ... so that's one oddity of this<br>
<emilio> ... if your shape is kinda boxy you probably want your border-width to affect it<br>
<emilio> ... I think border-width would be a default you can override<br>
<emilio> ... same with border-color<br>
<emilio> ... my thinking was that this could behave like a mask going through the borders<br>
<noamr> https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2389134315<br>
<emilio> ... would be a simple solution but not what people would want<br>
<fserb> q+<br>
<emilio> ... I think this should be separate from corner-shape<br>
<emilio> ... we should restrict corner-shape to rectangles<br>
<emilio> ... where we can use it with border-radius<br>
<emilio> ... and this would smooth your radius rather than something that controls shape<br>
<emilio> ... would be good to separate it at least in the beginning<br>
<emilio> ... and we'd leave the interaction problems for later<br>
<bramus> emilio: i was wwondering if this corrected border matches stuff how border-image works today<br>
<bramus> … not sure how border-image and border-radius interact<br>
<bramus> … feels similar<br>
<bramus> … in the sense that b-i disregards b-w and layout<br>
<bramus> … would be good to be consistent witht hat<br>
<florian> q+<br>
<astearns> ack emilio<br>
<bramus> … can find some answers to the weird questions here<br>
<astearns> ack TabAtkins<br>
<emilio> TabAtkins: generally agree with emilio, border-image does use border-width for the area but you can override<br>
<emilio> ... we should approach this to keep this simple, the geometry should be overridden by shape, which is what simon is suggesting as well<br>
<emilio> ... supportive of not paying attention to color or width as much as possible<br>
<emilio> ... had some suggestions but not fully fledges<br>
<emilio> ... having some way of specifying variable colors along the path seems nicer than trying to interpolate based on existing border properties<br>
<schenney> +1 to Tab's color/width idea.<br>
<schenney> Interpolate between points.<br>
<emilio> smfr: sounds hard, not sure if svg has a way of changing colors along the path<br>
<emilio> ... nice suggestion<br>
<emilio> TabAtkins: what about variable width stroke?<br>
<emilio> smfr: you need to use multiple paths for that<br>
<emilio> TabAtkins: that's kind of annoying<br>
<emilio> ... quite a jump from border-radius to some two-path<br>
<schenney> q+<br>
<emilio> weinig: PostScript model is a bit old, updating it might be reasonable<br>
<RRSAgent> I have made the request to generate https://www.w3.org/2025/01/29-css-minutes.html fantasai<br>
<emilio> ... sticking just to pdfs had in late 90s got us pretty hard<br>
<emilio> ... pushing that seems reasonable<br>
<astearns> s/hard/far/<br>
<emilio> ... we can build the paths and draw new stuff<br>
<emilio> ... would just be slow<br>
<emilio> ... doesn't mean that we need to be constrained, we should be able to push that<br>
<emilio> ... we know how to do the conversion from border-radius to multiple paths<br>
<emilio> TabAtkins: I agree that as long as it's not unusably slow we should be able to do this, authors would just have to wait for animation use cases<br>
<emilio> fserb: two things<br>
<astearns> ack fserb<br>
<emilio> ... first, I think I tend to agree with Tab that it might be possible to given one shape and automatically build the two things<br>
<emilio> ... it is probably possible<br>
<emilio> ... need to be careful about where it begins<br>
<emilio> ... I don't think we need more infrastructure from low level graphics APIs for this<br>
<emilio> ... if we have a good way of determining how the inner shape works from the outer and a width<br>
<emilio> smfr: I think some shapes might be pretty hard, like shapes with loops and what not<br>
<emilio> fserb: I think that works less for colors than for width<br>
<emilio> ... I don't know what colors mean on a shap<br>
<emilio> ... I think leaverou wanted to do quadrants, but even that seems a bit sketchy<br>
<TabAtkins> (i'm fine with abandoning gradient stroke)<br>
<emilio> ... but would be nice to try this for border<br>
<emilio> ... easy way is to lose some of those other properties, but maybe we regret this<br>
<noamr> q+<br>
<emilio> ... Maybe it's worth trying to connect border-width to this, even if it's probably hard<br>
<astearns> ack florian<br>
<fantasai> +1 fserb<br>
<emilio> florian: back to an earlier point, the fact that this would be disconnected from layout border-width<br>
<emilio> ... it might be seen as a feature<br>
<emilio> ... controlling the layout so taht it doesn't interact with the border seems useful<br>
<emilio> ... so defaulting stroke to top<br>
<TabAtkins> yeah, taking the default width/color from border-top seems fine<br>
<emilio> ... and using left/right/bottom for layout adjustments seems nice<br>
<astearns> ack schenney<br>
<emilio> ... maybe weird but convenient<br>
<fantasai> or average all the colors? :)<br>
<emilio> schenney: so in your original demo, where would scrollbars be if you had overflow: scroll?<br>
<TabAtkins> scrollbar-path: shape(...)<br>
<emilio> noamr: The problem with scrollbars is the same for border-radius, it appears on top<br>
<emilio> ... ugly, but needed for a11y<br>
<florian> scrollbar-path ?<br>
<emilio> ... this conversation about the border stuff being this default makes sense<br>
<emilio> schenney: so we're leaning towards making this not affect the layout right?<br>
<emilio> correct<br>
<emilio> smfr: Firefox applies extra constraints to border radius for scrollbars<br>
<emilio> ... maybe the spec could allow that for border-shape too<br>
<astearns> ack noamr<br>
<emilio> noamr: wanted to go back to separate it from corner-shape<br>
<emilio> ... so keep corner-shape for boxes, and border-shape for other stuff<br>
<noamr> q+<br>
<florian> q+<br>
<emilio> smfr: so do we want to merge corner-shape and border-shape or keeping separate?<br>
<TabAtkins> would prefer separate<br>
<astearns> ack noamr<br>
<fserb> +1 separate<br>
<TabAtkins> q+<br>
<emilio> noamr: one argument against combining is that corner-shape interacts with border-radius<br>
<astearns> ack florian<br>
<emilio> smfr: you could also see a border-shape that's mostly rounded as an enhancement on border-radius<br>
<emilio> florian: so border-shape: auto uses the rest, and otherwise you override<br>
<ydaniv> q+<br>
<emilio> emilio: but you have two props at that point already<br>
<emilio> q+<br>
<bramus> emilio: dont think that is exclusive<br>
<bramus> … if you keep the on the same property you can still define sth like that<br>
<bramus> … if corner shape is superellipse then you account for border radius and take over<br>
<bramus> florian: could be worng that corner shape thing has not 1 value but 1, 2,4 …<br>
<bramus> … it has longhands to go along with this<br>
<bramus> … whcih border-shape does not<br>
<bramus> … its 4 props (or more) rolled into 1<br>
<bramus> … where border-shape is 1 thing<br>
<bramus> emilio: that’[s a good argument<br>
<astearns> ack TabAtkins<br>
<emilio> TabAtkins: pretty strong to keep them separate<br>
<emilio> ... as it was brought up, generic paths have a lot of complexity<br>
<emilio> ... that prevents us from making assumptions<br>
<emilio> ... well defined corner shapes don't have those constraints, and we can use border-width etc<br>
<emilio> ... so I think corner-shape should be on the general thing, and the path version should do its own thing on top<br>
<astearns> ack ydaniv<br>
<emilio> ydaniv: we could consider reversing the names, conceptually<br>
<emilio> ... having a shape as the shorthand and border / corner as longhands<br>
<emilio> ... maybe think how they interact<br>
<emilio> ... may make it more complicated tho<br>
<astearns> ack emilio<br>
<emilio> astearns: so leaning about separate properties?<br>
<emilio> smfr: yeah, modulo bikeshedding name<br>
<emilio> noamr: yeah I think last bikeshed was border-shape, but we can always change it in the future<br>
<emilio> border-shape: <shape> <shape>?; + strokes TBD (top border width default + override)<br>
<astearns> ack fantasai<br>
<emilio> fantasai: I agree we should have border-{width,color} in<br>
<emilio> ... I think the border shorthand... ?<br>
<emilio> ... what's the plan for corner-shape?<br>
<emilio> fantasai: for color we might want the border-top-left color, or block-start, or averaging all the four colors<br>
<emilio> ... all slightly awkward<br>
<TabAtkins> block-start, definitely. i don't think averaging will produce anything meaningful. ^_^<br>
<emilio> astearns: maybe separate issue?<br>
<fantasai> s|colors|colors/widths|<br>
<emilio> noamr: details I need is (1) corner-shape is different<br>
<emilio> PROPOSED: corner-shape and border-shape are independent properties<br>
<fantasai> none sgtm<br>
<emilio> PROPOSED: border-shape overrides corner-shape/border-radius and co<br>
<fserb> sgtm<br>
<emilio> RESOLVED: corner-shape and border-shape are independent properties<br>
<emilio> ack fantasai<br>
<astearns> ack fantasai<br>
<emilio> fantasai: I think necessarily one has to override the other, and border-shape needs to override the other<br>
<emilio> ... we could create a shorthand for both border and corner shape<br>
<emilio> ... I don't see how we could have both applying at the same time<br>
<noamr> that shorthand would have to also have border-radius<br>
<fantasai> yes<br>
<bramus> emilio: consensus is that you cant have both appplied at th esame time and you cannot make them be the same property if you want corner-shape to be a shorthand<br>
<bramus> florian: yes, and we could have a super shorthand but can discuss separately<br>
<bramus> fantasai: yes, what i am saying<br>
<bramus> emilio: should also discuss things like them being reset or not by the shorthand<br>
<bramus> astearns: a super shorthand sound scary :)<br>
<emilio> RESOLVED: border-shape overrides corner-shape / border-radius<br>
<bramus> emilio: should we resolve on it not affecting layout too?<br>
<bramus> astearns: yes<br>
<bramus> PROPOSED RESOLUTION: border-shape is a non-layout affecting property<br>
<bramus> RESOLVED: border-shape is a non-layout affecting property<br>
<emilio> PROPOSED: border-shape doesn't affect layout, only ink overflow and graphic effects like clipping and shadows<br>
<bramus> astearns: other things to discuss?<br>
<bramus> noamr: the derfault stroke and color are taken from the existing border props. can say tbd which property exactly<br>
<emilio> PRPOSED: default stroke width / color get taken from existing border props<br>
<emilio> which ones TBD<br>
<emilio> smfr: maybe TBD is ok but I think it's fine to do the diagonal color joint in the issue<br>
<emilio> RESOLVED: default stroke width / color get taken from existing border props, specifics TBD<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2622533926 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 January 2025 18:37:56 UTC