Intent to implement: CSS property `line-height-step`

[Tommy Kuo]

**Summary**

I am intent to implement the property `line-height-step`. And it would be disabled behind the pref `layout.css.line-height-step.enabled` by default. It is a property to make authors create the content with vertical rhythm easier.

**Link to standard**

CSS Rhythmic Sizing
<https://drafts.csswg.org/css-rhythm/>


**Bug Link**

Bug 1343819 - Implement CSS property `line-height-step`
<https://bugzilla.mozilla.org/show_bug.cgi?id=1343819>

**Tests**

There are already some test cases on web-platform-tests.
<https://github.com/w3c/web-platform-tests/tree/master/css/css-rhythm-1>

**Status on Other Browsers**

*Blink*

Blink is implemented in Issue 2704343003.
<https://codereview.chromium.org/2704343003>

Currently, this property only available in Chromium Developer Build 59. To try this feature, you need to enable "Experimental Web Platform features" in chrome://flags.

*WebKit & Edge*

Not support.

**More About It**

Vertical rhythm is a principle of typography. It is about spacing text. More generally, it is about vertical stacked elements. We can create a more comfortable layout with vertical rhythm.

We can imagine that we're put all elements on a sheet of lined paper. The sizes of elements are according to the size between the lines.

For example, we set the font-size as 12px. And the line-height is 1.5x of font-size, so it is 18px. We assume we want to put all elements on a lined paper and the line size is 18px. For the normal text, we just put them align the lines. If there is a title with 24px, to follow the vertical rhythm, the size of the title should be multiple of the line size. We add 6px to both over-side and under-side of the title, and the size of the title would be 36px (2 * 18).


- Tommy

[L. David Baron]

On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
> **Summary**
>
> I am intent to implement the property `line-height-step`. And it would be disabled behind the pref `layout.css.line-height-step.enabled` by default. It is a property to make authors create the content with vertical rhythm easier.
>
> **Link to standard**
>
> CSS Rhythmic Sizing
> <https://drafts.csswg.org/css-rhythm/>

So in the discussions in the working group, I've been somewhat
skeptical that this feature does a good job of addressing the design
use cases that it's intended to address.

I think there are two issues with it:

First, in many cases, the goal of setting up vertical rhythm is to
ensure that different (adjacent) pieces of text have the same
rhythm, where by different pieces of text I mean things like text on
opposite pages, text in different columns, text in a float and in
the normal flow, or similar things. 'line-height-step' only
addresses this use case if the developer is *extremely* disciplined
to ensure that nothing other than line-height (e.g., border,
padding, margin) causes vertical spacing. My sense was that the
line grid proposals were significantly better at addressing this use
case (since they established an overall grid), although they were
harder to implement (because they complicate things like sliding an
element's position in the block axis).

Second, I think the rhythm that line-height-step sets up probably
isn't the most desirable one. I'd expect that it is preferable to
have the baseline of each line match the rhythm, but
line-height-step does not ensure this. For example, if most lines
have a line box height that matches the step, but there is something
tall on a line (say, an image protruding upwards) that makes its
line box height initially (without the adjustment from the step) 2.1
times the step height, then the line with the tall thing on it gets
an additional 0.45 multiple of the step height on each side, which
means the baseline of the text is 0.45 times the step height above
the rhythm, so instead of having an appearance of skipping two lines
and then having a baseline at the correct position, you get
(ignoring the thing that protrudes above) the appearance of skipping
1.55 lines, having a misaligned baseline (0.45 above the rhythm
poisition), and then skipping the remaining 0.45. I'd have thought
it would be preferable to put all the extra space above in this case
in order to keep the baseline matching the rhythm. (In some cases
this would require an additional multiple of the step height.) I
might be wrong about this, though; it's worth consulting designers
about what behavior is actually desirable.

-David

--
𝄞 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)

[fantasai]

