[css-images-4][css-backgrounds-4] Added stripes() function #7029

SebastianZ · 2022-02-09T23:20:16Z

This change is meant to convert the resolution of #2532 into spec. text.

It adds the stripes() function as a generally usable function as discussed in #2532 to CSS Images 4.

Note that I changed the syntax slightly to incorporate the fr unit mentioned in @LeaVerou's description. I did that by adding the <flex> value defined in CSS Grid 1, though the definition there currently focuses on the usage within grid layout. So its description either might need to be changed/generalized or the unit needs to be defined again within CSS Images 4. I'd prefer to generalize it (and maybe even move it to CSS Values 4).

The stripes() function is then used as a replacement for the colors list defined for border-*-color in CSS Backgrounds 4.

Reading through the discussions, a few things were still unclear to me or were discussed but not resolved on.

What's the behavior when the width of the image the stripes() function is used in is smaller or bigger? I've defined that the rest is transparent when the stripes thickness is smaller and that the stripes are clipped when they are bigger than the image, as that seems to be what people were in favor of in the discussion.
Should the stripes be painted inwards or outwards? For now I kept the definition of "starting outwards", though to me it seems a bit counter-intuitive that the borders go inwards. Also, the wording may be clarified further.
Should there be a description of how stripes (or generally border-color) interact with border-style? Clipping was mentioned in the discussion, also treating inset, outset, groove, and ridge as solid.

Also note that this change is based on #7014, because without those changes Bikeshed won't compile the spec.

Sebastian

svgeesus · 2022-02-14T19:55:23Z

@LeaVerou @fantasai we resolved to add stripes() ages ago and the edit was not made, this PR looks like a good way forward?

LeaVerou · 2022-02-14T20:19:34Z

Hi Sebastian,

Thank you for working on this.
It has been a long time, but IIRC the resolution of these discussions, we would define 1 dimensional images, and stripes() would just produce a 1 dimensional image. Right now in CSS we have 2d images (gradients, urls etc), and 0 dimensional images (image(<color>)). I see that in this PR, stripes() is defined as its own type, and can only be used in properties that explicitly allow it. We'd like to be a bit more general than that.

SebastianZ · 2022-02-15T12:54:20Z

Thank you for reviewing the PR! There are obviously some open questions, so let's continue the discussion in the issue before we continue with this PR.

Sebastian

SebastianZ · 2022-03-16T10:49:17Z

@LeaVerou @tabatkins I went ahead and interpreted your statements in the issue to make the relevant changes. That means, I added <stripes()> to <image> and changed its description.

I also added it to outline-color as previously resolved on. I've kept the reference to <flex> for now. Though as pointed out earlier, I think its definition should be generalized and moved to a more general place to make it clear that it doesn't only apply to grid layout anymore.

I am awaiting your feedback on these changes.

Sebastian

SebastianZ · 2022-04-20T12:26:22Z

As noted by @LeaVerou, I've now put stripes() behind a <1d-image> type, so it can easily be reused and extended.

Open questions:

Is it ok to allow different orders in the syntaxes?
What to do with <flex>?

Sebastian

LeaVerou · 2022-04-20T15:03:27Z

I don't understand either of the two questions, could you please elaborate?

SebastianZ · 2022-04-20T19:19:37Z

* Is it ok to allow different orders in the syntaxes?

I used the double pipe in the syntaxes, i.e. <color> || <1d-image>. This allows the two values to be in any order.

That allows to specify something like border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue;.

We might use juxtaposing instead, i.e. <color> <1d-image> to force the order of first <color> then <1d-image>.

* What to do with `<flex>`?

As noted in a previous comment, I reused <flex> from CSS Grid 1 because I agree with you that it fits very well this use case.

Though, as it is now used in two completely different places, should it's description be generalized and be moved somewhere else? And if so, should that be done in this PR already?

Sebastian

LeaVerou · 2022-04-20T20:57:34Z

* Is it ok to allow different orders in the syntaxes?
I used the double pipe in the syntaxes, i.e. <color> || <1d-image>. This allows the two values to be in any order.

That allows to specify something like border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue;.

We might use juxtaposing instead, i.e. <color> <1d-image> to force the order of first <color> then <1d-image>.

