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

Re: Option so line-height only affects height between lines

From: Ben Sciascia <ben.sciascia@sciascia.co.nz>
Date: Tue, 09 Dec 2014 07:02:01 +0000
Cc: W3C www-style mailing list <www-style@w3.org>
Message-Id: <219A5BC2-AB89-44B7-8A59-4BAADDC12856@sciascia.co.nz> (sfid-20141209_070208_878478_A04AD35B)
To: Gérard Talbot <www-style@gtalbot.org>

> On 9/12/2014, at 6:55 pm, Gérard Talbot <www-style@gtalbot.org> wrote:
> 
> Le 2014-12-08 19:04, Ben Sciascia a écrit :
>> Here’s a link that shows both the issues mentioned:
>> http://line-height.devsite.nz/
>> Design is obviously subjective but even this basic example shows the
>> issues - specific comments below...
> 
> By default, the default, initial vertical margins of <p> element in the user agent style sheet all mainstream browsers use
> 
> p {margin: 1em 0;}
> 
> So, can you try replacing:
> 
> <div class="left">
>        <p>
>          <img src="http://placehold.it/350x150">
>        </p>
>      </div>
> 
> with
> 
> <div class="left">
>          <img src="http://placehold.it/350x150">
>      </div>

Yes, but most CMS's I’ve come across wrap images in <p> tags - I don’t necessarily agree with it but that’s the reality of many sites out there. So allowing for this in the css becomes more important than changing the markup - which is not possible in many instances (clients edit content, not designers - especially in smaller companies).

Also, there’s no issue with making things line up, I just feel there would be fewer things to worry about if there was an option to limit line-height to the height between lines.




> --------
> 
> 2 other things
> 
> 1)
> Height of em box is consistent in a font but glyphs do not have the same shape, the same height and not the same width in a proportional font.
> 
> Eg.
> "É" and "e" do not have the same height;
> "w" and "i" do not have the same width.
> So *_visually_* this is tricky. And the line box could be aligned with something else but we visually can not be sure because we have to use special characters or a font like Ahem font.
> 
> So, it's impossible to vertically align 2 glyphs which have different shape and form.

I'm unsure how an option to limit line height to the space between lines would make this situation better or worse - I experience this problem now, glyphs often don't line up.




> 2)
> 
> When you say:
> 
> "Line-height in CSS not only affects the height between lines of text"
> 
> this may not be true; it depends on what you meant by "lines of text". Line-height sets a minimal of height for the line box; line box is not line of text (or line of glyphs). Line height can increase due to tall image or bigger font-size.
> 
> "
> Line boxes are stacked with no vertical separation (except as specified elsewhere) and they never overlap.
> "
> http://www.w3.org/TR/CSS21/visuren.html#inline-formatting
> 
> So, in the text of the spec, there is no inter-line-box-gap or inter-line-box-spacing.


I don’t really understand how line-height is calculated in CSS but based on your comments, it sounds very much as if each line is wrapped in a box, instead of using a baseline? 