On 03/31/2017 07:55 AM, L. David Baron wrote:
> On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
>> **Summary**
>>
>> I am intent to implement the property `line-height-step`. And it would be disabled behind the pref `layout.css.line-height-step.enabled` by default. It is a property to make authors create the content with vertical rhythm easier.
>>
>> **Link to standard**
>>
>> CSS Rhythmic Sizing
>> <https://drafts.csswg.org/css-rhythm/>
>
> So in the discussions in the working group, I've been somewhat
> skeptical that this feature does a good job of addressing the design
> use cases that it's intended to address.

As the co-editor of the spec, I agree with David Baron's concerns.

Also, based on my discussions with Dave Cramer (CSSWG member who works
in the publishing industry), my understanding is that the the most
common problems are situations that need to be solved with block height
stepping, not line height stepping. An author can fairly easily ensure
that, within a paragraph, the line height follows a strict vertical
rhythm: as long as the text is not interrupted by atomic inline content
or text that has a larger font size / different vertical alignment (and
this covers the majority of text), it will maintain rhythm. But when the
paragraph text is interrupted by different content such as illustrations
and headings, then the rhythm can be thrown off. These are block-level
intrusions into the rhythm, and won't be solved (without hacks like
turning them into inline-blocks) by line height stepping. But they are
solved by block height stepping (which is also outlined in that draft).

I think we should endeavor to avoid “solutions” that require hacks, so
my advice would be to implement block height stepping first, since it
will more directly solve most of the use cases. I'm less convinced that
line height stepping is necessary; and also there are many issues with
inline layout that need to be addressed before it can be an effective
solution to the problems it addresses.

* Note that even for headings, which are text, it is the margin-box of
the heading as a whole which needs to fit into the rhythm, not necessarily
each line of it; headings usually have large margins, but the text is set
closely between lines. Similar concerns apply to blockquotes with smaller
text, figures with captions, and other block-level interruptions to prose.

~fantasai

[Tantek Çelik]

Completely agreed re: the prioritization of block height stepping
before line height stepping and the respective design use-cases.

The issues noted here, and the summaries of use-cases are worthy of
explicitly including in the spec. Perhaps even a coarser change like
noting/listing block height stepping *before* line height stepping
both in the introduction and structure of the overall document.

I'll file spec issues accordingly to discuss separately from this
intent to implement thread.

Thanks fantasai.

Tantek

[Jet Villegas]

During recent discussions with Koji Iishi, we said we would consider
this feature for implementation if we could find examples of content
authored for this feature that satisfy use cases from web and/or print
designers. I'd still love to see those examples ( authored by someone
outside the working group) before we commit to an implementation. In
other words, we said we'd do it if it was relatively straightforward
to implement *and* web authors outside the CSSWG has used the
experimental Chromium feature and is happy with the rendering.

Koji: have you found such examples?

Thanks,

--Jet

On Thu, Mar 30, 2017 at 9:11 PM, Tommy Kuo <to...@mozilla.com> wrote:
> **Summary**
>
> I am intent to implement the property `line-height-step`. And it would be disabled behind the pref `layout.css.line-height-step.enabled` by default. It is a property to make authors create the content with vertical rhythm easier.
>
> **Link to standard**
>
> CSS Rhythmic Sizing
> <https://drafts.csswg.org/css-rhythm/>
>
>

> **Bug Link**
>
> Bug 1343819 - Implement CSS property `line-height-step`
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1343819>
>
> **Tests**
>
> There are already some test cases on web-platform-tests.
> <https://github.com/w3c/web-platform-tests/tree/master/css/css-rhythm-1>
>
> **Status on Other Browsers**
>
> *Blink*
>
> Blink is implemented in Issue 2704343003.
> <https://codereview.chromium.org/2704343003>
>
> Currently, this property only available in Chromium Developer Build 59. To try this feature, you need to enable "Experimental Web Platform features" in chrome://flags.
>
> *WebKit & Edge*
>
> Not support.
>
> **More About It**
>
> Vertical rhythm is a principle of typography. It is about spacing text. More generally, it is about vertical stacked elements. We can create a more comfortable layout with vertical rhythm.
>
> We can imagine that we're put all elements on a sheet of lined paper. The sizes of elements are according to the size between the lines.
>
> For example, we set the font-size as 12px. And the line-height is 1.5x of font-size, so it is 18px. We assume we want to put all elements on a lined paper and the line size is 18px. For the normal text, we just put them align the lines. If there is a title with 24px, to follow the vertical rhythm, the size of the title should be multiple of the line size. We add 6px to both over-side and under-side of the title, and the size of the title would be 36px (2 * 18).
>
>
> - Tommy
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

