Re: [csswg-drafts] [css-shapes] Allow optional rounding parameter for `polygon()` (#9843)

The CSS Working Group just discussed ``[css-shapes] Allow optional rounding parameter for `polygon()` ``, and agreed to the following:

* `RESOLVED: Work on adding corner rounding to polygon()`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> lea: this is about resolving whether we should work on this<br>
&lt;emilio> ... noticed that even though we have polygon() and clip-path, author still resort to images because they don't cover their use cases, the use cases include rounding<br>
&lt;emilio> ... many cases the same as the polygon<br>
&lt;emilio> ... I posted many<br>
&lt;emilio> ... proposal was to add a round parameter to the polygon, and then to also add an optional on each individual coordinate to customize rounding to that corner<br>
&lt;emilio> ... the way it'd be painted would be "a circle of that radius that is tangential to both vertices"<br>
&lt;emilio> ... if it's >180deg it'd draw outside<br>
&lt;emilio> ... we did some research on the max values to not end up with the right shape<br>
&lt;TabAtkins> q+<br>
&lt;astearns> q+<br>
&lt;emilio> ... question is whether there are blockers or should we work on this<br>
&lt;fantasai> +1 to the proposal<br>
&lt;astearns> ack TabAtkins<br>
&lt;emilio> TabAtkins: I agree with this. There are some details about limits<br>
&lt;emilio> ... but they don't need to be worked out here. Suggested functionality and syntax sounds good<br>
&lt;emilio> q+<br>
&lt;astearns> ack astearns<br>
&lt;emilio> ... so very supportive<br>
&lt;emilio> astearns: two questions<br>
&lt;emilio> ... perfectly fine with the proposal<br>
&lt;emilio> ... but I'm a bit concerned about rounding polygon corners because it's no longer a polygon<br>
&lt;emilio> ... so I wonder if it'd be better to fix path() to make this syntax simpler<br>
&lt;emilio> ... but if we do this I don't mind<br>
&lt;emilio> TabAtkins: we already round rectangles<br>
&lt;emilio> astearns: the other question is that it'd be nice if the rounding matches the rounding for shape-margin for polygons<br>
&lt;emilio> ... there's some text in the shapes spec that says how we do that<br>
&lt;emilio> TabAtkins: for expanding shapes it works the same way<br>
&lt;emilio> ... when it goes in I'm less sure<br>
&lt;astearns> ack emilio<br>
&lt;lea> re: is it a polygon any more, e.g. look at the W3Conf example, would you describe these as anything other than hexagons?<br>
&lt;dholbert> emilio (IRC): same line as astearns (IRC) ... Do we have anything to make this sort of path easily already right now?<br>
&lt;dholbert> TabAtkins (IRC): We do in the canvas specs. It has an operation to do this sort of rounding, corner-by-corner<br>
&lt;bkardell_> let's add it to svg :)<br>
&lt;dholbert> TabAtkins (IRC): It doesn't exist in SVG, but in the other thread I suggested pulling in some of the canvas operations as well<br>
&lt;fantasai> bkardell_, you volunteering to edit SVG? :)<br>
&lt;dholbert> emilio (IRC): seems like this use case should be/become covered by path, since it is a path<br>
&lt;lea> bkardell_: we'd need an SVG WG first and buy-in from implementers (who are *very* unwilling to implement any SVG thing)...<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to respond to that<br>
&lt;dholbert> emilio (IRC): it seems reasonable to add it to polygon, but we should make sure you can do this for a path too<br>
&lt;emilio> fantasai: could you do this in path? Yeah, but lots more work<br>
&lt;TabAtkins> the canvas `arcTo()` is literally "define a corner + a radius, and add the rounded corner to your path"<br>
&lt;emilio> ... by making the assumption that everything is a line it makes it a lot easier in polygon()<br>
&lt;TabAtkins> bkardell_, I don't think we need to add it to SVG *per se*, but adding it to shape() is fine<br>
&lt;emilio> ... telling authors that they should use path() for this is fine<br>
&lt;lea> +1 to fantasai's point, we even have a TAG principle to avoid cliffs where a small amount of use case complexity results in a large increase in complexity<br>
&lt;bkardell_> igalia is working on svg. I admit it is not 'new' svg, but if there are people (or organizations) interested in svg they should definitely maybe talk to me :)<br>
&lt;emilio> astearns: agree but we should make it easy to move from one to another<br>
&lt;lea> s/1 to fantasai's point, we even have a TAG principle to avoid cliffs where a small amount of use case complexity results in a large increase in complexity/1 to fantasai's point, we even have a TAG principle to avoid cliffs where a small amount of use case complexity results in a large increase in UI complexity/<br>
&lt;emilio> PROPOSAL: Work on adding corner rounding to polygon()<br>
&lt;emilio> RESOLVED: Work on adding corner rounding to polygon()<br>
&lt;fantasai> \^_^/<br>
&lt;emilio> emilio: should we resolve on rounded lines for path()?<br>
&lt;emilio> fantasai: there's another issue for that, a bit more complicated<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9843#issuecomment-1944485653 using your GitHub account


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

Received on Wednesday, 14 February 2024 19:48:00 UTC