- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 27 Sep 2024 16:58:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-shapes-2] Add a way to change an element's shape`, and agreed to the following: * `RESOLVED: adopt border-shape in principle and continue to discuss specifics` * `RESOLVED: Call it border-shape for now` * `RESOLVED: specify the 2 path syntax` * `RESOLVED: also specify the 1 path syntax` <details><summary>The full IRC log of that discussion</summary> <noamr> https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2311513957<br> <dbaron> noamr: I posted the comment from smfr with a proposal<br> <dbaron> fantasai: The proposal is to add a new border shape property<br> <dbaron> fantasai: We can probably split discussion into concept vs. specific syntax.<br> <Rossen9> q?<br> <dbaron> fantasai: The idea of a border-shape property is that it defines shape of border edge of box.<br> <dbaron> fantasai: It can both cut in to border edge and go out. It just gives a new path.<br> <dbaron> fantasai: We use that for painting purposes only.<br> <dbaron> fantasai: So backgrounds, border. Doesn't affect layout.<br> <dbaron> fantasai: The syntax here subsumes the corner-radius step. We can talk about that...<br> <dbaron> fantasai: We could make it a shorthand for corner-shape and border-radius and another thing that has a path.<br> <dbaron> fantasai: The proposed syntax has several variations.<br> <lea> q+<br> <dbaron> fantasai: One is to provide border radius and corner shape values and derive shape from that.<br> <dbaron> fantasai: Another is a basic-shape that gets stroked.<br> <dbaron> fantasai: With shape function you can provide shapes relative to the box.<br> <dbaron> fantasai: Third option gives 2 paths, one for the outer border edge and the other for the inner border edge.<br> <dbaron> fantasai: you fill in between them.<br> <dbaron> fantasai: There's an example in the issue showing how that would work.<br> <dbaron> fantasai: With the shape function you can have fully responsive shapes.<br> <Rossen9> q?<br> <dbaron> fantasai: That's the basic proposal, we can go into details from there.<br> <TabAtkins> q+<br> <noamr> q+<br> <dbaron> lea: First, +1 to pursuing this. This needs solving, outstanding for some time. This avoids complexity about how borders adapt to regular shapes.<br> <Rossen9> ack lea<br> <dbaron> lea: I think we should avoid basing things on corner-shape or using it as precedent. I think at this point it was a bad design that we need to rethink.<br> <dbaron> lea: It introduces a lot of complexity for things that aren't needed.<br> <dbaron> lea: I'd design this ignoring corner-shape.<br> <dbaron> lea: Naming border-radius around borders is a recognized mistake in CSS.<br> <dbaron> lea: I worry about calling this border-shape. Element might have no borders.<br> <dbaron> lea: I think it makes more sense than border-radius here because it's defining the shape of the border.<br> <dbaron> lea: Though there's complexity about what if these paths intersect.<br> <fantasai> SebastianZ's refinement of the proposal -> https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2342081298<br> <dbaron> lea: Also, does border line style need to be a part of this?<br> <dbaron> lea: Would be nice to see examples with real world use cases and the syntax.<br> <dbaron> fantasai: I've gone back and forth on the border-radius question for that reason.<br> <dbaron> fantasai: It does give border edge rather than padding edge or content edge.<br> <dbaron> fantasai: We could call it box-shape if we wanted something different, but might be useful to be consistent.<br> <dbaron> fantasai: I think I disagree on corner-shape, it's a good way to do common cases like beveling.<br> <Rossen9> ack TabAtkins<br> <dbaron> TabAtkins: This proposal looks good to me. I think all 3 variants are useful.<br> <dbaron> TabAtkins: Simple one, single path, or two paths.<br> <dbaron> TabAtkins: A little weird: the way to specify fill on 2 stroke path is weird. The fill is specified using a border-area background-clip value.<br> <lea> TabAtkins: background-clip: border-area; was something we resolved on months ago<br> <lea> it's not part of this proposal<br> <fantasai> s/TabAtkins:/TabAtkins,/<br> <dbaron> lea: background-clip border-area was something we resolved in February<br> <dbaron> lea: It's something we've already specified, not being proposed here.<br> <dbaron> TabAtkins: I'll leave it alone though I think we're overloading background.<br> <Rossen9> ack noamr<br> <dbaron> noamr: Wanted this in my web developer days. Popup baloon on wikipedia.<br> <dbaron> noamr: I wonder if this is 3 proposals.<br> <dbaron> noamr: I think the third one with the 2 paths is complex and has many questions. Could we start with other 2 and then add the third?<br> <dbaron> noamr: Or do we need to specify all at the same time?<br> <dbaron> noamr: Most use cases seem handled by second type.<br> <dbaron> noamr: Also needs clarification, important for this proposal: it's not just about painting, but also clips descendants like border-radius.<br> <dbaron> fantasai: only if you specify overflow<br> <dbaron> noamr: yes, same clipping semantics as border-radius<br> <lea> q+<br> <TabAtkins> I'm not sure what looks particularly complex about the two-path version. Fill one shape, cut out the second shape, that's well-defined to do with a single path using reverse winding on the "inner".<br> <dbaron> noamr: Reason why ??? are specific and not using the existing ones is that some of the values don't work with arbitrary paths.<br> <dbaron> fantasai: This is the rendering simon gave me about how border colors should work.<br> <dbaron> fantasai: Now when you specify border colors there's a diagonal cut where the color changes. That's calculated from the inner and outer border stuff.<br> <astearns> s/???/border-line-style options/<br> <dbaron> fantasai: From this picture I think he's proposing we use that same calculation. This isn't especially useful. But it's a clear path from the existing behavior to what we'd do as the border path.<br> <dbaron> fantasai: and generally you only use one color.<br> <dbaron> fantasai: gives a defined rendering for the other cases.<br> <dbaron> fantasai: We could consider other options but this seems like the best idea so far.<br> <dbaron> fantasai: Regarding inner/outer paths, Simon's rendering is weird. But use case: consider a speech bubble. You don't typcially want a single thickness stroke around the entire speech bubble. The corners are narrow, middle of curve is thicker, etc. Or some other pen/brush-like effect.<br> <dbaron> fantasai: So variation in thickness of stroke of border is a common scenario.<br> <dbaron> fantasai: That's the use case for having two.<br> <dbaron> astearns: To noamr's point, those could be separated and we could get to them later. The first 2 bits don't depend on it.<br> <dbaron> fantasai: but we have a proposal that also addresses those.<br> <Rossen9> ack lea<br> <dbaron> lea: Re fantasai, I agree the diagonal could be any angle, just needs ot be well defined.<br> <dbaron> lea: grammar is hard to parse here. What happens if you specify only one shape, or do you always need an inner and outer.<br> <dbaron> TabAtkins: Can specify one shape and you stroke that shape.<br> <dbaron> lea: Discussions in June about difficulty of offseting a path to make it smller or bigger.<br> <kizu> q+<br> <dbaron> TabAtkins: IT strokes the center of the path; if you want inside/outside you need to specify two.<br> <dbaron> lea: You could have it represent the outer edge, stroke it, and clip it, but that's...<br> <dbaron> s/lea/fantasai/<br> <dbaron> fantasai: The stroking in the middle is one thing I don't like about this.<br> <dbaron> lea: That would force authors to use 2 shapes in many cases when they could use one.<br> <fantasai> s/lea: You could/fantasai: You could/<br> <dbaron> lea: forces authors to specify a path that's not visible at all in their layout<br> <dbaron> lea: I noticed in the rendering that some text is clipped, how does that work?<br> <dbaron> fantasai: With border-radius it's clipped if you specify overflow.<br> <dbaron> lea: Would be nice to see what happens if you don't<br> <dbaron> fantasai: Just draws on top like any other box.<br> <dbaron> fantasai: we're not chagning the layout, just the border and background painting<br> <dbaron> kizu: This issue with overflow -- we might want how to make it accsesible in most cases. ??? ??? How we can make a big border-radius. For example, making big area by default -- by default the content if hidden or auto will not ??? and will exapnd further<br> <dbaron> kizu: It would be nice by default to not put content under something that's hidden.<br> <dbaron> kizu: Would be nice to find a safe solution for this.<br> <Rossen9> ack kizu<br> <dbaron> kizu: This is a proposel that I'd want to see. ??? define shape in a way that borders still work.<br> <dbaron> kizu: I will check... It will depend on ths proposal to make compat shapes as boxes.<br> <dbaron> fantasai: With an arbitrary shape there's no real way to make extra padding magically. The intrusions might not be at the bottom. If it's hourglass shape, what does that do?<br> <astearns> there is shape-inside…<br> <dbaron> fantasai: This has to be something that ... shape of the box. Up to author to adjust the padding.<br> <dbaron> fantasai: For authors adjusting shape... we still don't have a way to make shape-inside to something s in a responsive + performant way.<br> <dbaron> fantasai: border-image doesn't avoid the content. If you make the border thick it does. But if you use insetting ability then you don't have that.<br> <dbaron> fantasai: It will paint under the content.<br> <Rossen9> q?<br> <dbaron> fantasai: I have some questions.<br> <TabAtkins> +1<br> <dbaron> fantasai: First, do we want to adopt a border-shape property such as this one, in princple?<br> <dbaron> (questions to the group)<br> <astearns> and as a hack, you could use shape-outside to mimic the inside edge of the fancy border<br> <noamr> +1<br> <kizu> +1<br> <kbabbitt> +1<br> <astearns> +1<br> <dbaron> fantasai: with details ot be worked out later<br> <chrishtr> +1<br> <miriam> +1<br> <lea> +1 but very concerned about the single shape syntax<br> <dbaron> astearns: back to noam's point of separability, we can draft this, and if we find the 2 shape thing is more complicated we can mark it at risk or move to another level<br> <dbaron> noamr: or give it TODOs<br> <chrishtr> q+<br> <dbaron> fantasai: but this is the beginning, so draft what we can<br> <lea> q+<br> <Rossen9> ack fantasai<br> <dbaron> chrishtr: what about animations?<br> <dbaron> fantasai: yes, you can animate it<br> <dbaron> fantasai: given with shape syntax, animates same way as shapes<br> <dbaron> chrishtr: can it be HW accelerated?<br> <noamr> q+<br> <dbaron> fantasai: as much as anything else?<br> <Rossen9> ack chrishtr<br> <dbaron> chrishtr: has the team tried? Expressed in shader, put on compositor thread?<br> <dbaron> fantasai: I don't know implementation details.<br> <astearns> q+<br> <dbaron> chrishtr: would be good to follow up on that question<br> <dbaron> fantasai: does that block anything?<br> <dbaron> TabAtkins: Given that we can hw accelerate clip-path, seems similar.<br> <fantasai> s/does/sure, but does/<br> <dbaron> noamr: we don't hw accelerate border (?), we don't hw accelerate clip-path yet. We don't accerelate border-raidus if it's complex.<br> <dbaron> chrishtr: We draw it with a shader when possible. But we don't accelerate animations of it.<br> <dbaron> chrishtr: I want to make sure the syntax gives us a path to doing that.<br> <dbaron> noamr: I think the challenge is the complextiy of drawing borders, not the shapes.<br> <dbaron> chrishtr, noamr: color, image, storke, shadow<br> <Rossen9> ack lea<br> <dbaron> lea: Were lots of +1 about working on this. I wanted to get clarity on what's a detail?<br> <dbaron> lea: Would people be open to improving single shape syntax so it doesn't define something that's not visible anywhere.<br> <dbaron> fantasai: Just question of whether we want to solve the problem.<br> <noamr> q-<br> <dbaron> fantasai: I don't want to dive into all the details without agreeing that we want to pursue the general idea.<br> <ydaniv> q+<br> <Rossen9> ack ydaniv<br> <dbaron> ydaniv: Why you can do something like shape-outside to offset text?<br> <dbaron> fantasai: you can, yes<br> <dbaron> ydaniv: so if you want text overflowing, and also ?? on top of it, you can use shape-outside<br> <astearns> shape-outside uses floats. this would not<br> <dbaron> fantasai: You can use shape-outside on a shape element to flow text around it. But there are interesting problems with shape-inside.<br> <dbaron> fantasai: This proposal doesn't change layout. You could use the same path in shape-outside (which we have) and shape-inside (which we don't).<br> <dbaron> Rossen9: do we want to resolve on all 3 or one at a time?<br> <dbaron> fantasai: Let's go one at a time, I have more questions on specifics.<br> <dbaron> Proposed resolution: adopt border-shape in principle and continue to discuss specifics<br> <dbaron> RESOLVED: adopt border-shape in principle and continue to discuss specifics<br> <noamr> q+<br> <dbaron> fantasai: Next question: what should we call it?<br> <astearns> q-<br> <dbaron> fantasai: Current proposal is border-shape.<br> <dbaron> fantasai: Do people want to suggest other names?<br> <kizu> I like `box-shape`<br> <dbaron> fantasai: Quickly, could bikeshed more later.<br> <ydaniv> s/ydaniv: Why you can/ydaniv: Why you can't/<br> <Rossen9> ack noamr<br> <dbaron> noamr: Argument for border-shape -- it's in the family of existing things. We already have border-radius even if we don't like it.<br> <dbaron> noamr: this makes it discoverable<br> <dbaron> fantasai: We have border-shape and box-shape. Should we straw poll?<br> <fantasai> 1. border-shape<br> <fantasai> 2. box-shape<br> <castastrophe> 1<br> <TabAtkins> 1<br> <kizu> 2<br> <kbabbitt> 1<br> <fantasai> 0<br> <futhark> abstain<br> <dbaron> 1<br> <noamr> 1<br> <alisonmaher> 1<br> <astearns> 1 (for now, ok to bikeshed later)<br> <Rossen9> 1<br> <kschmi> 1<br> <masonf> abstain<br> <oriol> abstain<br> <ydaniv> abstain<br> <noamr> (box-shape feels like a layout thing)<br> <dbaron> RESOLVED: Call it border-shape for now<br> <dbaron> fantasai: next question: should this be a shorthand that sets corner-shape and border-radius properties, or should it be a separate property than when sets, overrides everything else regardless of cascade<br> <astearns> q+<br> <lea> q?<br> <dbaron> fantasai: I feel like shorthanding makes sense, but question about what happens if you set both.<br> <lea> q+<br> <dbaron> fantasai: If we make it a shorthand then if you specify either a shape or corner then that's what you get for sure.<br> <TabAtkins> q+<br> <dbaron> fantasai: If it's a separate longhand, then the border-shape always wins.<br> <dbaron> fantasai: We could go either way... could also open separate issue.<br> <dbaron> astearns: I would like to take this to an issue. I'm happy to have something in the draft with issue in it. But I don't think we can design this in committe right now.<br> <astearns> ack astearns<br> <Rossen9> ack lea<br> <dbaron> lea: I agree that this needs more design work. I also don't think we should design around corner-shape, in spec for >10 years and not implemented. If we're adding a new thing, do we *also* need corner shape? We already have border-radius for common cases. We don't need another new way to set element shape.<br> <dbaron> lea: For something it might be easier, let's define a shape funciton and continue to use element shape for them.<br> <lea> qq+<br> <dbaron> fantasai: Counter to that is that there are common use cases. When you're using a path you have to give a path for the whole shape. Corner shape lets you set corners independently, can do writing-mode-relative easily.<br> <dbaron> fantasai: When you're doing something compcilated you need to specify the whole path.<br> <Rossen9> ack lea<br> <Zakim> lea, you wanted to react to lea<br> <Rossen9> ack fantasai<br> <Zakim> fantasai, you wanted to respond to that<br> <dbaron> lea: That would apply if all we could do is specify path. But there's a lot to shapes: inset, etc.<br> <dbaron> fantasai: But you have to set them all. But if you want a slash shape, you have to define the path of the whole box rather than just the corner.<br> <castastrophe> q+<br> <dbaron> fantasai: I think that's a much easier thing when that's what they want,which is common.<br> <dbaron> fantasai: So I think the border-shape properties make sense.<br> <dbaron> fantasai: But that doesn't really affect this question because we still have the border-radius properties.<br> <dbaron> fantasai: corner-shape is only a minor additional complexty<br> <dbaron> lea: That's a ???. corner-shape does make some cases simpler. But it has cruft for things that aren't really needed.<br> <dbaron> lea: For things like bevel, helps with some polygons, but most polygons in the wild have rounding which it doesn't account for.<br> <Rossen9> ack TabAtkins<br> <dbaron> TabAtkins: ??? concern is that I don't care about shorthand or complicated direction. If you just set border-shape it should do the right thing. It looks like in the example he didn't to do something to explicitly cause the regular border to not render. It should work better in that case.<br> <dbaron> TabAtkins: If you set border-shape it should affect the other border properties appropriatly without author needing to do extra work.<br> <dbaron> castastrophe: Question: is there a perf gain for repainting just a border corner versus a larger shape?<br> <dbaron> fantasai: no idea<br> <dbaron> fantasai: I also don't think that's a consideration; we should worry about the ergonomics.<br> <Rossen9> q?<br> <dbaron> noamr: We could probably figure out from any shape, could reverse-engineer it to a corner-shape and get the same hypothetical perf benefit.<br> <Rossen9> ack castastrophe<br> <dbaron> fantasai: So on this question we're opening a new issue.<br> <dbaron> fantasai: ANother question: do we want the 2 path syntax where you can fill between or do we think that's not worth trying?<br> <noamr> q+<br> <lea> q+<br> <dbaron> fantasai: The current proposal has a stroked 1 path version and a filled 2 path version. Do we like both options or want just 1?<br> <astearns> +1 to add it in for now, issues to remove or postpone as necessary<br> <Rossen9> ack noamr<br> <dbaron> noamr: I tihnk we want both shapes, question of editorial understanding and iteration on spec to make it readable.<br> <TabAtkins> 1-shape super restrict you to *solely* the geometry of a shape's stroke, that's quite limiting (if common)<br> <Rossen9> ack lea<br> <dbaron> lea: especially if we don't figure out how to offset paths property, I think the 2-shape syntakx is essential for specifying what you want<br> <dbaron> lea: If you don't have a way to specify the shapes explicitly then it doesn't have the necessary level of control.<br> <dbaron> lea: we definitely need the 2 path syntax esp. if we don't figure out the 1 path syntax.<br> <dbaron> (I think lea meant offsetting for the 1 path syntax.)<br> <dbaron> RESOLVED: specify the 2 path syntax<br> <dbaron> RESOLVED: also specify the 1 path syntax<br> <astearns> q+<br> <dbaron> fantasai: One other question from smfr, a little orthogonal, do we need additional keywordsfor background-origin.<br> <dbaron> fantasai: and maybe background-clip<br> <astearns> q-<br> <dbaron> fantasai: to change from using the layout box to using the box of the whole border shape<br> <dbaron> Rossen9: also sounds like a feature we can define once we get ...<br> <TabAtkins> Yeah, I think it's needed.<br> <dbaron> astearns: noam, would you be willing to become an editor for shapes2 for these features<br> <dbaron> noam: yes<br> <dbaron> astearns: my proposal is to add Noam as editor to shapes 2<br> <dbaron> fantasai: this goes in borders 4<br> <dbaron> astearns: ok, that spec instead!<br> <astearns> s/instead!/in addition!/<br> <dbaron> fantasai: I'm going to take actions to file followup issues, and I'm going to add this to the ED of borders 4.<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-2379700678 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 27 September 2024 16:58:12 UTC