- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Tue, 03 May 2022 06:16:46 +0000
- To: public-css-archive@w3.org
> > But the big downside here is that the syntax regarding the color stops is not the same because the meaning of thickness is different from the positioning syntax for color stops in gradients. > > This is fine? It's literally the entire point of them, after all, and I'm not seeing why this is a problem in `linear-stripes()` but okay in `linear-gradient(..., stripes())`. It might just be my gut feeling but `linear-gradient(..., stripes())` looks more explicit than `linear-stripes()`. But yeah, it's a weak point. > > And another downside is that existing functions and data types are not reused. So, any additions to them also require some updates to those functions. > > No, we'd just create a non-terminal for the first arg of each of the gradient functions, and then use it in both gradients and stripes. Then any updates apply to all at the same time. What I meant by that is that neither the gradient functions nor the new `<1d-image>` data type are reused by that option. Though you're right that we could share more between both types of functions to mitigate this issue. We might also introduce a `<flex-color-stop>` data type for the stripes syntax, which could be reused in other places in the future. I currently also slightly tend to option 2 (with the adjustments mentioned above), as it's semantic seems a little clearer to me. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7244#issuecomment-1115772385 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 3 May 2022 06:16:47 UTC