- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Oct 2024 21:19:47 +0000
- To: public-css-archive@w3.org
Or, another alternative: define *another* function, `stroke()`, which is identical to `shape()` but specifically defines a stroked path. It can then have the additional grammar items that handle stroke width and color, along with future items in a prelude argument like stroke direction (center/left/right) and such. (And it would *not* have the fill-specific items in its prelude argument, like the nonzero/evenodd keyword that `shape()` has.) Then, individual contexts would define whether they expect a `<shape>` or a `<stroke>`. If you pass `stroke()` to a `<shape>`, it's allowed, but we ignore all the stroke-specific stuff and default the fill-specific details in a context-specific manner. If you pass `shape()` (or any of the basic-shape function) to a `<stroke>`, it's allowed, but we ignore all the fill-specific stuff and default the stroke-specific details in a context-specific manner (such as getting the stroke width from 'border-top-width' or something). (We already do this if you use `path()` or `shape()` in Motion Path, for instance; the `nonzero`/`evenodd` keyword is simply ignored, since it actually takes a *third* semantic type, a plain ol' path.) So the one-path syntax would actually be a `<stroke>`; the two-path syntax would be a pair of `<basic-shape>`s. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6997#issuecomment-2389715094 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 October 2024 21:19:47 UTC