- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Apr 2025 15:59:39 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width` ``. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: similar demo here<br> <TabAtkins> noamr: was discussed last f2f<br> <TabAtkins> noamr: border-shape is not the same as corner-shape<br> <TabAtkins> noamr: border can be any path or any two paths<br> <TabAtkins> noamr: question is how/if this should interact with border-width and border-color<br> <TabAtkins> noamr: i foudn some use-cases where i think it should<br> <TabAtkins> noamr: that's what's on the screen<br> <TabAtkins> noamr: things that are *like* a box but a little off<br> <TabAtkins> noamr: this is almost a rectangle, but with slanted lines and a curved bottom<br> <TabAtkins> noamr: and maybe the author would want the four sides of the box to take width and color from border-*<br> <TabAtkins> noamr: what i do here is i take each segment of the path and check its slope<br> <TabAtkins> noamr: if takes from the side it's closest to<br> <TabAtkins> noamr: another option i looked at is the split curves at the inflection point, where it changes direction<br> <TabAtkins> noamr: then beziers can feel a bit more accurate<br> <TabAtkins> noamr: but from my experiments so far, this would be more understandable for authors. to not split. they can split if they want to.<br> <fantasai> TabAtkins: So if I understand...<br> <smfr> can't hear tab<br> <fantasai> TabAtkins: For each path segment, you look at just the start and end point. Find the line between them. Identify that with one of the four sides depending on its angle.<br> <fantasai> TabAtkins: That's why this purple one is identified with bottom<br> <fantasai> noamr: Right, this is identified with the bottom edge because clockwise path<br> <TabAtkins> noamr: a lot of shapes and authors won't need this, their shape isn't boxy at all<br> <TabAtkins> noamr: but then they could jsut give it a uniform border-wdith and color and they wouldn't get this effect<br> <astearns> ack fantasai<br> <smfr> q+<br> <TabAtkins> fantasai: so one concern i have here is, by being tied to the direction of the path, if you flip the path (which you might want to do if you're respondign to writing direction) you'll associate the bottom with the top/etc<br> <TabAtkins> fantasai: which probably isn't intended<br> <TabAtkins> fantasai: i wonder if there's a way to do this that doesn't carea bout CW vs CCW<br> <TabAtkins> noamr: we always work on the CW version of the path. if the path is CCW we reverse the order first<br> <TabAtkins> noamr: if it's got subpaths we do it for each subpath separately<br> <astearns> ack smfr<br> <TabAtkins> noamr: each subpath, we make it clockwise, then check each segment<br> <TabAtkins> smfr: something elika just reminded me of is animations<br> <TabAtkins> smfr: if you evaluate the path association live, you could have colors flickering as the path changes<br> <TabAtkins> noamr: yeah ifyou're animating the path, you probably want uniform border colors<br> <TabAtkins> noamr: but when you're close to a box you probably do want this.<br> <TabAtkins> smfr: my concern here is just, i foresee some ugly paths coming out of this<br> <TabAtkins> smfr: we spent a lot of time getting corner-shape to look nice, but it seems like this wouldn't<br> <TabAtkins> noamr: i think that's generally the case for border colors<br> <fantasai> TabAtkins: I think we should have a way to manually associate colors and segments, but I think this is probably the most correct default assignment<br> <fantasai> TabAtkins: if you do just want uniform colors, you can set uniform colors<br> <fantasai> TabAtkins: There's space open for a border-shape-colors property to associate with the segments<br> <fantasai> TabAtkins: that would allow consistent coloring across an animation<br> <smfr> q+<br> <fantasai> TabAtkins: We shouldn't require authors to spec by default<br> <astearns> ack smfr<br> <TabAtkins> smfr: this isn't just about colors tho, right? it's also width<br> <TabAtkins> TabAtkins: yes, but i think same argument applies<br> <TabAtkins> smfr: i haven't played with this too much, but my suspicion is some paths it'll give okay results, others bad, potentially flickery if animated<br> <TabAtkins> smfr: question is just if authors want this, versus just specifying the two path version<br> <fantasai> TabAtkins: I want to avoid requiring 2-path version as much as possible. It's unusable for hand authoring.<br> <fantasai> TabAtkins: Shouldn't be requiring it for simple shapes.<br> <TabAtkins> smfr: i think that's okay, many shapes will be tooling in the long run<br> <TabAtkins> smfr: it's possible take one shape and make minor edits to get the inside shape<br> <fantasai> TabAtkins: If doing just a quadrilateral, it's not impossible to offset and get inner shape<br> <fantasai> TabAtkins: but in that case I just want this sort of adjustment: give each side a width. That's what border-width does for me.<br> <fantasai> TabAtkins: In a large section of common cases, this will give good behavior. And for more unusual cases, we can either have manual overrides or have authors use 2-path version.<br> <TabAtkins> astearns: simon, are you concerned enough about this that you'd prefer just having something radically simple for single-path version that doesn't do any widths and colors? that requires using two-path or manual override for something else?<br> <TabAtkins> smfr: i'm not sure. i think i'd like more time to experiment<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i think i'd probably +1 that<br> <TabAtkins> fantasai: ther'es four options in the original comment here, what was your analysis of those four?<br> <TabAtkins> noamr: uniform border width (option 1), we can always achieve by ignoring the other borders. i think people would just be confused why their border-bottom isn't being used<br> <TabAtkins> noamr: but we coudl always do it, it's simplest<br> <TabAtkins> noamr: option 2 (cutoff points with interpolation), it's bascially this (the current demo) but the cutoff points are determined by the segment<br> <TabAtkins> noamr: when i tried it, it gave worse results than using the slope<br> <TabAtkins> noamr: rotated shapes in particular<br> <TabAtkins> noamr: option 3, point-by-point tangent, we don't know how to implement it<br> <TabAtkins> noamr: great api in theory, really complicated.<br> <TabAtkins> noamr: need to convert this into an inner and outer path<br> <TabAtkins> noamr: closest i got to that was splitting a bezier, like i showed, at inflection points or something<br> <TabAtkins> noamr: so you'd have the path as a bunch of smaller segments and then connect from there<br> <TabAtkins> noamr: but that would be even more jittery with animations<br> <TabAtkins> noamr: authors can achieve it thesemvles by splitting segments into pieces<br> <TabAtkins> noamr: so option 4 is the nearest border. if you have a small rectangle close to the right, you'd get all the right-width styles, doesn't look right.<br> <TabAtkins> noamr: the slope version i think gives the best results when the shape has some relationship with a box<br> <TabAtkins> astearns: any other comments?<br> <fantasai> fantasai: thanks<br> <TabAtkins> noamr: i think we can leave it unresolved for now, if simon isn't sure about it<br> <TabAtkins> astearns: yeah some more examples, looking at things that approximate rectangles less<br> <TabAtkins> noamr: yeah, my intention wasn't necessarily to resolve, but to open people's minds to the topic<br> <TabAtkins> astearns: okay, take it back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11662#issuecomment-2769857146 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 April 2025 15:59:40 UTC