- From: Mats Palmgren via GitHub <sysbot+gh@w3.org>
- Date: Sat, 18 Dec 2021 17:55:17 +0000
- To: public-css-archive@w3.org
@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: 1. it's similar to existing sizing models in CSS 2. it works the same way in both axes 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](https://matspalmgren.github.io/css-gap-decorations/Overview.html).) -- GitHub Notification of comment by MatsPalmgren Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6748#issuecomment-997238558 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 18 December 2021 17:55:19 UTC