- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Aug 2023 17:02:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-images-4] Allow stripes to be used as gradients`, and agreed to the following:
* `RESOLVED: We go with option 2 and worry about composability in the future`
<details><summary>The full IRC log of that discussion</summary>
<emeyer> SebastianZ: We had several discussion of how to bring stripes() syntax into gradients<br>
<emeyer> …There were three proposals initially, but the third was ruled out<br>
<emeyer> …So we now have two choices<br>
<TabAtkins> q+<br>
<emeyer> …Add the stripes() function to existing gradient functions<br>
<lea> q+<br>
<emeyer> …Or add new functions just for stripes<br>
<emeyer> …Both have pros and cons<br>
<emeyer> …Tab suggested option2, Lea said option 1, I think we should go with option 2 for now but keep discussing option 1<br>
<astearns> ack TabAtkins<br>
<emeyer> TabAtkins: My big question is whether we have a reasonable argument for making this easier to do<br>
<emeyer> …You can already do stripes in gradients, with a different syntax and with some more author work<br>
<emeyer> …The question is whether stripe images like this are common and complex enough that writing them in gradients as they are now is an impediment to authors<br>
<bramus> q+<br>
<fantasai> +1 to everything TabAtkins said<br>
<astearns> ack lea<br>
<emeyer> …I just don’t feel like it’s been established that there’s a big need for this in the authoring community<br>
<emeyer> lea: The whole point of defining stripes as a 1D image was that we intended to use them in other places in CSS<br>
<TabAtkins> q+<br>
<fserb> q+<br>
<emeyer> …Defining how 1D images can be used in place of gradient colors stops can be much more useful down the line<br>
<emeyer> …Defining ad-hoc gradient functions sets us up for having to define a lot of specific functions<br>
<emeyer> …Combining two concepts they already know is somethuing they might do accidentally<br>
<emeyer> …We could say that the stripes() function has to be in place of the color stops at first, and relax that later<br>
<emeyer> …I want to be able to talk about how 1D images should work<br>
<emeyer> …If we want to do something like this, there could be value in renaming stripes() to something more broad<br>
<emeyer> …Even in the border use case that started this, it’s weird to set a border to stripes()<br>
<astearns> ack bramus<br>
<emeyer> …maybe bands would be a better term<br>
<bradk> 'radial-gradient(stripes,' doesn’t seem better than 'radial-stripes('<br>
<emeyer> bramus: I always have to look up how to do this in existing gradients, and there are a lot of tools out there to do this properly<br>
<emeyer> …I’m leaning toward option 1, which seems nice to me<br>
<astearns> ack TabAtkins<br>
<emeyer> TabAtkins: The point of defining of defining 1D images was to have a concept for 1D images which are only useful for borders<br>
<emeyer> …The ability to re-use this for certain 2D cases was discussed but was not the reason we did it<br>
<argyle> q+<br>
<astearns> ack fserb<br>
<emeyer> fserb: First, I agree with when Bramus said about people trying to do stripes on gradients<br>
<emeyer> …Independent of what Tab said, I think option 1 looks better<br>
<emeyer> …What does the 100px in that option mean?<br>
<emeyer> SebastianZ: In my proposal it was the width of the stripes<br>
<lea> q+ also do we define conic-stripes too? repeating-*-stripes? Do we add new stripes functions for every new gradient function? It's a combinatorial explosion…<br>
<lea> q?<br>
<astearns> example: background-image: linear-gradient(45deg, black, stripes(red, yellow, lime, blue) 100px, white);<br>
<lea> q+<br>
<emeyer> …So that would be a 100px-wide areas for the stripes, so each stripe would be 25px wide<br>
<emeyer> …This is different to the color-stop syntax we currently have<br>
<emeyer> …My point was to make it easier to express a width for all the stripes<br>
<TabAtkins> I am indeed finding a bunch of "gradient stripe generators" from a quick search, so I wouldn't object to linear-stripes()/etc<br>
<emeyer> …We could use color-stop syntax as Oriol pointed out<br>
<emeyer> fserb: The syntax currently defines the image as proportional to whatever?<br>
<emeyer> SebastianZ: The current use cases are just for borders and outlines<br>
<emeyer> …There, it takes the border width into account<br>
<TabAtkins> lea, yes, we would do the full set.<br>
<fantasai> +1<br>
<emeyer> …So in this case, I wanted to say “let’s define a width for this”<br>
<emeyer> fserb: This seems like a generic problem of stripes<br>
<fantasai> s/+1/+1 to TabAtkins/<br>
<emeyer> …Maybe the linear gradient syntax is more consistent<br>
<astearns> ack argyle<br>
<argyle> https://shorturl.at/or689<br>
<lea> thought experiment: how would we do the opposite? How would we produce a <1d-image> that is a gradient? I'm not saying let's do it, but it's not entirely unthinkable, especially once <1d-image>s start being used all around (e.g. strokes, paths etc) We'd need to be consistent.<br>
<emeyer> argyle: I’ve been making alots and lots of stripes and it’s hard to find online the syntax easiest to manage<br>
<emeyer> …In the link I shared, I provided multiple stripe examples<br>
<lea> argyle: I created the whole technique of using CSS gradients for patterns back in 2010, so you are not alone here! :)<br>
<emeyer> …Would ths proposal fix some of the hard stop problems, allowing aliasing<br>
<emeyer> …Sometimes stripes aren’t even; sometimes the syntax is used to do easing<br>
<TabAtkins> q+<br>
<SebastianZ> q+<br>
<emeyer> …If we’re going for stripe convenience, I’d like to see aliasing as an option<br>
<astearns> ack fantasai<br>
<emeyer> fantasai: Want to support everything Tab said<br>
<emeyer> …If we’re going to add this, we should use option 2<br>
<bradk> +1 to #2<br>
<emeyer> …If we want to do a composable thing, then I think we should add linear-pattern and radial-pattern that are dedicated to establishing those patterns<br>
<emeyer> …Trying to shoehorn stripes() into gradient functions is awkward<br>
<smfr> +1<br>
<emeyer> …I don’t think it’s a good plan<br>
<astearns> ack lea<br>
<TabAtkins> (note, for example, that a repeating stripes, which would be great, isn't currently compatible with putting stripes() directly into repeating-linear-gradient() - the way that flex is defined is incompatible with the way that the repeating width is found<br>
<TabAtkins> )<br>
<fantasai> s/establishing those patterns/composing 1D patters, including 1D stripes() and gradient()/<br>
<emeyer> lea: Want to point out the proposal says we’ll define linear and radial stripes, but there’s more than that: conics, repeating gradients, maybe mesh gradients later on<br>
<astearns> ack TabAtkins<br>
<argyle> conic stripes https://shorturl.at/itzDR<br>
<emeyer> TabAtkins: To Adam, stripes() is not just about evenly-sized stripes<br>
<emeyer> …So long as they are solid-color stripes of some size, you’re good to go<br>
<emeyer> …The transition between color areas is not defined<br>
<SebastianZ> q-<br>
<emeyer> …I presume stripes would work similarly to linear gradients<br>
<emeyer> …That should be fine to allow, but it would be good to raise as an issue that we should say so in the spec<br>
<fserb> I wonder if we are going to end up defining a 1d-image gradient, to do linear-gradient(45deg, gradient(red, white)...)<br>
<emeyer> …The idea of just using stripes() directly in gradient functions<br>
<emeyer> …In some ways, it’s just incompatible, as with repeating gradients<br>
<emeyer> …You could not use a repeating-linear-gradient with a flex-defined stripe<br>
<emeyer> …The concepts are just different enough that they need special handling<br>
<emeyer> …That’s why I don’t think this is do-able in a generic way<br>
<fantasai> fserb, that's why I don't think we should shove this into the gradient functions. If we want composing the functions, we should add a composition function that's better suited to composing.<br>
<lea> q+ to reply to TabAtkins doesn't this depend on how the <1d-image> is used in the gradient? E.g. it could be used with two color stops, and treated as basically a black box (well, line)<br>
<fserb> fantasia, yeah, it makes sense.<br>
<fserb> *fantasai<br>
<emeyer> …Google shows there are a lot of stripe generators, so the need does seem to exist<br>
<fserb> argh<br>
<argyle> +1 to dedicated functions<br>
<bramus> +1 to that<br>
<emeyer> fserb: You mentioned a bunch of functions, but that’s different than what Elika said, right?<br>
<emeyer> fantasai: I was suggesting both; I think it’s convenient to have dedicated functions in parallel with gradient functions<br>
<SebastianZ> +1<br>
<lea> a composition function is more complex and confusing than either option, and we're just hoping it will save us complexity down the line…<br>
<florian> +1<br>
<emeyer> …If we want composable things, we need to define those<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to reply to TabAtkins doesn't this depend on how the <1d-image> is used in the gradient? E.g. it could be used with two color stops, and treated as basically a<br>
<SebastianZ> q+<br>
<Zakim> ... black box (well, line)<br>
<emeyer> lea: To Tab, who said stripes wouldn’t work with repeating gradient syntax, wouldn’t that depend on the syntax we choose??<br>
<emeyer> TabAtkins: Yes, that would work, but that would be the most complex and least justified of the syntax options<br>
<fantasai> +1<br>
<astearns> ack SebastianZ<br>
<emeyer> SebastianZ: I think fantasai’s suggestion is a good path forward<br>
<TabAtkins> the *-stripes() function family, paralleling gradients<br>
<fserb> I like composition functions more than stripe specific functions, but I agree that adding stripe support to gradient is not great.<br>
<emeyer> …Let’s introduce new stripe-gradient functions and later on, pursue a way to mix both stripes and gradients<br>
<emeyer> …At some point we could have in the image-1D data type some gradient function as well that could be used inside other patterns<br>
<TabAtkins> (these are basically just sugar for a gradient)<br>
<emeyer> …You could use both, having both gradients and stripes<br>
<emeyer> …So, option 2 for now<br>
<TabAtkins> Yeah, I'd prefer waiting on for a third example before we try to generalize.<br>
<fserb> that's fair too<br>
<emeyer> astearns: I think that’s about all we could resolve on today, absent any objection<br>
<bradk_> Straw poll?<br>
<emeyer> astearns: I’m not sure there’s sufficient enthusiasm to start that work<br>
<TabAtkins> +1 to adding *-stripe() functions<br>
<emeyer> …Are there any objections to adding the stripe function family, as in option 2?<br>
<bramus> Would be great for authors already<br>
<emeyer> (silence)<br>
<emeyer> RESOLVED: We go with option 2 and worry about composability in the future<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7244#issuecomment-1699543528 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 August 2023 17:02:58 UTC