I have SPAN wrapped into another SPAN:
<span id="outer">
<span id="inner">
Some long text
</span>
</span>
And CSS:
#outer {
font-size: 20px;
font-family: 'Times New Roman';
line-height: 30px;
}
#inner {
font-family: 'Times New Roman';
}
This variant renders exactly the same in Opera, Safari, Chrome, FF.
Text is rendered exactly 30px lines height.
If outer SPAN is set another font-family, for example Arial:
#outer {
font-size: 20px;
font-family: 'Arial';
line-height: 30px;
}
Crome and Safari renders text as 31px line-height.
FF - 30.5px line-height
Opera - 30px (as expected)
Why this happens?
Note: this markup and styles is created by user in WYSIWYG editor.
JSFiddle - right rendering
JSFiddle - wrong rendering
If you look at the image below, you will notice that both fonts have different baseline heights. It appears that Times New Roman is about 2px shorter than Arial.
I'm not an expert on the font rendering engines, but my best guess as to what is happening is that the 1-2px additional pixels applied to the #outer is caused by Arial being 2px taller.
Even though the font within the #inner is Times New Roman, the rendering still has an affect on the outer div due to it being set as Arial.
Hopefully this gives you some insight as to where there are additional pixels in your line-heights.
The line-height value applied is the declared value, as you can see by using developer tools in browsers. The rest is rendering differences that probably have nothing to do with inheritance and are probably not controllable by authors.
Related
I have this code:
<p style="line-height: 1;overflow: hidden;">blah_blah</p>
<p>blah_blah</p>
<p style="line-height: 1;overflow: hidden;">qypj;,</p>
<p>qypj;,</p>
which results in (notice no underscore, and cut characters):
That is, it behaves that way in Firefox (66.0.3 on Windows 10). Other browsers seem to render the underscore. The above snippet runner also seems to work (even in Firefox), unless you run it in "Full page".
This Q is similar to Text changes height after adding unicode character except there are no tricks here. "_" is just a simple ASCII character.
My question is which behavior is the correct one.
Is specific character allowed to change line height (I thought it was only supposed to be font dependent)? Shouldn't line-height: 1 imply it can fit exactly any text?
I suppose some characters are special, such as "p", "g", "j" (and possibly "_") that draw below its line. Still which behavior is the correct one. Is it considered overflow or not?
PS: Furthermore I find it funny either overflow-x: hidden;overflow-y: visible; and overflow-x: visible;overflow-y: hidden; still causes this. Which seems more like an actual bug to me.
My question is which behavior is the correct one.
All of them are correct because we don't have the same default font in all browsers and it's also different depending on the OS.
Is specific character allowed to change line height (I thought it was only supposed to be font dependent)?
Character doesn't change line-height. To be more accurate, line-height is a property that can only be changed by setting line-height but you are probably confusing with the line box that is defined by the line-height and a character alone cannot change it.
Shouldn't line-height: 1 imply it can fit exactly any text?
Not necessarely, line-height:1 means that the line box will be equal to the 1xfont-size 1 but is the font designed to include all the character inside this space? Probably most of them will do but we don't know.
Basically, you have two things to consider. The content area that is defined by the font properties and the line box that is defined by the line-height. We have no control over the first one and we can only control the second one.
Here is a basic example to illustrate:
span {
background:red;
color:#fff;
font-size:20px;
font-family:monospace;
}
body {
margin:10px 0;
border-top:1px solid;
border-bottom:1px solid;
animation:change 2s linear infinite alternate;
}
#keyframes change {
from {
line-height:0.2
}
to {
line-height:2
}
}
<span >
blah_blah
</span>
The red is our content area and its height is defined by the font properties and if you inspect the element you will see it has a height equal to 23px (not 20px like the font-size) and the borders define our line box that we control using the line-height.
So if the line-height is equal to 1 we will have a line box equal to 20px which is not enough to contain the 23px of the content area thus it will get truncated and we may probably hide some characters (or a part of them) which is logical:
span {
background: red;
color: #fff;
font-size: 20px;
font-family: monospace;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<span>
blah_blah ÂÄ j p
</span>
a different font-size will remove the underscore in Firefox:
span {
background: red;
color: #fff;
font-size: 26px;
font-family: monospace;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<span>
blah_blah ÂÄ j p
</span>
Another example with a Google Font where the result should be the same cross browser. The underscore is visible but not the ^/¨
span {
background: red;
color: #fff;
font-size: 26px;
font-family: 'Gugi', cursive;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<link href="https://fonts.googleapis.com/css?family=Gugi" rel="stylesheet">
<span>
blah_blah ÂÄ j p
</span>
Another example where the underscore is not visible:
span {
background: red;
color: #fff;
font-size: 27px;
font-family: 'PT Sans', sans-serif;
}
body {
margin: 5px;
line-height: 1;
overflow:hidden;
}
html {
overflow:auto;
}
<link href="https://fonts.googleapis.com/css?family=PT+Sans" rel="stylesheet">
<span>
blah_blah ÂÄ j p
</span>
You can clearly see that we have a different overflow everytime we use a different font which confirms that this is font related. We have no control over it unless we know how the font is designed.
Related questions:
Understanding CSS2.1 specification regarding height on inline-level boxes
Why is there space between line boxes, not due to half leading?
Line height issue with inline-block elements
Here is a good article to get more accurate details and calculation: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
A quote from this article:
It becomes obvious that setting line-height: 1 is a bad practice. I remind you that unitless values are font-size relative, not content-area relative, and dealing with a virtual-area smaller than the content-area is the origin of many of our problems.
1 : I considered a simplified explanation but in reality the calculation of the line box is not only relate to the line-height property.
The default line-height (depending on the font-family) when not otherwise specified is about 1.2 in most browsers. This includes Firefox.
This would explain why the underscore did not show in FireFox when the line-height was set to 1 - the bottom was of the line was cut off. So I don't think it's entirely to do with the font (although this does contribute), but also browser defaults.
Some font-sizes are bigger than other even at seemingly the "same" font size (as I'm sure you've seen when typing documents in e.g. Georgia vs Times new Roman/Baskerville ; so you wouldn't be guaranteed that text would always show on a specified line height of 1 (or 1.2). There are ways of measuring a font in pixels however
Hope this helps
If I use the browser tools in Firefox to inspect my snippet below, there is no height difference between the lines with and without underscore. The only difference is caused by the line-height setting: 16px with line-height: 1, 19.2 px with the browser's default line-height. So the underscore doesn't make a difference here (Firefox 66.0.3 on Mac), and it is visible in both cases.
Note that I set margins to 0 to see the "pure" line-height without distances between the lines. Also, I didn't specify a font-familiy setting, so the default font of the browser for p tags is used.
The only reason for what you describe which I can think of is a font with very particular dimensions/settings, where the descenders (i.e. the parts of letters like p q j which extend below the baseline) are not inside the line-height as defined by the font.
After a bunch of comments back and forth: I suppose it could be caused by the different default (system) fonts on Windows and Mac. Still a bug, I would say (if you are using the default font).
html,
body {
margin: 0;
padding: 0;
}
p {
background: #fb6;
margin: 0px;
}
<p style="line-height: 1;overflow: hidden;">blah_plah</p>
<p style="line-height: 1;overflow: hidden;">blah plah</p>
<p>blah_plah</p>
<p>blah plah</p>
I'm experiencing the following issue in both Safari and Chrome.
body {
font-size: 15px;
line-height: 1.2;
}
body, .same-font {
font-family: Helvetica, sans-serif;
}
code {
font-family: Courier New, sans-serif;
}
<ul>
<li>Without any code - 18px height.</li>
<li>With <code>code</code> - 20px height.</li>
<li>With <code class="same-font">code.same-font</code> - 18px height.</li>
</ul>
Run the above snippet and the inspector. You can notice that the code element doesn't have anything modifying its font-size or line-height except body which it's inheriting from.
It's not adhering to that inherit though, because the height of its containing li is 20px, not 18 like the others... I'm not sure where that height is coming from, because the code element itself has a height of 17px (which is also of unknown origin).
When the normal/body is applied to the code element (like on the third list item), it goes back to 18px like normal. To me this means it's not any other properties that the user agent has imposed on the code element affecting the height - solely the font-family.
EDIT: For reference, something in StackOverflow's styles prevent this behaviour. The following list items all have the same height:
One
two
Three
EDIT 2: Apparently not.. if you change their monospace font to Courier New then the same problem would persist.
How can this change in size be prevented? i.e. How can you specify a line height that will be used even if the fonts within that line continue to change?
An example use case would be in a design with vertical rhythm - each line's height and the total height used by an element should be a multiple of 18px (i.e., if using that grid size) - a 20px line throws off the rhythm.
I ended up solving my own problem (to an acceptable extent) by simply tweaking with the font family and size until it worked for me:
body {
font-size: 15px;
line-height: 1.2;
}
body, .same-font {
font-family: Helvetica, sans-serif;
}
code {
font-family: Menlo, Courier New, sans-serif;
font-size: 0.9333em; /* 14/15 */
line-height: 1.28571; /* 18/14 */
}
<ul>
<li>Without any code - 18px height.</li>
<li>With <code>code</code> - 18px height.</li>
<li>With <code class="same-font">code.same-font</code> - 18px height.</li>
</ul>
Why Menlo?
I noticed that StackOverflow used Menlo and that didn't have this problem. When I tried it, it also solved the problem, however the font isn't built in on Windows.
So simply using Menlo solved the problem on Mac and didn't change anything on Windows.
Why the different font-size?
The different size changed nothing (except the font size...) when Menlo is in use - it still adhered to the line height, so Mac is all good.
However this font-size in combination with the Courier New fallback on Windows somehow got it adhering to the line height there too!
If I used 14px instead of 0.9333em it'd still work fine, but if I used 18px for the line-height instead of 1.28571, it wouldn't work. That doesn't bother me as I use relative values in my designs anyway.
So...
The Menlo font in combination with a Courier New fallback with a different font-size worked to solve my problem to a good-enough extent on Mac (Safari and Chrome) and Windows (Chrome).
My situation is lenient - a pixel difference wouldn't break my design, but just my rhythm. In cases where pixel perfection is required, I wouldn't feel safe with this voodoo method of playing with fonts and sizes...
If anybody can still explain where all of these numbers are coming from and what makes the actual difference here, that'd be great.
I ask this because when I try to create a CSS font stack for multi-language content, such as English and Chinese, the final rendering is affected by the first font in the stack (usually Latin ones, since most Chinese font comes with Latin support).
See this Codepen, for example.
div.a p {
overflow: hidden;
}
p {
background-color: red;
border: 1px solid black;
display: inline-block;
}
.chinese-only {
font-family: "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.english-chinese {
font-family: "Avenir Next", "Hiragino Sans GB", sans-serif;
font-size: 24px;
line-height: 48px;
}
.chinese-english {
font-family: "Hiragino Sans GB", "Avenir Next", sans-serif;
font-size: 24px;
line-height: 48px;
}
What I am seeing:
Since Chinese glyphs only appear in the Hiragino Sans GB, I expect all Chinese blocks to use the same line height. But they are apparently affected by adding the Avenir Next font at the top of the stack.
Since both Firefox and Chrome on OSX renders my example the same, I wonder if the CSS specification mentions anything about this. CSS 2.1 fonts spec doesn't appear to state what to do with line height when you fallback on missing glyphs.
Updated: Safari does render differently, but unfortunately the difference is due to overflow: hidden, not glyph fallback. My updated example may show this a bit clearer.
On Chrome and Firefox
On Safari
And if you are really into font-related headaches, try this example showing different font stacks, and see how they differ on each browser.
This is pretty much going to come down to the user agents. Any time the CSS specification says, “not defined by this specification”, that’s code for “we’ll let browsers do whatever they think is best and then try to get them all to behave consistently after a few years of doing it differently”.
Furthermore, the latest CSS Inline Layout Module states right at the top of Section 1 (Line Heights and Baseline Alignment):
This section is being rewritten. Refer to section 10.8 of [CSS21] for the normative CSS definition or the 2002 Working Draft if you want pretty pictures. (But ignore the old text, half of it’s wrong. We’re not specifying which half, that’s to be determined.)
That’s from last month. So, you know, good luck and Godspeed, basically.
Interestingly, I see a different result in Safari 6.2.2 than you posted:
If there’s a difference between that and the latest Safari, you might be able to track down a bugfix between the two versions that explains why it changed.
http://www.alecos.it/new/125027/125027.php this link is an example of my problem... I used a png 1x16 for drawing the rows... the rows are visible in the link posted... my question is:
why under IE 6/8, FireFox, Opera, Safari and other browsers the rows are perfectly aligned with the text while under IE 9/10/11 the text do not fit in the rows?
I used a simple css:
/* Style Source Code */
.code {
border-radius: 7px;
border: #6666FF 1px solid;
background-color: #FFF5EE;
background-image: url("../bkg/Bkg_116.png"); /* Horizontal Rows */
background-repeat: repeat;
background-position: 0 10px;
}
/* Style Source Code */
.xcode {
color: #008000;
font-family: 'Courier New', Courier, FreeMono, 'Nimbus Mono L', monospace;
font-size: 13px;
font-style: normal;
line-height: normal;
font-weight: normal;
font-variant: normal;
}
/* Style Div */
.alignment {
line-height: 20px;
text-align: justify;
}
Hope in workround to fix the issue...
here there is my css: http://www.alecos.it/css/alecos.css
I'm not on Windows machine right now but my guess is .xcode(line-height:16px;} would solve your problem, but I must say that this is the wrong way of creating row borders. Why not add:
.xcode td{border-bottom:1px solid #ddd;}
instead of using background image?
Firefox is temporarily outdated unti it's next update meaning that it's browser does not have the ability to process codes in the same manner as other browsers.
.alignment {line-height: 20px;}
Gets over ruled by .xcode line-height normal;
IE aint normal ;)
Besides content tages like h1, p, font all have slightly different margins/paddings around them. So a non responsive img isnt the best way to go.
Would be better if you could wrap each line with a span, div or sinces its a table a tr,td and give those a border-bottom.
Gr.
Kevin
In order to make your text inside .xcode aligned with the horizontal lines, the "code" lines must be distributed vertically. Unfortunately, It seems that you did not understand the meaning of line-height property and use the default value without considerations.
The line-height property
As you can see, the line-height property will decide how much is the distance of two lines of text. In your case, we need it to be exactly 16px inside the whole block of .xcode.
The value of normal value of the line-height property
From the W3C CSS spec, the value of normal value is defined as:
Tells user agents to set the used value to a "reasonable" value based
on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
From some online resource like this article or this page, you can see that the real value of normal value depends on many arguments like font size, font family, OS, user agent, ... Therefore, it is recommended that you should use some css normalize stylesheet to set the value of line-height correctly and cross-browser.
About your case
The quick fix here is setting the line-height inside the .xcode class to be 16px (which is the height of the of your background image).
i am using FF as the main testing platform and Chrome (for Mac) as the secondary.
I just noticed that Chrome is showing ~20px off positioning for CSS. (just to be clear Chrome is showing the TEXTAREA ~20px down as compared to FF)
Also Chrome is not obeying the width CSS property for TEXTAREA.
Is it just me or everyone is having this problem? I thought IE was crazy.
TEXTAREA {
background-color: white;
border: #ccc 2px solid;
color: black;
font-family: calibri, helvetica, arial, verdana, ms sans serif;
padding: 10px;
font-size: 16pt;
font-weight: normal
min-width:320px;
min-height:138px;
max-height:138px;
resize: none;
}
Is there a solution??
I think it would help if you could show us your 'troublesome' page. Maybe make a copy and upload it to the web so we can give it a check?
Whatever the case, I'm sure it has something to do with more than just the textarea itself. Perhaps its one of the containing elements, a rule on a parent div or table td or who knows. Since it's a textarea, I'm pretty sure there's a form or submit of some type involved so yeah, please show us more of your code ;)
You might find this useful anyway so that you can edit your code individually for moz or chrome:
Gecko browsers (FIREFOX):
#-moz-document url-prefix() {
/* Gecko-specific CSS here */
}
WebKit browsers (CHROME, SAFARI):
#media screen and (-webkit-min-device-pixel-ratio:0) {
/* Webkit-specific CSS here */
}
Cheers
Different browsers have different defaults. Add the following to the top of your CSS file:
* {
margin: 0;
padding: 0;
}
Also, what doctype are you using? If XHTML then "TEXTAREA" needs to be lowercase.