Re: [csswg-drafts] [css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width` (#11662)

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>
&lt;TabAtkins> noamr: this is about border-shape<br>
&lt;astearns> zakim, open queue<br>
&lt;Zakim> ok, astearns, the speaker queue is open<br>
&lt;TabAtkins> noamr: border-shape receives two paths<br>
&lt;TabAtkins> noamr: unclear what to do with the border proeprties<br>
&lt;TabAtkins> noamr: researched a lot, discussed with smfr<br>
&lt;TabAtkins> noamr: concluded there's no solution for a non-uniform border width. no way to do it that's useful<br>
&lt;TabAtkins> noamr: and very few border styles are supported for general-purpose shapes (mroe than just a box)<br>
&lt;TabAtkins> noamr: i suggested we treat this whole thing a bit differently in terms of styling, and use the SVG fill and stroke props<br>
&lt;SebastianZ> q+<br>
&lt;TabAtkins> noamr: so we ignore border width entirely, and use stroke to stroke the two paths, fill to fill between them<br>
&lt;TabAtkins> noamr: if you have only one shape, it's only stroked, no fill<br>
&lt;TabAtkins> noamr: you get all the svg functionality, dashing, paint servers, etc<br>
&lt;TabAtkins> noamr: i'd say it's a little confusing at first, but less confusing than having osme work and some not<br>
&lt;TabAtkins> noamr: when you're in border-shape, SVG styles your border.<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: i'm assuming border-width interactions still happen for layout purposes?<br>
&lt;TabAtkins> noamr: for layout it treats the border-style as none<br>
&lt;TabAtkins> fantasai: that's not great, you lose the border area entirely<br>
&lt;TabAtkins> noamr: we coudl also treat the border as transparent, can do either way<br>
&lt;TabAtkins> fantasai: yeah, that's what border-image does, should match<br>
&lt;TabAtkins> fantasai: wrt fill and stroke, we have a proposal for a long time to use fill/stroke for text<br>
&lt;fantasai> https://www.w3.org/TR/fill-stroke/<br>
&lt;TabAtkins> fantasai: if we want to do something completely different for that, we have to decide which use-case gets to use these props<br>
&lt;ChrisL> q+<br>
&lt;TabAtkins> fantasai: like maybe we need text-fill and text-stroke, etc<br>
&lt;astearns> ack SebastianZ<br>
&lt;TabAtkins> SebastianZ: just posted in the issue, i'm not yet convinced that the appraoch with fill/stroke is right<br>
&lt;TabAtkins> SebastianZ: i still think, for most use-cases, it's easier for authors and maybe impls to reuse the border properties for this<br>
&lt;TabAtkins> SebastianZ: maybe on top of this we could define how fill and stroke work for it<br>
&lt;TabAtkins> SebastianZ: see some issues - fill is defined to fill the whole geometry, not just the border<br>
&lt;TabAtkins> SebastianZ: issue was originally just for single-path border shapes, it seems it also wants to cover double-path border shapes<br>
&lt;TabAtkins> SebastianZ: but i'm not yet convinced this is the perfect solution<br>
&lt;TabAtkins> fantasai: i ahve a blocking issue, fill/stroke are inherited, and you really don't want these to inherit<br>
&lt;TabAtkins> noamr: hm okay<br>
&lt;fantasai> s/ahve/have/<br>
&lt;TabAtkins> noamr: about the second point, there's no solution in isolation from thinking about how the borders are rendered<br>
&lt;TabAtkins> noamr: we originally thought about single border but the solution needs to think about the whole thing<br>
&lt;TabAtkins> TabAtkins: I think the inheritance just means we ahve to go the other way - introduce border-stroke and border-fill<br>
&lt;TabAtkins> noamr: I think it's cleaer border-style doesn't work. if we use border-stroke/fill, we can default them to the border-color or something.<br>
&lt;TabAtkins> noamr: smfr suggested using the four border triangles and clip their colors. complicated tho, the shape can go outside the border box<br>
&lt;TabAtkins> fantasai: i was thinking about that too. seems a straightforward way, but...<br>
&lt;TabAtkins> fantasai: for two-sided thing could go further. we draw the border then clip it to the shape.<br>
&lt;TabAtkins> TabAtkins: elaborate? don't understand<br>
&lt;ChrisL> q?<br>
&lt;TabAtkins> fantasai: you have a solid border, there's angles at the corner where the color changes<br>
&lt;TabAtkins> fantasai: smfr proposed extending those lines until they intersect, this divides the plane into four colored segments<br>
&lt;TabAtkins> fantasai: then you clip that plane by the border shape<br>
&lt;TabAtkins> fantasai: in theory you could do the same with dashing<br>
&lt;TabAtkins> fantasai: where they extend infinitely in both directions. but could be weird<br>
&lt;astearns> ack ChrisL<br>
&lt;TabAtkins> ChrisL: 3 points<br>
&lt;TabAtkins> ChrisL: is this meant to be a generalization that still applies to svg? so svg would use it?<br>
&lt;TabAtkins> fantasai: stroke/fill in svg are not affected<br>
&lt;TabAtkins> fantasai: i was just saying that becuase fill/stroke are inherited (from svg), we can't use those props for borders<br>
&lt;TabAtkins> ChrisL: second, if we apply this to text, can we define that th estroke goes behidn the fill? that's what you always want.<br>
&lt;TabAtkins> TabAtkins: separate issue, but yeah probably<br>
&lt;lea> re stroke behind fill, don't we have a property for this?<br>
&lt;TabAtkins> ChrisL: third, this reminds me of a concept we tried to do in svg where there's a boudning box, but sometimes you want stroke boudning box, etc<br>
&lt;TabAtkins> ChrisL: sounds like that's what we're needing here. stroking can make the element larger, may or may not care about it<br>
&lt;lea> (Yes, there is, `paint-order`: https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/paint-order Supported everywhere but WebKit)<br>
&lt;TabAtkins> ChrisL: fourth, mention of double borders reminded me, a11y wanted double borders, we introduced stripes(). wonder how this fits in?<br>
&lt;SebastianZ> q+<br>
&lt;SebastianZ> q-<br>
&lt;astearns> zakim, close queue<br>
&lt;Zakim> ok, astearns, the speaker queue is closed<br>
&lt;TabAtkins> fantasai: stripes() goes perpendiular from the border. could say the inner border edge is where you draw .... the outer border edge draws clipped<br>
&lt;TabAtkins> fantasai: that'll get you striped borders<br>
&lt;TabAtkins> fantasai: if you do a single path, so it's just stroked, you'll do something different<br>
&lt;TabAtkins> astearns: at time, can we resolve taht border-shape turns off border-size/etc?<br>
&lt;TabAtkins> fantasai: it should turn off the painting of the border<br>
&lt;TabAtkins> noamr: like the border is forced transparent<br>
&lt;TabAtkins> fantasai: yeah repalces the painting of the border, not the layout<br>
&lt;TabAtkins> noamr: yes. and can resolve on border-stroke/fill being separate from SVg stroke/fill<br>
&lt;TabAtkins> noamr: so first reoslution, if border-shape is not none, the normal border doesn't paint (but is still laid out)<br>
&lt;TabAtkins> SebastianZ: I'd prefer to talk about this in the issue. there was a comment yesterday about the comments to be discussed.<br>
&lt;TabAtkins> astearns: we'll take this all back to the issue. sounds like there's some details to work out, in future discussion we can discuss bits of it and resolve in different issues. adding new props, like border-fill/stroke, etc<br>
&lt;TabAtkins> fantasai: i have some comments. if we can reuse border width/color somehow, would be nice for authors<br>
&lt;SebastianZ> +1 on fantasai<br>
&lt;TabAtkins> noamr: sure. just haven't managed to do it so far<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-3205329047 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 August 2025 10:05:09 UTC