- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Fri, 05 Nov 2021 23:16:14 +0000
- To: public-css-archive@w3.org
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. # General 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. 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. # Specifications 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. 2. Depending on the outcome of https://github.com/w3c/csswg-drafts/issues/6739 the syntax for `column-rule-image-slice` and `row-rule-image-slice` should be extended accordingly. 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. 6. `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. 7. Regarding issue 1, I tend to say yes, we should add `rule-*` shorthands. And those should use the slash like the grid shorthands. 8. Again some name bikeshedding, though I'd name the values for the rule alignment properties `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. 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. 11. Regarding issue 2, I believe there should be padding-related options. 12. Regarding issue 3, I'm definitely for a separate `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. 13. I also question whether all the different ways to style the extent are needed. For example, the results of `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. 14. Regarding issue 5, I strongly believe that should be possible. The examples look compelling to me and I think that's something authors would expect as the normal behavior. Related to this, I think the terminology is a bit mixed up here. I think you meant intersecting 'grid cell spans' instead of 'tracks'. Also, that seems to apply to normal grid layout as well. 15. Related to the above, it confuses me a bit that example 9 and the paragraph above it say that rules are also drawn between empty grid cells. Though in issue 5 they don't. In my opinion, rules should not be drawn between empty cells by default but there should be a way to control that. 16. I'd really, really love if all those properties also applied to table layout, though as far as I heard from implementers (I think also Mozilla in the past), they are reluctant extending their table layout mechanisms. This could have changed in the meantime and I might be wrong here, though if that's the case, gap decorations also applying to table layout should be moved to level 2 of the spec. in order to get this feature quickly into UAs. # Editorial / questions 1. `column-rule-width` is missing `<line-width>` as value. 2. There should be a note after the definition of `column-rule-width` and `row-rule-width` regarding the handling of the `auto` value. 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. Does it work like `column-rule-inset` suggested by @fantasai and @mirisuzanne by _assuming_ a gap? 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. 5. The rule painting order specifies that rules are painted above an element's border, though in example 21 the column rule is painted below the border in the upper element and both are painted below the border in the lower element. 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 -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6748#issuecomment-962273499 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 5 November 2021 23:16:16 UTC