> 
> Gérard
> 
>> On 9/12/2014, at 9:54 am, Gérard Talbot <www-style@gtalbot.org> wrote:
>>>> Because line-height also adds space above the headline, headlines
>>>> often fail to line up with other elements.
>>> Please create a *_simple and reduced test page_* illustrating, demonstrating the issue you describe and upload it somewhere so that we can examine your code.
>> Notice how out-of-the box, line-height is pushing the headline below
>> the image. In many instances it doesn’t matter but in some designs, it
>> does matter - requiring additional properties to compensate (like
>> adjustments to top margin on either the image or the headline).
>> This is what I meant by "This creates a situation similar to the old
>> box model” - changing leading also changes the space between elements
>> forcing us to juggle multiple properties to compensate for the extra
>> space line-height is adding above and below the element.
>>>> This forces us to compensate with negative margins - and if the line
>>>> height is changed, the compensating adjustments also requiring
>>>> updating, creating unnecessary work.
>>>> USE-CASE #2: Headlines need to be visually grouped with paragraphs
>>>> If the design requires that headlines be visually grouped with
>>>> paragraphs, less space is required between the headline and paragraph
>>>> and more space before the paragraph.
>>> Visually grouped how? Horizontally? Again, please create a reduce test page illustrating the issue.
>> If you scroll down to the second two examples you can see what I
>> mean't by visually grouped - the second example shows additional space
>> between the headline and the preceding paragraph. This visually groups
>> the headline with the paragraph immediately below it.
>> You can also see that the second headline feels a bit squashed
>> (subjective, I know) but any increases in line-height will also add
>> additional space above and below the headline.
>> Once again, we have a juggling situation where we're adjusting
>> line-height along with compensating properties instead of just
>> line-height - especially when line-height is adjusted at a later date
>> (i.e. after we’ve added any compensating properties).
>> I agree that the additional space line-height adds is hardly
>> noticeable in many instances but sometimes it is noticeable - and can
>> require the juggling of multiple properties to compensate which is
>> unnecessary in my opinion.
>> Hence the suggestion of an option to force line-height to only affect
>> the space between lines and not the space above and below an element.
>> Hope that all makes sense,
>> Regards,
>> Ben
>>> Le 2014-12-01 14:49, Ben Sciascia a écrit :
>>>> Line-height in CSS not only affects the height between lines of text,
>>>> it also alters the space above and below elements.
>>>> This creates a situation similar to the old box model when padding
>>>> also affected width - changing line-height in CSS can require us to
>>>> also alter top and bottom margins or padding.
>>>> USE-CASE #1: Top edges of headlines need to line-up with top edges of
>>>> other elements
>>> Are you saying the headlines are on the left-hand (or on the right-hand) side of other non-headline text elements? What do you do? Are you using a table element?
>>>> Because line-height also adds space above the headline, headlines
>>>> often fail to line up with other elements.
>>> Please create a *_simple and reduced test page_* illustrating, demonstrating the issue you describe and upload it somewhere so that we can examine your code.
>>>> This forces us to compensate with negative margins - and if the line
>>>> height is changed, the compensating adjustments also requiring
>>>> updating, creating unnecessary work.
>>>> USE-CASE #2: Headlines need to be visually grouped with paragraphs
>>>> If the design requires that headlines be visually grouped with
>>>> paragraphs, less space is required between the headline and paragraph
>>>> and more space before the paragraph.
>>> Visually grouped how? Horizontally? Again, please create a reduce test page illustrating the issue.
>>> I'm only trying to better understand your description alongside with what you code exactly.
>>> Gérard
>>>> But because line-height is also affecting the space between the
>>>> headline and the paragraph, line-height on larger headlines (like h1s
>>>> and h2s) create a space that’s too big.
>>>> Reducing line-height reduces the space but it also forces lines in
>>>> multi-line headlines to bleed together. Adding negative margin to
>>>> compensate quickly becomes painful if the line-height is adjusted -
>>>> again, the designer is adjusting multiple properties instead of one.
>>>> CONCLUSION:
>>>> Overall, this suggestion is about creating an additional line-height
>>>> property that forces line-height to only affect the height between
>>>> lines and not the space before and after elements.
>>>> Regards,
>>>> Ben
>>>> ___
>>>> Ben Sciascia
>>>> Sciascia Brothers
>>>> Level 1, 56 Brown Street, Ponsonby
>>>> PO Box 68-578 Newton,
>>>> Auckland, New Zealand
>>>> PH: +649 360 0559
>>>> FAX: +649 360 0012
>>>> MOB: +64 21 44 33 66
>>>> www.sciascia.co.nz
>>>> ben.sciascia@sciascia.co.nz
>>>> WARNING: This e-mail contains information which is CONFIDENTIAL and
>>>> may be subject to LEGAL PRIVILEGE. If you are not the intended
>>>> recipient, you must not peruse, use, disseminate, distribute or copy
>>>> the e-mail or attachments.  If you have received this message in
>>>> error, please telephone us immediately and destroy the original
>>>> message.
>> ___
>> Ben Sciascia
>> Sciascia Brothers
>> Level 1, 56 Brown Street, Ponsonby
>> PO Box 68-578 Newton,
>> Auckland, New Zealand
>> PH: +649 360 0559
>> FAX: +649 360 0012
>> MOB: +64 21 44 33 66
>> www.sciascia.co.nz
>> ben.sciascia@sciascia.co.nz
>> WARNING: This e-mail contains information which is CONFIDENTIAL and
>> may be subject to LEGAL PRIVILEGE. If you are not the intended
>> recipient, you must not peruse, use, disseminate, distribute or copy
>> the e-mail or attachments.  If you have received this message in
>> error, please telephone us immediately and destroy the original
>> message.


___

Ben Sciascia

Sciascia Brothers
Level 1, 56 Brown Street, Ponsonby
PO Box 68-578 Newton,
Auckland, New Zealand

PH: +649 360 0559
FAX: +649 360 0012
MOB: +64 21 44 33 66

www.sciascia.co.nz <http://www.sciascia.co.nz/>

ben.sciascia@sciascia.co.nz <mailto:ben.sciascia@sciascia.co.nz>

WARNING: This e-mail contains information which is CONFIDENTIAL and may be subject to LEGAL PRIVILEGE. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy the e-mail or attachments.  If you have received this message in error, please telephone us immediately and destroy the original message.


Received on Wednesday, 17 December 2014 12:47:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:49 UTC