W3C home > Mailing lists > Public > www-style@w3.org > October 2017

Re: Thoughts on line grids and line spacing proposals

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 10 Oct 2017 12:11:08 +0900
Cc: www-style@w3.org
Message-Id: <94308B6C-46F8-4979-ADC6-957C16BF73C6@rivoal.net>
To: "L. David Baron" <dbaron@dbaron.org>
Hi,

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 regards,
β€”Florian

> On Oct 6, 2017, at 6:38, L. David Baron <dbaron@dbaron.org> wrote:
> 
> 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:
> https://github.com/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] https://lists.w3.org/Archives/Public/www-style/2017Sep/0003.html
> [2] https://github.com/dbaron/css-line-spacing/issues
> 
> -- 
> π„ž   L. David Baron                         http://dbaron.org/   𝄂
> 𝄒   Mozilla                          https://www.mozilla.org/   𝄂
>             Before I built a wall I'd ask to know
>             What I was walling in or walling out,
>             And to whom I was like to give offense.
>               - Robert Frost, Mending Wall (1914)
Received on Tuesday, 10 October 2017 03:11:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 10 October 2017 03:11:26 UTC