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

Le 2014-12-09 02:02, Ben Sciascia a écrit :
>> 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.


But such option always existed or already exists, although it's not 
directly settable.


> 
> 
> 
> 
>> --------
>> 
>> 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 personally think that bringing up another line-height model is just 
going to make things worse.

In the past, I have advocated several times here and elsewhere to 
include judicious schemas and examples explaining related concepts in 
section 10.8 and 10.8.1 of CSS2.1.

> - I experience this
> problem now, glyphs often don't line up.
> 

Glyphs will never line up, unless you use a special font (like some 
fantasy fonts like Thought Police or some Canadian Aboriginal font or 
usually bar-coded fonts) or specially crafted font like Ahem font.

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

line-height is one of the most misunderstood CSS2.1 property; it's very 
often misunderstood and misused.
Section 10.8, 10.8.1 and 10.6.1 are difficult to figure out, to 
understand.

> but
> based on your comments, it sounds very much as if each line is wrapped
> in a box, instead of using a baseline?

It is the case... although you can not directly style such box (with a 
border or background-color).

"
The rectangular area that contains the boxes that form a line is called 
a line box.
"
http://www.w3.org/TR/CSS21/visuren.html#inline-formatting

Line box includes the glyphs which fit onto the baseline. Line box is 
independant of the styling (borders, padding) of inline non-replaced 
boxes it contains.

"
The vertical padding, border and margin of an inline, non-replaced box 
start at the top and bottom of the content area, and has nothing to do 
with the 'line-height'. But only the 'line-height' is used when 
calculating the height of the line box.
"
10.6.1 Inline, non-replaced elements
http://www.w3.org/TR/CSS21/visudet.html#inline-non-replaced

By itself and of itself, line box height has nothing to do with the CSS 
box model.

Gérard

> 
> 
> 
> 
> 
>> 
>> 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 19:32:04 UTC