Oh no, you need to use a single pipe: [ <<color>> | <<1d-image>> ]. It's a <color> OR <1d-image> but not both. It doesn't make sense to have border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue; because you can't tell what is for what side.

* What to do with `<flex>`?
As noted in a previous comment, I reused <flex> from CSS Grid 1 because I agree with you that it fits very well this use case.

Though, as it is now used in two completely different places, should it's description be generalized and be moved somewhere else? And if so, should that be done in this PR already?

Yeah, it should go to css-values. @fantasai @tabatkins ?

tabatkins · 2022-04-20T20:59:46Z

Yeah we can move <flex> out to the general V&U spec now that it's being used in more than just Flexbox. (I'll wait for merging of this PR tho.)

LeaVerou · 2022-04-20T21:09:41Z

Yeah we can move <flex> out to the general V&U spec now that it's being used in more than just Flexbox. (I'll wait for merging of this PR tho.)

Great, should we call it something else in that case? <fraction>?

fantasai

Overall looks pretty good. Posted some specific things to fix.

Also, the line-breaking convention for our specs is https://rhodesmill.org/brandon/2012/one-sentence-per-line/ (This is why the lines look so ragged, there's a method to the madness.)

(You might also find https://lists.w3.org/Archives/Public/spec-prod/2018OctDec/0011.html a useful read as background context, though nothing else there is particularly relevant to this PR.)

css-backgrounds-4/Overview.bs

fantasai · 2022-04-20T21:29:25Z

css-backgrounds-4/Overview.bs

+
+	The stripes are painted above a given <<color>>. This allows the <<color>>
+	value to serve as a fallback, so any transparent stripes let the color
+	shine through.

 	When interpolating between borders with the same number of colors,
 	interpolation is performed individually per color band as <a href="https://www.w3.org/TR/css3-transitions/#animtype-color">color</a>.


Interpolation should probably be defined in the definition of the stripes() function, rather than here. And it should match what we do for gradients.

I've moved it to the "Interpolation" section in CSS Images 4 and tried to align its definition with the one for gradients. @fantasai As those changes are bigger, please have a detailed look at it and let me know whether something needs to be changed!

Sebastian

css-images-4/Overview.bs

css-ui-4/Overview.bs

css-backgrounds-4/Overview.bs

tabatkins · 2022-04-20T21:56:59Z

I've done what turned out to be a decent bit of rearranging and rewording on the Images part. Largely editorial; the only normative changes are to handle sums of flexes < 1 the same way flexbox does, and define the painting area when used as a 2d image.

SebastianZ · 2022-04-21T09:43:35Z

* Is it ok to allow different orders in the syntaxes?
I used the double pipe in the syntaxes, i.e. <color> || <1d-image>. This allows the two values to be in any order.
That allows to specify something like border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue;.
We might use juxtaposing instead, i.e. <color> <1d-image> to force the order of first <color> then <1d-image>.
Oh no, you need to use a single pipe: [ <<color>> | <<1d-image>> ]. It's a <color> OR <1d-image> but not both. It doesn't make sense to have border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue; because you can't tell what is for what side.

I deliberately chose to allow both, so <color> serves as a fallback, as you noticed in an inline comment. border-color is one place where slashes would make it easier to distinguish between the different values like we have it for grid-area. So we could also express the syntax as:

<<color>>{1,4} | [ <<color>>? <<1d-image>>? ]! [ / [ <<color>>? <<1d-image>>? ]! ]{0,3}

That means, authors have to add the slashes when using <1d-image>, while the existing <color>-only syntax without slashes is still supported as legacy syntax. Applied to my example above, this would then look like

border-color: red stripes(white, silver) / yellow stripes(white, silver) / lime stripes(black, gray) / blue;

Sebastian

SebastianZ · 2022-04-21T09:49:25Z

Yeah we can move <flex> out to the general V&U spec now that it's being used in more than just Flexbox. (I'll wait for merging of this PR tho.)

Great, should we call it something else in that case? <fraction>?

As even Tab obviously mixed it up being part of Flexbox and not Grid, I'd say yes. 😉 Though I don't have a strong opinion on that.

And I agree with him that this should be done in a separate PR.

Sebastian

