Thoughts on line grids and line spacing proposals

# L. David Baron (7 days ago)

After the discussion in Paris that we had about CSS Rhythm and other line spacing issues [1], I decided to write down a bit more detail about both:

(a) fleshing out the proposal I made there about using the ideas from line-box-contain for a better line spacing model, and

(b) my thoughts on the existing proposals around line grid and rhythm, and which pieces of each could be taken to form a first version to address the use cases that motivated these drafts.

I've thus written this document: dbaron/css-line-spacing/blob/master/explainer.md with some background, and thoughts on how we might combine pieces of these proposals.

I think this may be worth talking about when we meet at TPAC in a little over a month, but I'm also happy to get feedback before then. Probably github issues in the repository [2] work for feedback, although they're not necessarily particularly permanent since the document may end up moving.

-David

[1] lists.w3.org/Archives/Public/www-style/2017Sep/0003.html [2] dbaron/css-line-spacing/issues

Contact us to advertise here
# Florian Rivoal (2 days ago)

Thank you, this is very interesting. The feedback I have is more comments than issues, so if you don't mind I'll send it here. If you'd rather have it some place else (github?), let me know and I'll refile it.

  • Overall I like this. I had internalized the line grid as two properties, so initially having it in one was a bit unsettling, but I've now gotten over it, so this has probably more to do with habit than anything else.

  • The major issue I am seeing with this proposal is that it doesn't seem to do anything to address what was already the primary weakness of the existing line-grid proposal: snapping lines to the grid can change (increase) the size of their container, and in some layout modes, changing its size can change its position, which should imply a different snapping, and unless we explicitly break out of this one way or another, we've good an infinite loop.

One way to work around that might be to have "auto" not propagate the line grid down through these kinds of formatting context (i.e. not to grid items, flex items, table cells). This lets us have a level 1 that works in many scenario, and is considerably simplified in terms of spec and implementation. Later, when we have figured out how to make these various layout mode work without infinite loop, we add another explicit keyword (snap?) that does the same as auto AND goes through these formatting context boundaries.

Even if we can find a solution to this soon, unless it is also simple to implement, we may still need this simplification to auto and this separate keyword: the feedback I had from potential implementers was that the probable complexity of dealing with these position<->size dependencies was likely to push the complexity of the feature over what was acceptable to schedule in a release cycle.

  • I think I understand what you mean with the new line height calculation, and it seems right, but I'd need to see more detailed text. There's plenty of room for subtle differences on line height.

  • I think the new line calculation you propose should be possible to turn on without the line grid. It would allow authors to reduce unwanted jitter on the line height, which is almost always what people would want, without opting into the line grid and its visually disruptive gaps which may not always be desired.

  • I don't miss most of what you're proposing to drop/simplify away, but it seems to me that what block-step-insert does is worth preserving. When you have block quotes, figures, or other sort of intrusions where you'd use line-grid:none with some align-self value, if the box has a background or a border, whether the extra space should go around the box (margins) or expand the box (paddings) seems like a purely subjective author choice. Maybe these two effects can be achieved by align-self:end vs align-self:stretch; align-content: end

Best

# Alan Stearns (2 days ago)

On 10/9/17, 8:15 PM, "Florian Rivoal" florian@rivoal.net wrote:

  • The major issue I am seeing with this proposal is that it doesn't seem to do anything to address what was already the primary weakness of the existing line-grid proposal: snapping lines to the grid can change (increase) the size of their container, and in some layout modes, changing its size can change its position, which should imply a different snapping, and unless we explicitly break out of this one way or another, we've good an infinite loop.

Please read drafts.csswg.org/css-line-grid/#alignment-interactions for a solution to this problem. One spacing adjustment to deal with size and position changes should be sufficient to break out of the loop. There are examples showing how this is done for centered and end-aligned content in the draft, but if you have other concerns I’m happy to work out additional examples to add.

Thanks,

Alan

# Florian Rivoal (2 days ago)

On Oct 10, 2017, at 13:27, Alan Stearns stearns@adobe.com wrote:

On 10/9/17, 8:15 PM, "Florian Rivoal" florian@rivoal.net wrote:

  • The major issue I am seeing with this proposal is that it doesn't seem to do anything to address what was already the primary weakness of the existing line-grid proposal: snapping lines to the grid can change (increase) the size of their container, and in some layout modes, changing its size can change its position, which should imply a different snapping, and unless we explicitly break out of this one way or another, we've good an infinite loop.

Please read drafts.csswg.org/css-line-grid/#alignment-interactions for a solution to this problem. One spacing adjustment to deal with size and position changes should be sufficient to break out of the loop. There are examples showing how this is done for centered and end-aligned content in the draft, but if you have other concerns I’m happy to work out additional examples to add.

Hi Alan,

You are right, I should have mentioned this existing proposal. As far as I can tell, the problem is the same in both variants of the line grid, so the solution should be the same. Workarounds like the keyword separation I suggested may be different, but the actual solution ought to be the same.

As for this specific proposal, you have pointed me to in in the past, and I have not reported back with either satisfaction or issues. Apologies, that was very bad form.

I do have issues with the solution outlined in that section of the line-grid. It does seem like a step in the direction of a solution, but I am not sure it is complete or well defined. Maybe I am just not understanding it fully, though. Anyway, whether it should be resolved or explained away, I have a issue about that, and this discussion can continue there. As it applies equally to the existing line-gird and to dbaron's proposal, here isn't the best place to discuss this. Sorry for not filing this issue a year (or more) ago.

w3c/csswg-drafts#1856

—Florian

# Ian Kilpatrick (16 hours ago)

I filed a few issues, but there are a lot of subtle issues wrt. positioning a non-BFC post-layout (and existing issues with how to position new-FCs but that is a separate compat issue).

This is probably better as an in-person discussion, (it may also help to talk about how blink is going to perform block-layout in the future, which may clarify why some of these things are difficult - I'm happy to have a break-out on this if there is interest and people would find it valuable).

Want more features?

Request early access to our private beta of readable email premium.