W3C home > Mailing lists > Public > www-style@w3.org > December 2011

Re: line-height suggestions and easier alignment

From: Richard Le Poidevin <ric@betleywhitehorne.com>
Date: Thu, 29 Dec 2011 09:58:38 +0000
Message-ID: <4EFC39CE.6020204@betleywhitehorne.com>
To: www-style@gtalbot.org
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style@w3.org
Hello,

Sorry for not getting any examples to you until now - Christmas got in 
the way.

I've put together three pages that show how I believe line-height 
currently doesn't work for all cases. One problem I discovered whilst 
making these is that CSS columns don't align text correctly with 
line-height added top and bottom. The vertical alignment is a few pixels 
out. The examples are not pretty, they are just designed to show the 
problem.

http://www.betleywhitehorne.com/ric-lep/fix-css-line-height/

I've never suggested anything for the spec before, so please let me know 
if you require anything else.

Kind regards

Ric

On 28/12/2011 23:26, "Gérard Talbot" wrote:
> Le Mar 27 décembre 2011 10:57, Tab Atkins Jr. a écrit :
>> On Fri, Dec 23, 2011 at 2:33 AM, Richard Le Poidevin
>> <ric@betleywhitehorne.com>  wrote:
>>> Hello,
>>>
>>> I've often been frustrated by how line-height works in CSS. The value is
>>> added equally to the top and bottom of each line. This is different to
>>> the
>>> behaviour of programs such as InDesign, Illustrator etc which add
>>> leading
>>> (line-height) to the bottom of each line. I believe this behaviour to be
>>> far
>>> easier to control and useful.
>>>
>>> Examples:
>>>
>>> I have a site with three columns. The text in each column needs to line
>>> up
>>> vertically, however the central column has a header set in larger type
>>> and
>>> requires a bigger line-height. If I increase the line-height it gets
>>> applied
>>> top and bottom to each line pushing the title down the page a few
>>> pixels. I
>>> then need to use a horrible hack such as a negative top margin to to fix
>>> this.
>>>
>>> This 'fix' will not work if the box has a background colour that also
>>> needs
>>> to align.
>>>
>>> I think we either need a rule to supplement line-height such as
>>> line-height-align/line-height-origin. Or perhaps base-line: top / middle
>>> /
>>> bottom.
>>>
>>> Or maybe have a leading rule that behaves in the same manner that has
>>> been
>>> used since movable type was first invented and where it gets it's name
>>> from.I could then ditch line-height all together as I find it had to
>>> find
>>> any practical uses for the current implementation.
>> The idea of controlling where the leading gets placed (or
>> equivalently, where the text is placed within the line-height) makes
>> sense to me.
> Tab,
>
> How is this idea of where the leading starts an improvement? Please
> elaborate.
>
>>   Your use-case (a heading in a larger font, and thus
>> larger line-height, where you want the top of the heading to line up
>> visually with the top of the first lines in the other columns) is
>> definitely reasonable.
> Please explain why defining+controlling where the leading would start
> would be reasonable, advantageous or adding some kind of usefulness, value
> in such case. Regardless of where the leading starts, it will not impact
> display of glyphs which could be impossible to vertically align anyway:
> glyphs are not the same either; there are those with ascenders, with
> descenders, etc...
>
> I have asked already Richard to give an URL about his three columns webpage.
>
> If a heading, let's say,<h1>  is (font-size) 2em with a line-height of
> 1.2, it won't align anyway with a p (font-size) 1em with a line-height of
> 1.2.
>
> As far as I can see this, it does not really matter where the leading
> actually starts.
>
> Just a supposition: maybe what Richard needs would be to correctly use
> line-height like in
>
> div#central-column>  h1 {font-size: 2em; line-height: 2.4;}
>
> div#left-column:first-line {font-size: 1em; line-height: 2.4;}
>
> (assuming central column uses h1 heading; we also have to assume and
> postulate that glyphs with no ascender should not be top-aligned with
> glyphs having an ascender, same thing with descender, max-ascent,
> max-descent cases.)
>
>
> And there is already a property for controlling where inline boxes are
> vertically aligned inside the line box in CSS 2.1: vertical-align.
>
>
>> We can't change the default behavior regarding leading distribution
>> now, as there's tons of content that depends on the existing
>> definition.  However, I can get behind a new property that allows some
>> control over this.  For consistency with similar properties, it would
>> be better to do 'line-height-align' or 'line-align', with values
>> "before | middle | after" (or perhaps "over | middle | under" to align
>> with the over/under directions defined in
>> <http://dev.w3.org/csswg/css3-writing-modes/#line-directions>),
>> defaulting to "middle".
>
> I do not understand how or why having control over where the leading
> starts would actually fix the problem described (in general terms) by
> Richard's 3 column webpage. We *really* need a demo webpage clearly
> presenting the issue first.
>
> regards, Gérard
Received on Thursday, 29 December 2011 09:59:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT