- From: Mike Bremford via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Feb 2022 13:51:41 +0000
- To: public-css-archive@w3.org
I agree with Brad's comments above - we already have these concepts in CSS, we shouldn't be trying to reinvent an (arbitrarily-shaped) wheel. Someone mentioned `border-image` above - I think this is the model to follow for several reasons: 1. When specified it overrides _all_ the border properties, and defines the entire outline in one go. The alternative is deciding where "left" stops and "top" starts, which is impractical for arbitrary shapes. 2. It explicitly has no impact on the box-sizing calcs, which is going to be really important. 3. Because of the previous point, it introduces the concept of expanding the visible outline of the box by a certain number of pixels - i.e. drawing outside the nominal border-box. This approach would work well for shapes too (every browser already has code to expand or contract a path, as we have to do it when clipping to SVG stroke outlines). And allowing shapes to be expanded or contracted means you can reuse existing outlines like the `shape-outside` or `clip-path`. So, personally, I'd go with something more like a single `border-shape` property. Like `border-image` it completely overrides all the border properties if specified, it has no-impact on box-sizing at all, and as well as the style/color/width it takes both: * a path or the keywords `shape-outside` and/or `clip-path` to reference those shapes. * the number of pixels to expand/contract that path. As this builds on the conceptual models of `border-image` we'd be able to implement it using the same approach without too much trouble. -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6980#issuecomment-1026865647 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 February 2022 13:51:43 UTC