[Koji Ishii]

After some more thoughts, I thought this conversation clarified my feeling
of wrongness, so I added a section to explain that.

https://drafts.csswg.org/css-rhythm/#eastasia

Hope this makes better understanding for this CJK feature.

On Mon, Apr 3, 2017 at 2:39 AM, Koji Ishii <ko...@chromium.org> wrote:

> Hi Jet, thank you for cc'ing me.
>
> I'm having difficulty to convince authors to use features when it's behind
> the flag, so it's a bit circling. But we found some sites are, logically
> speaking, implementable only with line-height-step, and their biggest wish
> is interoperability, because supporting down-level browsers is troublesome.
> That being another reason to make convincing sites difficult, with or
> without flag.
>
> One such example is <http://sato-yuki.net/>. The site owner had to
> develop SASS plugin because Compass <http://compass-style.org/
> reference/compass/typography/vertical_rhythm/> doesn't provide vertical
> rhythm for vertical flow, but we confirmed that this site is fully
> implementable by line-height-step. I've got several other cases from Japan
> digital-publishing industry but they're not available on public internet
> unfortunately, so they don't suffice your request. They're not really using
> the behind-the-flag feature, but could they be examples?
>
> cc'ed a few more people, who presented the needs of vertical rhythm in
> Sapporo industry meetup a few years ago, and as far as I understand, they
> will be presenting vertical rhythm again in Tokyo meetup. I hope they can
> present more cases.
>
> Just in case my words in the past were misleading, I do agree with
> usefulness of line grid and box height stepping. They complement
> line-height-step, covers cases where line-height-step doesn't, or make it
> more robust. I do agree, depends on use cases, especially in Latin, they're
> more useful than line-height-step.
>
> If Gecko is going to work on all 3 features -- line grid, box step, and
> line step -- this is super great. We wish to revisit them in future too.
> But other features having useful cases doesn't look like a reason not to
> work on line height step to me, when line-height-step complements line grid
> and box stepping (and vice-versa of course,) and CJK has been strongly
> demanding vertical rhythm for more than a decade even the simplest one.
> We're going to try to make CJK happy first, then try to spread to other
> authors, but other engines can take different orders, or make all of them
> happy at once. It's just great.

[Koji Ishii]

[L. David Baron]

On Friday 2017-03-31 07:55 -0400, L. David Baron wrote:

> On Friday 2017-03-31 12:11 +0800, Tommy Kuo wrote:
> > **Summary**
> >
> > I am intent to implement the property `line-height-step`. And it would be disabled behind the pref `layout.css.line-height-step.enabled` by default. It is a property to make authors create the content with vertical rhythm easier.
> >
> > **Link to standard**
> >
> > CSS Rhythmic Sizing
> > <https://drafts.csswg.org/css-rhythm/>
>

> So in the discussions in the working group, I've been somewhat
> skeptical that this feature does a good job of addressing the design
> use cases that it's intended to address.
>

> I think there are two issues with it:

I actually think there's a third, more serious, issue, based on the
discussions that we just had in the working group meeting. This
issue is that there's a risk that this property encourages designs
that are very sensitive to conditions (e.g., the way font metrics
are rounded, the exact choice of fonts used) such that they will
lead to double-spacing in some engines and not others, producing
serious compatibility problems.

I think until this issue is addressed better I'd be opposed to
shipping an implementation of this feature.