[csswg-drafts] [css-line-grid-1] Clarifying / improving "Interacting with other alignments"

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-line-grid-1] Clarifying / improving "Interacting with other alignments" ==
https://drafts.csswg.org/css-line-grid/#alignment-interactions

This section proposes a solution to the problem that snapping lines to the grid may change the size of the element whose lines are being snapped, but changing its size may (depending on the layout mode and various parameters) change it's position, which affects where the lines should snap, which affects the size, causing a loop if we don't break out.

The solution outlined does seem like a step in the right direction, but I am not sure it is complete or well defined. I believe I understand what it does as long as all we're talking about are block level boxes that are also block containers,with no non-block formatting context in between, but if we step out of that, I am not sure I understand the proposal (and therefore cannot either agree or disagree). A few points to that effect:

* “An element can have additional block layout constraints” seems to understate the problem. An element may also be a block container without itself being block level, and other layout modes (flexbox, grid...) have inter dependencies between size and position, or between the size of siblings (and their positions).

* Relatedly, I am not sure what "Line snap as if the layout constraint does not apply / Apply the layout constraint to the block " means in the general case. Here are a few cases where I  am not sure what the steps are supposed to be. Not meant to be exhaustive, just illustrative.
  - a flexbox in column direction, with the line grid coming either from the flexbox itself or an ancestor, and applying to the flex items. The Flex Layout Algorithm first sizes the items, then places them. I cannot line-snap until I know where the items are supposed to be, and I cannot know where they are supposed to be until I know how large they are. Flex items may have auto-margins, justify-content may used flex-basis may be set to various values... What does it mean to "Line snap as if the layout constraint does not apply" then "Apply the layout constraint to the block"?
- What about a similar flexbox (column direction, with the line grid coming either from the flexbox itself or an ancestor, and applying to the flex items), where the first item has the `flex` property set to `1.5` and the second has it to `2.3`. Do the proposed steps say what we're supposed to do?
  - For an abspos, does it mean that if `top` is `auto` and `bottom` is not, first (layout and) line-snap as if `bottom` was `auto`, then shift the whole thing to the place `bottom` wants to put it at? That may seem like a good thing to do, but I am not sure it falls out of the proposed steps. If it doesn't, I am not sure what the steps proposed to do, if anything.

* In step 3 "Adjust exactly one line box shift or space at the beginning or end of the block such that all of the snapping lines meet the line grid while maintaining the block layout constraint. The single adjustment chosen must be the smallest shift needed to achieve the result without causing overflow." Overflow of what in what?
  - Is it of the line boxes in their block container? I think that it is not what it means, as I do not see how step 1 & 2 guarantee that there will be enough room for this shifting to be possible without growing the box.
  - if is of the block container, overflow with respect to what?If you're shifting up the lines from a bottom aligned abspos, that causes the abspos to grow taller. If that would make it overflow the viewport, is it allowed? Regardless of the answer for abspos.
  - If regardless of which type of overflow we're talking about, if you cannot do the shift without overflowing, what do you do?
 - Unless I am reading this wrong, this may cause the box to grow. In layout modes like flexbox, this kicks of a new round of layout, and we haven't broken the infinite loop.

All in all, maybe I am just reading it wrong (but if so, I'd appreciate editorial clarifications), but it seems to me that the section doesn't address the problem in the general case.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1856 using your GitHub account

Received on Tuesday, 10 October 2017 06:46:39 UTC