[css-multicol] image support for column rules

[MatsPalmgren]

From the discussion in #2748 it seems that image support for column rules is a requested feature.
I propose to add three new properties to support that:

• column-rule-image-source: none | <image>
• column-rule-image-slice: [<number [0,∞]> | <percentage [0,∞]>]{1,2} for slicing the image into three regions. The initial value, 0, makes the whole image fill the rule area as specified by column-rule-image-repeat. A non-zero value defines an area at the start/end of the rule area that isn't stretched (as demonstrated in the testcase below).
• column-rule-image-repeat: stretch | repeat | round | space

Here's a testcase demonstrating these properties. And here's a video of how it would render.

I think we can start with these properties for now and consider column-rule-image-width/outset at a later stage. They seem less important and I'd prefer to look at the column-rule-extent / column-rule-inset in #2748 first, in case those might affect the decision/design.

(If we decide to add row-rule-* properties in #2748 then these three properties should also be added in that axis of course.)

Fwiw, the above three properties should be fairly easy to implement in UAs that already support the corresponding border-image-* properties since you can leverage existing rendering code for those.

[fantasai]

Agree with using the border-image model as a basis. But I think we should figure out how it's going to work with an intersected grid (#2748) before finalizing on anything, since we don't want to come up with something here that won't be exactly portable to Grid.

[astearns]

The working group discussed this today, and decided to keep the discussion going here and in #2748 to see how this would work with grid

Topic: [css-multicol] image support for column rules
fantasai: Need to figure out grid before we resolve it. Proposal is in right direction, but need to figure out intersections and how they fit together
astearns: Any opinions or ideas on how to work with grid?
AmeliaBR: Clarification- If someone wants to slice an image so column rules and row rules have nice overlap. THat is a lot more complicated than proposal
AmeliaBR: Do we have general interest in proposal with details TBD?
fantasai: I think a fair amount of interest from authors. If interest from impl we should tyr and have it. BUt since we haven't figured out intersections we shouldn't add this. Shouldn't block into a place where we can't make intersections work
fantasai: WE should let discussion continue until we have proposal for all layout modes with this kind of rules. We can than subset but we should solve intersections and spanning elements to the point where we know we can make it work
fantasai: Also don't think this is particularly urgent
rachelandrew: I don't hear lots of requests in multicol. Yes in grid, but not constantly asked for in multicol
astearns: Let's go back to github

[SebastianZ]

I was playing a bit more with the thought of how intersections could be handled. I did so from a design point of view. Once all questions are clarified, I'm happy to express this in syntax form.

Here's what I came up with so far:

• The rules are sliced into three parts, a start part, a middle part, and an end part, similar to border images, as @MatsPalmgren outlined above.
• The extent of a rule is defined by an inner and an outer part, which are independent from each other.
  • The inner part is specified by how intersections of gaps are handled and how they align to each other.
  • The outer part is specified by either the content or the content box.
• There are three ways for how intersections can be handled:
  1. Keep them empty, i.e. only extend the rules up to the segment edges.
  2. Extend the rules up to where they intersect.
  3. Ignore interections and let the rules extend over the whole content. (This option probably only makes sense if all gaps extend over the whole content, i.e. in grid layout, otherwise they would be cut off in the middle.)
• Horizontal and vertical rules are handled individually, also in regard of their extent.

Examples

I have created some mockups to illustrate the different types of extents. The colors and patterns are just for illustration purposes, so please bare with me!

Some general notes on them: All the examples paint the horizontal rules above the vertical ones and their middle part is repeated.

Extend up to center of gap

Grid layout, no outer extent:

Masonry/Flexbox layout, no outer extent:

Extend up to edge of segment

Grid layout, no outer extent.

Extend over whole content

Grid layout, no outer extent.

Extend over whole content box

Grid layout.

Open questions

• When rules are overlapping, it needs to be defined whether the horizontal or the vertical rules are painted last, and if that is also something that should be controllable by authors.
• When applied to Flexbox or Masonry layout, it needs to be clarified whether the rules extend up to the longer or the shorter tracks. (In my example I chose the longer one.)
• When extending over the whole content and ignoring intersections, it needs to be specified whether they always extend over the whole content or only up to next T-intersection. (In the examples they only extend up to the T-intersections.)
• It needs to be defined how gap images of different widths are handled in regard of the intersections when extending them to the center of the gap.

I surely missed a few questions. So please let me know when there are more things that need clarification.

Sebastian

[design1online]

Additional Questions

• What happens when your image is wider than the row or column gap? Can you tell the image to overlay on top of the elements or below? Should the user be able to control how it overlays or should it only be considered as a background-image? For instance, let's say you have a Pinterest board and when you pin an item you want to highlight that row and have an icon appear beside it that also overlaps the element.
• What if you wanted to be able to visualize each row or column that a grid element spans? With this you cannot tell if the first column is 1 col wide or potentially 5 cols wide unless this is intended to show every column that isn't spanned by an element.
• What if you wanted to do an alignment? Left, right, middle within the column or row? What if you wanted an alignment within the row/column gap?
• Does this also work with nested grids?
• Is there a way to control which items get row/grid lines. For instance:

item   |   item   |   item
----------------------------
blankblank....... |   item

Or in the case where you want it only on a single item in the row:

item | item | item
            ------
            | item

Or in between two items:

item | item | item
---------------------
     | item |

Or for another example:

item | item | item
     -------
     | item |

Sebastian, to your point:

When rules are overlapping, it needs to be defined whether the horizontal or the vertical rules are painted last, and if that is also something that should be controllable by authors.

Could this be determined by setting a z-index value?

[SebastianZ]

Additional Questions

• What happens when your image is wider than the row or column gap? Can you tell the image to overlay on top of the elements or below? Should the user be able to control how it overlays or should it only be considered as a background-image?

I guess @MatsPalmgren's suggested border-image-like representation clips wider images to the gap area. Though that would be influenced by column-rule-image-width and column-rule-image-outset, so yes, that needs to be defined.

For instance, let's say you have a Pinterest board and when you pin an item you want to highlight that row and have an icon appear beside it that also overlaps the element.

• What if you wanted to be able to visualize each row or column that a grid element spans? With this you cannot tell if the first column is 1 col wide or potentially 5 cols wide unless this is intended to show every column that isn't spanned by an element.

• What if you wanted to do an alignment? Left, right, middle within the column or row?

I am not totally sure regarding some of those questions, but I think all of them rather go in the direction of being able to style grid areas, which is discussed in #4416, and not the gaps.

What if you wanted an alignment within the row/column gap?

That could be achieved by having the alignment within the image, but what are the use cases for different alignments than centering?

* Does this also work with nested grids?

Using subgrids I'd say so, though it needs to be defined how they behave.

* Is there a way to control which items get row/grid lines. For instance:

item   |   item   |   item
----------------------------
blankblank....... |   item

Or in the case where you want it only on a single item in the row:

item | item | item
            ------
            | item

Or in between two items:

item | item | item
---------------------
     | item |

Or for another example:

item | item | item
     -------
     | item |

Regarding those examples, it seems to be a question of whether to always draw the rules or only between items. And I agree that both may have use cases.

One use case for a having the rules be drawn when they don't have adjacent content can be seen at https://sea-visualcommunication.design/uploads/9/8/6/6/98662420/cn-07112018-a01_orig.jpg.

Sebastian, to your point:

When rules are overlapping, it needs to be defined whether the horizontal or the vertical rules are painted last, and if that is also something that should be controllable by authors.

Could this be determined by setting a z-index value?

To be able to set a z-index, the gaps would need to be defined as pseudo-elements. The current proposal goes a different way and defines the gaps via properties. So in order to allow controlling which one is painted last a new property would need to be defined that specifically does that.
But there's still the question of whether there are use cases for being able to control that.

Sebastian

[fantasai]

Using Sebastian Zartner's diagrams of grid line intersection options, @mirisuzanne and I sketched out a few syntax proposals which we posted in #2748.

See #2748 (comment)

Putting it all together, we'd have the following syntaxes for gap styling (with row-/column-/unprefixed variants for each):

/* Existing Properties */
column-gap: normal | <length-percentage>
column-rule: <color> || <line-style> || <line-width>
  column-rule-color: <color>
  column-rule-style: <line-style>
  column-rule-width: <line-width>

/* Proposed Properties */
column-rule-extent: span-skip | no-skip | span-break | corner-break
column-rule-inset: nearest | center | farthest | <length>
column-rule-image: <border image syntax but with only one axis>
  rule-image-source: none | <image>
  rule-image-slice: [ <number [0,∞]> | <percentage [0,∞]> ]{1,2}
  rule-image-width: [ <length-percentage [0,∞]> | <number [0,∞]> | auto ]
  rule-image-outset: [ <length [0,∞]> | <number [0,∞]> ]{1,2}
  rule-image-repeat: [ stretch | repeat | round | space ]

What do people think?

[MatsPalmgren]

@SebastianZ @fantasai I've posted a concrete proposal for this feature in #6748 which includes image support and other features discussed in #2748. I'd love to hear your feedback on that. I didn't see @fantasai's proposal above until now, but I think it should cover those cases and more...

[SebastianZ]

@MatsPalmgren Thank you for creating the concrete proposal and the prototype implementation! That's really awesome! I'll provide more feedback in #6748 once I had the time to read it more carefully.

Sebastian

[SebastianZ]

@fantasai @mirisuzanne Thank you for your syntax proposal, as well! It looks really promising.

I'll provide more general feedback in #2748. Though I have a one note regarding the image support. I feel like column-rule should be extended to also include column-rule-image. I always found it a little awkward that border-image trumps border (or more precisely border-image-source and border-style) and that it's not part of the border shorthand.

So could column-rule be defined like that?

column-rule: [ <color> || <line-style> || <line-width> ] | [ <'column-rule-image'> || <'column-rule-inset'> || <'column-rule-extent'> ]

Sebastian

[tabatkins]

border-image uses a 9-slice to give you complete control over all the relevant changeable areas - the four corners, and the four stretchable/repeatable sides. Using these 8 areas, you can do fancy things like scrollwork; the syntax was explicitly designed to allow these sort of uses.

But rules in a grid have a different set of areas - they've got only two stretchable/repeatable bits (horizontal and vertical), but seventeen possible fixed images - the four endcaps (top, bottom, left, right), then the four 1-way intersection, the four 2-way intersections, the four 3-way intersections, and the single 4-way. Only using 6 regions (row-* and column-* each specifying 3) doesn't account for any of the intersection areas.

We do have the advantage that all the missing intersection regions are the same size, so specifying them is potentially relatively easy, with a separate image that gets implicitly sliced into 13 regions (4 1-way, 4 2-way, 4 3-way, 1 4-way). We can just say they must be stacked vertically, for instance. This would be provided by a separate property from the row-gap-image and column-gap-image; if it wasn't specified, you would just overlay the repeat bit of the row and column images in some way.

---

I also don't think we need the full complexity of border-image. It's designed in a slightly funky way to deal with the fact that border-width is layout-affecting, but the border-image might want to be smaller or larger than that border region, and extend both further in or further out than the inner/outer border edges. Gaps have a much simpler sizing model to deal with.

On the other hand, we have a physical/logical mismatch with gaps that doesn't exist with borders. Borders are specified physically (you can now use logicals, but physical is always an option) and the border-image directions are physical as well. But gaps are inherently logical; we'd have to autorotate images to make that work, which is (a) somewhat weird, and (b) favors one orientation as the "default"; vertical writing modes would have to author a "sideways" image which is then rotated into the actually-used orientation.

Both of these suggest that we actually need do something relatively different from border-image to get gap images.

Here's an initial sketch:

gap-image-x-source: none | <image>
gap-image-x-slice: [ <number> | <percentage> ]{1, 2}
gap-image-x-width: <length-percentage> | auto
/* analogous gap-image-y-* properties */

gap-image-cross-source: none | <image>
gap-image-cross-size: [ <length-percentage> | auto ]{1,2}

The gap-image-x/y-* properties define the stretchy part of the gap line, and the end caps.

• -source is self-explanatory.
• -slice specifies how to slice the image into 3 pieces (an endcap, a mid area, and an endcap), along the given axis. If only one length is given, it measures equally from either side (that is, it's (100% - len)) (initial 0)
• -width sets the size of the image, perpendicular to the given axis. auto uses the image's natural size. %s are relative to the gap size. (initial auto)

The gap-image-cross-* properties set the images used for when gap rules cross. The image is automatically sliced into 13 equal vertically-stacked sub-images, used for the 4 1-way intersections, 4 2-way intersections, the 4 3-way intersections, and the 4-way intersection. The size sets the size: again, auto uses the natural size of the image, and %s are relative to the appropriate gap width.

These interact with the existing+proposed gap-rule properties:

• *-rule-extent determine whether you use crosses or endcaps, depending on whether there's a break, a skip, or neither.
• *-rule-inset determines the size of the gap image area along the axis.

I think, then, that the endcap images are used against breaks, with the mid image between them. When gaps intersect without a break, the mid image goes up to the edge of the intersection, and the appropriate -cross- image is used inside the intersection area, depending on what skip behavior is being used, and how the gaps are intersecting. (In a normal grid, no-skip always uses the 4-way intersection, while span-skip can use any of them, depending on which sides of the intersection are spanned. In a flexbox/masonry, I think they'd only use the 3-way intersections?)

(Ugh, I didn't consider that intersection areas can overlap in flexbox and masonry. Not sure what to do about that. Maybe they just plain overlap, and you shouldn't use images that would look bad in that situation when using masonry or flexbox gap images.)

(If you only use a gap image in one axis (x or y, not both), then I think we only use the cross images when you'd trigger a skip in that axis. Otherwise we just stretch across the intersection area. That is, consider a horizontal multiline flexbox. With an -x-image, filling the flex-line gaps, you'd never trigger a skip, so it's always either one continuous rule, with one endcap on each end, or a bunch of rules triggered by breaks, each still only made of endcaps and stretch. With a -y- image, on the other hand, it'll be a bunch of 1-way intersections as the item-gap images extend into the line-gap intersection area.)

Gap images are always centered in the appropriate way; horizontal/vertically for the -x- and -y- images, and centered in both axises for the -cross- images.