SebastianZ · 2022-04-21T09:56:54Z

Overall looks pretty good. Posted some specific things to fix.

Also, the line-breaking convention for our specs is https://rhodesmill.org/brandon/2012/one-sentence-per-line/ (This is why the lines look so ragged, there's a method to the madness.)

(You might also find https://lists.w3.org/Archives/Public/spec-prod/2018OctDec/0011.html a useful read as background context, though nothing else there is particularly relevant to this PR.)

Thanks for the links! I'll correct the line-breaking.

Sebastian

SebastianZ · 2022-04-21T10:39:05Z

I've done what turned out to be a decent bit of rearranging and rewording on the Images part. Largely editorial; the only normative changes are to handle sums of flexes < 1 the same way flexbox does, and define the painting area when used as a 2d image.

I missed that when answering the previous comments. @tabatkins Thank you for the changes! With those you obviously already covered a few things noted by @fantasai.

I'll incorporate the rest of the changes and we can discuss the points that are still open afterwards.

Sebastian

LeaVerou · 2022-04-21T15:12:40Z

* Is it ok to allow different orders in the syntaxes?
I used the double pipe in the syntaxes, i.e. <color> || <1d-image>. This allows the two values to be in any order.
That allows to specify something like border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue;.
We might use juxtaposing instead, i.e. <color> <1d-image> to force the order of first <color> then <1d-image>.
Oh no, you need to use a single pipe: [ <<color>> | <<1d-image>> ]. It's a <color> OR <1d-image> but not both. It doesn't make sense to have border-color: red stripes(white, silver) stripes(white, silver) yellow lime stripes(black, gray) blue; because you can't tell what is for what side.
I deliberately chose to allow both, so <color> serves as a fallback, as you noticed in an inline comment. border-color is one place where slashes would make it easier to distinguish between the different values like we have it for grid-area. So we could also express the syntax as:
<<color>>{1,4} | [ <<color>>? <<1d-image>>? ]! [ / [ <<color>>? <<1d-image>>? ]! ]{0,3}
That means, authors have to add the slashes when using <1d-image>, while the existing <color>-only syntax without slashes is still supported as legacy syntax. Applied to my example above, this would then look like
border-color: red stripes(white, silver) / yellow stripes(white, silver) / lime stripes(black, gray) / blue;
Sebastian

What kind of fallback? If stripes() is not supported, the entire declaration would be dropped, including the color.
If we want stripes() to accept an optional color to paint the stripes over, it should probably be part of the syntax for stripes(), not in each individual property's grammar as separate tokens. @fantasai any thoughts on this?

tabatkins · 2022-04-21T17:36:48Z

I don't know what the "color to paint the stripes over" is for, tbh.

LeaVerou · 2022-04-21T17:45:15Z

I don't know what the "color to paint the stripes over" is for, tbh.

No idea, but I assume that's what @SebastianZ intended for the fallback, a color to paint underneath any semi-transparent stripes. FWIW I don't think it's that necessary and complicates the syntax, so I'd be fine removing it.

SebastianZ · 2022-04-21T21:13:46Z

I don't know what the "color to paint the stripes over" is for, tbh.

No idea, but I assume that's what @SebastianZ intended for the fallback, a color to paint underneath any semi-transparent stripes. FWIW I don't think it's that necessary and complicates the syntax, so I'd be fine removing it.

Yes, the meaning of this "fallback color" was to let the color is drawn below any (semi-)transparent stripes. So, basically the same interaction as background-color with background-image. The idea behind that was that authors might expect that the <color> value still has an influence even when using stripes().

Though I'm happy to change the syntaxes to <color> | <1d-image> if we agree that this won't be the case and there are only use cases to have either <color> or stripes().

If we decide to use the either-or syntax instead, we should also clarify whether it's ok to stick with "transparent black" as fill color. See also @fantasai's related comment.

Sebastian

SebastianZ · 2022-10-09T19:42:22Z

As the comment list on this PR got quite long, let me summarize the pending points:

I've moved the definition for interpolating <1d-image> to Images 4.
I believe fantasai's suggestion to add dfn-for="stripes()" is not needed anymore after all the changes.
I've previously made a suggestion to add slashes between the different values in the border-color shorthand to align it with other shorthands and make it future prove which I'd like to get feedback on.
We agreed on moving <flex> to Values & Units (and possibly rename it to <fraction>) once this PR is merged.

@fantasai @tabatkins Could you please give this another review so the changes can be merged?

Sebastian

SebastianZ · 2022-09-12T06:14:41Z

css-backgrounds-4/Overview.bs

 	Animation type: see prose
 	</pre>

 	<pre class="propdef shorthand">
 	Name: border-color
-	Value: <<color>>#{1,4}
+	Value: [ <<color>> | <<1d-image>> ]{1,4}


@tabatkins @fantasai What do you think about my suggestion to distinguish the values for the different borders by adding slashes between them like in grid-area?

This makes the syntax more future proof, in my opinion.

Sebastian

For reference, here's the suggested syntax again:

<<color>>{1,4} | [ <<color>>? <<1d-image>>? ]! [ / [ <<color>>? <<1d-image>>? ]! ]{0,3}

And here's an example using that syntax:

border-color: stripes(white, silver) / stripes(white, silver) / stripes(black, gray) / blue;

SebastianZ · 2022-10-09T19:00:40Z

css-images-4/Overview.bs

+	The function represents a 1-dimensional image generated by a list of colors
+	and an optional thickness for each of them.
+
+	A <<percentage>> or <<flex>> value refers to the total length of the image
+	in the used context.
+	The <<percentage>> must be between ''0%'' and ''100%'' inclusive;
+	any other value is invalid.
+
+	If the thickness of a stripe is omitted, it is interpreted as ''1fr''.


I don't think this is still needed but please let me know if it is!

css-ui-4/Overview.bs

… for it

…xtensible

This was resolved on in w3c#2532 (comment).

Loirooriol · 2022-10-28T20:04:57Z

css-images-4/Overview.bs

+	If used generically as an <<image>>,
+	the |painting area| is the height of the [=concrete image size=].


What does "If used generically as an <image>" mean, if <1d-image> is no longer an <image>?

That was just a left-over. I've removed the whole paragraph now as it didn't add any additional information anymore.

Thanks for the hint!

You removed another used generically as an <<image>>, but not this one.

SebastianZ · 2022-11-06T00:03:34Z

I went ahead and merged the changes now as I believe all feedback was addressed and I waited for half a year for review.

I'll create separate issues for my suggestion to change the syntax of border-color and for generalizing the <flex> value. For reference, see my previous comment.

If there is still anything left, please let me know and I'll change it.

Sebastian

Loirooriol · 2022-11-06T21:42:12Z

css-images-4/Overview.bs

+	If the thickness is omitted,
+	it defaults to ''1fr''.
+
+	In each entry, a <<percentage>> is relative to the |painting area|


I think this is very confusing, the "painting area" is never defined but since it's an area it seems to be 2D. How to resolve a 1D <length-percentage> relatively to a 2D area?

Should this refer to the "length of the paint line" instead?

Loirooriol · 2022-11-06T21:45:59Z

css-images-4/Overview.bs

+	If used generically as an <<image>>,
+	the |painting area| is the height of the [=concrete image size=].


You removed another used generically as an <<image>>, but not this one.

Loirooriol · 2022-11-06T21:49:06Z

css-images-4/Overview.bs

+
+	2. Neither image uses a combination of <<length>>, <<percentage>>, and <<flex>> stripes.
+
+	If the two image satisfy both constraints,


If the two images

Loirooriol · 2022-11-06T21:51:39Z

css-images-4/Overview.bs

+		first match each stripe in the start image
+		to the corresponding stripe at the same index in the end image.
+		Then, for each pair of stripes,
+		interpolate the <a href="https://www.w3.org/TR/css3-transitions/#animtype-length">thickness</a>


How to interpolate a <length-percentage> with a <flex>?

Rather than checking that each image doesn't mix different types, should the requirement be that each pair of matched stripes have the same type?

SebastianZ added css-backgrounds-4 css-images-4 labels Feb 9, 2022

SebastianZ requested review from LeaVerou and fantasai February 9, 2022 23:20

SebastianZ force-pushed the stripes-function branch 2 times, most recently from c1ce848 to 119070c Compare March 16, 2022 10:06

SebastianZ requested a review from tabatkins March 16, 2022 10:43

SebastianZ mentioned this pull request Apr 20, 2022

Incorrect display of type definitions and references starting with digits speced/bikeshed#2262

Open

SebastianZ force-pushed the stripes-function branch 2 times, most recently from 8be979c to 8046368 Compare April 20, 2022 12:19

fantasai previously requested changes Apr 20, 2022

View reviewed changes

SebastianZ mentioned this pull request Sep 9, 2022

[css-backgrounds-4] Split CSS Backgrounds into separate specs? #7664

Closed

SebastianZ requested review from tabatkins and fantasai and removed request for LeaVerou, tabatkins, fantasai and bert-github October 9, 2022 19:48

SebastianZ commented Oct 9, 2022

View reviewed changes

SebastianZ and others added 12 commits October 9, 2022 21:56

Added stripes() function to CSS Images 4

99ff48a

Replaced colors list in border-*-color by stripes() function

72ff857

Rephrased stripes() and added it to <image>

e9b96b7

Added information about how to compute stripes()

aa6ccce

Added stripes() to outline-color and added computed value information…

5423bc7

… for it

Added stripes() function to Changes sections

6f450ab

Put stripes() definition behind a <1d-image> type to make it easily e…

f556965

…xtensible

tweak/rearrange stripes() text; add sum<1 behavior

1f982db

Removed <1d-image> from <image>

303dc90

This was resolved on in w3c#2532 (comment).

Made <color> and <1d-image> exclusive alternatives

a49e0a2

Incorporated fantasai's comments on stripes() and `<1d-image>

1b610f7

[css-ui-4] Fixed links to other specs in outline-color definition

eb59c87

SebastianZ force-pushed the stripes-function branch from fa2ec8b to eb59c87 Compare October 9, 2022 19:57

Loirooriol reviewed Oct 28, 2022

View reviewed changes

Removed left over paragraph describing <1d-image> in <image>

d316d16

SebastianZ merged commit 426ae64 into w3c:main Nov 5, 2022

This was referenced Nov 6, 2022

[css-borders-4] Add slashes between individual border-color values #8026

Closed

[css-values-4] Generalize definition of <flex> #8027

Open

Loirooriol reviewed Nov 6, 2022

View reviewed changes

SebastianZ mentioned this pull request Nov 18, 2023

[css-values-5] Centralized and generalized definition of fr unit in CSS Values 5 #9516

Open

		If used generically as an <<image>>,
		the \|painting area\| is the height of the [=concrete image size=].


		2. Neither image uses a combination of <<length>>, <<percentage>>, and <<flex>> stripes.

		If the two image satisfy both constraints,

[css-images-4][css-backgrounds-4] Added stripes() function #7029

[css-images-4][css-backgrounds-4] Added stripes() function #7029

Conversation

SebastianZ commented Feb 9, 2022

svgeesus commented Feb 14, 2022

LeaVerou commented Feb 14, 2022

SebastianZ commented Feb 15, 2022

SebastianZ commented Mar 16, 2022

SebastianZ commented Apr 20, 2022

LeaVerou commented Apr 20, 2022

SebastianZ commented Apr 20, 2022

LeaVerou commented Apr 20, 2022

tabatkins commented Apr 20, 2022 • edited Loading

LeaVerou commented Apr 20, 2022

fantasai left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SebastianZ May 4, 2022 • edited Loading

Choose a reason for hiding this comment

tabatkins commented Apr 20, 2022

SebastianZ commented Apr 21, 2022 • edited Loading

SebastianZ commented Apr 21, 2022

SebastianZ commented Apr 21, 2022

SebastianZ commented Apr 21, 2022

LeaVerou commented Apr 21, 2022

tabatkins commented Apr 21, 2022

LeaVerou commented Apr 21, 2022

SebastianZ commented Apr 21, 2022 • edited Loading

SebastianZ commented Oct 9, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SebastianZ commented Nov 6, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tabatkins commented Apr 20, 2022 •

edited

Loading

SebastianZ May 4, 2022 •

edited

Loading

SebastianZ commented Apr 21, 2022 •

edited

Loading

SebastianZ commented Apr 21, 2022 •

edited

Loading