W3C home > Mailing lists > Public > www-style@w3.org > June 2014

Re: [css-values] Line-height relative length units 'lh' and 'rlh'

From: MURAKAMI Shinyu <murakami@antenna.co.jp>
Date: Wed, 04 Jun 2014 03:56:31 +0900
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-style list <www-style@w3.org>
Message-Id: <20140604035630.8E94.C598BCD7@antenna.co.jp>
"Tab Atkins Jr." <jackalmage@gmail.com> wrote on 2014/06/02 2:26:17
> On Sun, Jun 1, 2014 at 12:29 AM, MURAKAMI Shinyu <murakami@antenna.co.jp> wrote:
> > I would like to propose new relative length units:
> >
> >     'lh'    line-height of the element
> >     'rlh'   line-height of the root element
> >
> > (refer the used value of the line-height property)
> >
> > The line-height relative length units are necessary for specifying
> > the block-size of a block container using number of lines.
> 
> What happens when a line is larger than the 'line-height' property
> value, due to containing a large inline image, for example?  Is it
> okay that the element will contain less than the specified number of
> lines?  Or does the lh value vary based on what lines are actually
> present in the element?

In my proposal, the lh unit simply refers to the line-height property's 
used value. For example,

  div {
    font-size: 10pt;
    line-height: 1.5;
    height: 10lh;
  }

the line-height property's used value is 15pt, and the height value
10lh is computed to 150pt.  The actual number of lines in this block
may be less than 10 due to containing taller lines.

I think this is very natural behavior.  When we define a page layout,
we consider the number of lines per page for setting page area size
but don't expect the page area size varies based on actual lines.

> 
> If you recall from the last day of the face-to-face meeting, I
> proposed standardizing the -wekbit-line-clamp behavior, which lets you
> specify the height of an element in terms of the number of lines.
> This actually *does* handle the "some lines are a different size"
> problem, if all you care about is sizing an element to a specific
> number of lines.
> 
> > Examples:
> >
> >   @page {
> >     height: 20rlh; /* n of lines per page */
> >   }
> 
> So I think this would work with the line-clamp proposal.  You'd just set it to:
> 
> @page {
>   line-clamp: 20;
> }
> 
> Or whatever we end up naming the property.  We'd have to define that
> 'line-clamp' applies to @page, of course, but that's not hard.

That's interesting idea, but I understand that the line-clamp proposal 
seems different purpose from the line-height relative length unit proposal.

Because the page media size is limited by physical paper of screen size,
the necessity of handling the "some lines are a different size" will
be rare for @page area.

> 
> >   p {
> >     margin-top:    1lh;  /* keep paragraph spacing to 1 line-height */
> >     margin-bottom: 1lh;
> >   }
> 
> This seems like it's about maintaining vertical rhythm, which implies
> that what you really want is the Line Grid module, right?  Having a
> unit that's relative to the current line grid on the element makes a
> little more sense to me than one based on the 'line-height' property.

Yes, I want the Line Grid module. However also I think that the
length unit based on the line-height value is useful even when the
Line Grid is not used; e.g., when a half line-height space is needed
between block boxes.

> 
> > To prevent circular dependency, the following limitations are needed:
> >
> > - 'lh' cannot be used on 'line-height' and 'font-size' property value
> > - 'rlh' cannot be used on root element's 'line-height' and 'font-size' property value
> 
> This sounds like you're proposing making it a syntax error to use 'lh'
> and 'rlh' in these circumstances?  Might be better to use something
> akin to the 'em' behavior, where we instead use the value from the
> parent, or a default value.

Agree.  In these circumstances, it will be better to use the value from 
the parent, or use the default value on root element.

Thanks,

Shinyu Murakami
Antenna House
Received on Tuesday, 3 June 2014 18:57:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:22 UTC