Open MatsPalmgren opened 2 years ago
After a quick read I'm generally a fan of this, it's a feature I know people really want in grid in particular. As mentioned in my comment on #6746 however, I'd like to see this specced along with block dimension overflow for multicol, which I'd like to do in Level 2 of the spec. I think from an author standpoint, the resulting column rows would be where the row gap would be expected. It's also possible to style spanners already with borders and margins whereas it won't be possible to style the gap between rows of column boxes.
Thank you again for the detailed proposal for gap decorations, @MatsPalmgren! I really love to see this feature getting traction.
I've read through the specification now and I wrote down all the things that came to my mind while reading. Some points are bigger, others smaller. Some are very general, some very specific and some are asking for clarification. I tried to group the points to make it a bit easier to go through them.
column-rule-image-slice
should be defined as relative to the height of the image, and on row-rule-image-slice
relative to the width of the image.column-rule-image-slice
and row-rule-image-slice
should be extended accordingly.column-rule-length
and row-rule-length
should be removed together with the auto
value of longitudinal insets properties.*-rule-position
properties similar to background-position
that are independent of the rule's width and define the alignment plus an offset within the rule containing rectangle in lateral axis. They'd then have a syntax like [ [ start | center | end ]? <length-percentage>? ]!
.column-rule
and row-rule
should include <'column-rule-image'>
resp. <'row-rule-image'>
. We missed to add <border-image'>
to the border
shorthand. We should do better here.rule-*
shorthands. And those should use the slash like the grid shorthands.gap-start
, gap-center
, gap-end
, rule-start
, rule-center
, and rule-end
. Also, *-rule-align
can be a bit misleading because they are actually influencing the size of the rule not aligning it. So they probably should have another name. I can't come up with a good one right now, though.*-rule-align
properties.*-rule-align
to ensure symmetry, i.e. an auto
value. Alternatively, this could be handled by adding shorthand that combines the *-rule-align
and *-rule-edge-align
properties that applies gap
, gap-center
, or gap-over
to all of them when set.all
keyword. It might even default to the most common one of the four values it can be combined with, so that you can use it alone.column-rule-extent: short
or long
in masonry layout as illustrated with those big gaps look weird to me. Though that's just me. Maybe there are use cases for that I don't see.column-rule-width
is missing <line-width>
as value.column-rule-width
and row-rule-width
regarding the handling of the auto
value.*-rule-edge-align
are meant to work. At the edges of a container there is no gap. Does it work like column-rule-inset
suggested by @fantasai and @mirisuzanne by assuming a gap?start
and end
values of the *-rule-extent
properties in grid containers.You see, I tried to provide detailed feedback. That's why the list may seem be a bit overwhelming. Though I hope it still helps the discussion and to push the spec. forward.
Sebastian
@SebastianZ Thanks for your detailed feedback - much appreciated! I'll reply inline below:
1. In regard of the complexity and scope of the proposal, I believe it deserves its own spec. instead of being added to Box Alignment.
I don't have an opinion on that - I'll leave it for the CSSWG to decide.
2. Whenever referring to an image's measurements, this should be done by using width and height, or x and y, as they are not flow-relative.
If you're referring to the row/column-rule-image-slice
properties specifically: I believe the spec is correct, although it might be a bit confusing that the spec talks about the block axis for column-rule-image-slice
and then, at the end, says that "row-rule-image-slice
works the same but in the inline axis", when the axis we describe in both cases is the rule's longitudinal axis! I've changed that so hopefully the intention is a bit clearer now.
1. Percentages on `column-rule-image-slice` should be defined as relative to the height of the image, and on `row-rule-image-slice` relative to the width of the image.
Again, the slicing is always done in the rule's longitudinal axis, so it's neither flow-relative, nor physical. I've changed it to refer to the image size in the longitudinal axis instead.
2. Depending on the outcome of [[css-backgrounds] accept "px" for pixel values in border-image-slice #6739](https://github.com/w3c/csswg-drafts/issues/6739) the syntax for `column-rule-image-slice` and `row-rule-image-slice` should be extended accordingly.
Thanks for the heads up. We can add that after it's added to the css-backgrounds spec.
3. I think we concluded previously that defining an inset is better than an explicit length. So `column-rule-length` and `row-rule-length` should be removed together with the `auto` value of longitudinal insets properties. 4. The functionality of the lateral inset properties in combination with the rule width is rather complicated, in my opinion. I'd rather introduce `*-rule-position` properties similar to `background-position` that are independent of the rule's width and define the alignment plus an offset within the rule containing rectangle in lateral axis. They'd then have a syntax like `[ [ start | center | end ]? <length-percentage>? ]!`. 5. With the removal of the lateral inset properties, the word 'longitudinal' could be removed from the longitudinal inset property names. Besides then being unnecessary, it's a relatively long and complicated word.
I honestly think that the model I propose is simpler than specifying both an alignment and an offset relative to that anchor point. What you suggest is basically just merging the *-inset-start/end
properties into one property with a more complicated set of values instead.
It seems easier to learn a sizing model that we already use in other places in CSS, for example the left/width/right
properties for abs.pos. or even margin-start/width/margin-end
for block layout etc are very similar to the triplet of inset-start/column-width/inset-end
I propose.
I also use the same model is used in both axes -- it's completely symmetrical.
I also think it's more expressive -- without lateral inset properties you have to resort to column-rule-width: calc(100% - <inset>)
in some cases, which seems more complicated to me.
I agree the word 'longitudinal' is a rather long though... I discussed this with @dholbert , but we couldn't think of a better replacement for lateral/longitudinal.
Again, I think the sizing model I propose is simpler for two reasons:
I think this will make it easier for authors to learn than having a separate model for each axis.
I've added more examples to these sections in an attempt to make it a bit more pedagogical... I suspect that any perceived complexity is likely just that the spec doesn't explain it in a pedagogical way, but that's something we can fix hopefully.
6. `column-rule` and `row-rule` should include `<'column-rule-image'>` resp. `<'row-rule-image'>`.
If we add px
values to *-rule-image-slice
then column-rule: 10px
is ambiguous since it could also be a <line-width>
. We would have to be very careful with any future changes to the longhand values to avoid ambiguities, so I'm not sure it's worth it... I'm leaning towards not including them...
8. [...] I'd name the values for the rule alignment properties `gap-start`, `gap-center`, `gap-end`, `rule-start`, `rule-center`, and `rule-end`.
That would be rather confusing since start/end
typically refer to the logical sides of an axis. So does gap-start
refer to the nearest edge of the gap or does it refer to the gap edge closest to the start of the axis? (which can be different edges)
I note that @fantasai /@mirisuzanne used the words nearest
/farthest
... I guess gap-near/gap-far
would be an alternative to gap/gap-over
that I use.
I'll stick to gap/gap-over
for now - they're short and reasonably clear IMO.
Also, `*-rule-align` can be a bit misleading because they are actually influencing the size of the rule not aligning it. So they probably should have another name.
We already have for example align-self:stretch
that also affect the size, so I don't see that as a problem.
9. The functionality of the longitudinal inset properties might also be combined with the one of the `*-rule-align` properties. 10. In addition to the above, I'd say, they should default to use what's defined for `*-rule-align` to ensure symmetry, i.e. an `auto` value. Alternatively, this could be handled by adding shorthand that combines the `*-rule-align` and `*-rule-edge-align` properties that applies `gap`, `gap-center`, or `gap-over` to all of them when set.
I think it's simpler to have separate properties for separate concerns. I also suspect that combining them would make it less expressive.
13. I also question whether all the different ways to style the extent are needed.
That's fair. I don't know what's useful to authors so I basically just added all possibilities :-)
16. [...] I heard from implementers (I think also Mozilla in the past), they are reluctant extending their table layout mechanisms.
Right, but what we're concerned about are changes to table layout. This feature does not affect layout at all, it's purely an addition to the painting phase, so it isn't a big deal to support tables IMO.
Editorial / questions
1. `column-rule-width` is missing `<line-width>` as value.
That's intentional, column-rule-width
is an existing property so this spec defines an extension (hence "New values"), so existing values are not listed.
2. There should be a note after the definition of `column-rule-width` and `row-rule-width` regarding the handling of the `auto` value.
OK, I added a reference to the section about "resolving a rule’s position and size".
3. It's not clear to me yet how `*-rule-edge-align` are meant to work. At the edges of a container there is no gap.
If you have an explicit width/height that is larger than the tracks then you get spacing at the edges.
See for example space-around
here: https://drafts.csswg.org/css-align-3/#distribution-values
4. It's not clear to me what is meant by the 'start-most' and 'end-most' track in the definition of the `start` and `end` values of the `*-rule-extent` properties in grid containers.
By "start-most" I meant the first track at the start of the axis. I changed it to use first/last instead - hopefully that's clear enough...
5. [...] in example 21 the column rule is painted below the border in the upper element
No, it's a blue border that is semi-transparent, but you're right it's a bit hard to see. I've updated the example.
and both are painted below the border in the lower element.
No, that grid has overflow: hidden
so the rules are clipped at the padding edge.
I've made the container's border dotted
, hopefully that makes it a bit clearer.
Again, thanks for all the feedback!
(I've updated the draft spec.)
I'm thinking if there shouldn't be some extra, more logical properties, like *-block-end
is for *-bottom
. I'm notably thinking about flexbox axes, which can change responsively.
Have column-*
and row-*
get a shortcut gap-*
(I don't think this causes any issue with the current gap
property, which can act as a shortcut itself for gap-*
properties).
Add to that gap-main-*
and gap-cross-*
that would generally correspond to column-*
and row-*
except for flex-direction: column
, where the axes swap.
@Wolfeur wrote:
I'm thinking if there shouldn't be some extra, more logical properties, like
*-block-end
is for*-bottom
. I'm notably thinking about flexbox axes, which can change responsively.
Please let's discuss adding logical properties for them in its own issue! The initial proposal is already huge and I suspect the introduction of logical properties may require some separate discussion.
Have
column-*
androw-*
get a shortcutgap-*
(I don't think this causes any issue with the currentgap
property, which can act as a shortcut itself forgap-*
properties).
This was my initial proposal in issue #2748.
Add to that
gap-main-*
andgap-cross-*
that would generally correspond tocolumn-*
androw-*
except forflex-direction: column
, where the axes swap.
I am against adding specific property names as aliases just for one type of layout they're used in, even when "column" and "row" may not make sense in some situations. Note that the properties introduced here are meant to apply to grid, flexbox, multi-column, and table layout.
Sebastian
Hey all! I'm looking for the most up-to-date info on progress here. I see this issue hasn't been updated in about a year - is there a more appropriate place to look?
This is a concrete proposal for a gap decorations feature that covers the use cases and ideas discussed in the issues #2748 and #5080. (I've made a prototype implementation of this in Gecko to ensure it's feasible to implement.)
I'd appreciate any feedback you might have on this proposal in this issue. Thank you.