- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Apr 2022 16:28:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `listifying border color`, and agreed to the following: * `RESOLVED: Remove <1d-image> from <image> for now, open a separate issue to discuss it` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> topic: listifying border color<br> <TabAtkins> sebastian: several years ago we resolved to add stripes() to let you define several border colors<br> <TabAtkins> sebastian: Idea was to allow this to be used in other contexts, so we introduced <1d-image> to Images 4.<br> <TabAtkins> sebastian: Now the feature is mostly complete; there's a PR ready for the specs.<br> <TabAtkins> sebastian: fantasai asked what to do with <1d-image> in 2d contexts<br> <TabAtkins> sebastian: Idea was to also allow it in other 2d contexts, so adding <1d-image> to the <image> type<br> <lea> Can someone link to the PR we are discussing?<br> <fantasai> PR https://github.com/w3c/csswg-drafts/pull/7029<br> <TabAtkins> sebastian: fantasai wasn't sure how that should be done. One idea was to add a new function for 2d stripes<br> <TabAtkins> sebastian: But the idea was that we could have linear-gradient(..., stripes())<br> <TabAtkins> fantasai: The original proposal is that we allow stripes() in 2d contexts, and default it to "down" (like a linear gradient)<br> <TabAtkins> fantasai: I dont think it's that useful (you often want something else), and it's not worht the testing/impl cost of doing it for the limited case<br> <lea> q+<br> <TabAtkins> fantasai: So if we *do* want the ability to do stripes()-like in 2d, we should have that addressed specifically with a proper 2d striping image, not this limited-direction 1d image<br> <astearns> ack lea<br> <TabAtkins> fantasai: Think it's more confusing than helpful otherwise<br> <TabAtkins> lea: Agree ethere's not much use in 1d-image in 2d contexts, primarily debugging<br> <TabAtkins> lea: Note tho that we do have 0d images (colors)<br> <iank_> what is an example of a 0D-image?<br> <TabAtkins> lea: So feels a little odd we can use 0d and 2d, but not 1d<br> <TabAtkins> lea: Also don't think we should add a new 2d stripes function; the gradients functions are already used for stripes and could use stripes() for their gradient line<br> <iank_> ok<br> <TabAtkins> fantasai: I don't agree that lack of 1d is confusing<br> <TabAtkins> fantasai: 0d is fine - you don't need any additional params to make it work<br> <TabAtkins> fantasai: 1d needs additional params - we have to *set* the direction<br> <TabAtkins> fantasai: for putting it in linear-gradient(), I don't think nesting the functions is easier to read. I think it's better to have a linear-stripes() or wahtever, that's more like how we do functions normally<br> <TabAtkins> sebastian: But we could use it for all the gradients<br> <TabAtkins> fantasai: Right, a linear-stripes(), radial-stripes(), conic-stripes(), that's just the same first arg as the gradient func but takes the stripes args after<br> <TabAtkins> fantasai: syntaxes are perfecty analogous<br> <TabAtkins> lea: Agree nesting isn't great, but reusing means you get all the gradient controls for free<br> <TabAtkins> fantasai: Right, we'll just copy the first arg.<br> <TabAtkins> lea: Do you suggest we abstract it to a separate type? otherwise we have to keep it in sync manually<br> <TabAtkins> fantasai: They're in the same module, we can do whatever we need. This is editorial, we can do that if we need.<br> <fantasai> TabAtkins: We already have that problem for the repeating variants as well<br> <TabAtkins> astearns: So I'm hearing two options - nested stripe() in gradient(), or a separate gradient()<br> <fantasai> s/gradient/stripes()/<br> <fantasai> e.g. linear-gradient(..) ~~ linear-stripes(...)<br> <TabAtkins> lea: One slightly weak arg - if we can use stripe as a gradient line, authors can use a single variable for both borders and backgrounds<br> <TabAtkins> astearns: You could put the args in a variable and then use them i both<br> <TabAtkins> lea: You can but it's awkward, same as putting color args in a variable so you can modify the alpha. Awkward<br> <TabAtkins> sebastian: we could also have a keyword that interprets the following args as stripes<br> <TabAtkins> fantasai: Or just add a new function name<br> <lea> q+<br> <TabAtkins> sebastian: But then we'd have to add 6 new functions<br> <TabAtkins> fantasai: That's not meaningfully different. We already have 2x3 variants of gradients, if they want stripes we can do another set<br> <astearns> ack lea<br> <iank_> Additional functions aren't particularly expensive from an implementation POV.<br> <TabAtkins> lea: Note that what I was proposing was speccing the gradient line as a 1d image, not as stripes() specifically<br> <TabAtkins> lea: I do think it's a little werid if we have a bunch of 1d images that we can't use as a gradient line, since the gradient lie is conceptually a 1d image itself<br> <TabAtkins> fantasai: I don't think of the gradient as being a generic 1d image stretching function. It's for making gradients, which it does. If we need different functions that do different things, we can do that.<br> <TabAtkins> fantasai: If you wanna do something complicated you can use the gradient functions, if you want stripes you can do stripes()<br> <TabAtkins> lea: This isn't mutually exclusive either<br> <TabAtkins> fantasai: I think we're bikeshedding syntax now, I just don't wnat the 1d-as-2d to be in the initial PR<br> <lea> q+<br> <TabAtkins> sebastian: So maybe leave that out for now, and only define it for border and outline, which is the initial use-case<br> <astearns> ack lea<br> <TabAtkins> sebastian: can discuss 2d contextsw in a separate issue<br> <TabAtkins> lea: Fine with not accepting, just need to define what happens<br> <TabAtkins> fantasai: Invalid<br> <TabAtkins> lea: Okay, that lets us change it in the future<br> <TabAtkins> astearns: So proposed resolution is to remove the stripes() as <image> for now<br> <fantasai> Literally, that's what falls out of the spec if we don't add it to <image><br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: Remove <1d-image> from <image> for now, open a separate issue to discuss it<br> <fantasai> scribeNick: fantasai<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2532#issuecomment-1111207894 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 April 2022 16:28:05 UTC