In Firefox and Chrome and Safari (latest all, on Mac 10.6.8) if I use a browser's developer tools to reduce the font size of the following span, I can watch the height (line-height) of the paragraph increase by a few pixels :
<p style="line-height: 40px; background: red;">
Some sample text some sample text.
<span style="font-size: 100%;">As this span's text size gets smaller, the paragraph gets taller.</span>
</p>
Can someone explain why this happens?
Ok, so I posted your sample html and inline css into js fiddle, here's the link:
http://jsfiddle.net/sauhL/
I then used firebug to change font-size:100%; down to 99, 98 and so forth. You are right, when you go down 1 by 1 for the font-size value, the red box gets a little bigger for a second.
The problem is that you have line-height predetermined as 40px, which causes what you called a 'bug' because line-height applied to different font sizes leads to different height renderings, and in the case of js fiddle, the linebreak is also a factor in the 'rendering' of the red box's height. After going down several points in %, there's no more expanding of the red box but rather a diminishing of size.
This is easily fixed by applying line-height:100% to the span which normalizes the height and makes sure there's no odd increases. You can expect these kinds of 'bugs' or anomalies when mixing fixed values (say 40px for example) with percentual values (100% or whatever).
Hope this solves your question
Related
I have a text input styled with the class:
.my_input{
padding:10px;
font-size:16px;
line-height:16px;
border:0;
}
You would expect the above to render an input field with a height of 36px, however it is rendering a text box as 38px high. If I set the height as a property it works, however I would like to know why it needs the height property set to accurately render it.
See my codepen for an example:
https://codepen.io/jonniejoejonson/pen/Ewmyad
Thanks, J
Your Codepen example defaults to Arial font. If you look in Dev tools (Chrome) you'll see the textbox as inner dimensions of 195x18, with the top and bottom padding of 10px, that's your 38 pixels in height explained.
Now set the .my_input class to use font-family: Tahoma;, now the inner dimensions are 191x19.
Why? Your browser is computing a reasonable value depending on the font size set or inherited on the element.
Excellent deep dive here, https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align.
Here's a key takeaway:
The Arial font describes an em-square of 2048 units, an ascender of 1854, a descender of 434 and a line gap of 67. It means that font-size: 100px gives a content-area of 112px (1117 units) and a line-height: normal of 115px (1150 units or 1.15). All these metrics are font-specific, and set by the font designer.
Note the 1.15 value. If we calculate (font size) 16px x 1.15 the result is 18.4. On Internet Explorer the height of the TextBox element is 18.4px (Chrome displays only 18px, an example of browsers treating this differently).
It's not the font size that's being changed, just the line height of the element.
In summary line-height depends on font-family, font-size and your browser. For this reason height is the more appropriate property to guarantee the result you expect in this case.
As is (roughly) explained in this answer, height is the vertical measurement of the container, and line-height is the distance from the top of the first line of text to the top of the second. line-height is equally divided above and below the text, and on inline elements (like <input>), specifies the height that is used to calculate line box height.
line-height has no influence on height, as can be seen in this fiddle.
Despite you not explicitly specifying a height, an <input> element cannot exist without one, and so it is automatically generated for you. According to MDN, the default height is calculated in the following way:
By default, the property defines the height of the content area. The content area, bounded by the content edge, contains the "real" content of the element, such as text, an image, or a video player. Its dimensions are the content width (or content-box width) and the content height (or content-box height).
This correlates to roughly 18px on most browsers.
Your <input> defaults to 38px because it inherits the 18px default height, plus the 20px of padding. Adding a custom height attribute overrides the default setting, and thus you end up with an <input> element with a height of 36px.
Hope this helps! :)
Consider the following example:
<!doctype html>
<html>
<head>
<style>
td {
padding: 0;
background: red;
}
img {
display: block;
}
</style>
</head>
<body
><table
><tr
><td
><img src="https://raw.githubusercontent.com/sinatra/sinatra/v1.4.7/lib/sinatra/images/500.png"
></td
></tr
></table
></body>
</html>
There's a red line in chrome on the right of the image. No such line in firefox. It doesn't seem like a space, because the html markup has no spaces between tags. It doesn't seem like a margin, because Developer tools doesn't report any margin.
What is this? How much space could it take?
I'm running chromium-47.0.2526.111 (64-bit), if anything.
UPD I made an example without spaces specifically to show that the red line is not caused by spaces.
Next, it was found the line appears when Zoom is, for instance, 110%. So, everything is supposedly clear now.
It is because of the way <td> elements are displayed. As you can see, they are displayed as:
display: table-cell;
This is because of how table-cell is ment to calculate pixels. Since 1 pixel is not equal to 1 pixel in CSS if you have DPI scaling enabled (or you zoom), it will start to behave weird.
You can either find another approach of your <td> inside <tr> or simply change the display to display: inline;
It's all because of how pixels sizes are calculated. I know it sounds weird, but 1px is not 1 physical pixel. Essentially what happens is your td's background changes according to the size of your image. When your image hits an odd number (because of zooming or DPI scaling), it will either round down or up. This is when the calculation happens and is wrong.
Sources: https://www.w3.org/TR/css3-values/#absolute-lengths
http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html
There is no red line for me on initial load, however I can see red lines if I zoom in, which begs the question, is your browser set to zoomed in?
Look for the magnifying glass in the url bar of google chrome and make sure you're set to 100%
Causes when not zoomed
Since you have padding set to zero on your td element, that's fine, and the only thing that can make the same effect is to have the margin on the image (the margin on the child element sort of behaves like a padding on the parent element in this case). The margin could be set either by you, or by your browser's stylesheet (I don't see it on mine).
Set img {margin: 0} and it should be gone because you've covered both cases that could cause it.
Zooming problem
If you see it only when zooming, it's because of browser's sub-pixel rendering (when the pixel values become floats and the browser starts rounding or flooring them). And due to the extremely non-power-of-two dimensions of the image (313x161) it's highly likely to get that extra pixel line on various zoom levels when, say at 110% zoom, the calculated width of the td is 313.636 pixels, and the image 312.997 pixels, which become 313 and 312 when floored. That leaves us with the td element being one pixel wider than its child image, which is where the line (the red td background not being "covered" by the image) comes from.
img {width: 100%} fixes this (as Aziz already said in the comments)
This may help you:
td {
padding: 0;
background: none;
}
The correct answer is that for several years Chrome has handled images in tables defectively and no one can comprehend that this the actual problem. You have to take the images out of the table and put them in divs...
hello i have this problem:
as you can see the left hand side there is a screenshot of how it is in chrome, right hand side firefox. the text has not the same height. the structure of the html is quiet simple. its just a div in which is a fieldset in that is placed a h1 tag. around that there is a border of 1px. that h1 tag has a height of 20px and even a line-height of 20px. next is a h2 tag with the same sizes. the problem is the text-height.
in firefox it seems that this is 1px lower than in chrome and safari.
i'm using a css reset from eric meyers in its latest version. so it should not beeing caused by that.
it would be great if someone have hints to help me out.
thanks alot.
The default line-height varies by a wide margin in different browsers, and for different font families at different font sizes. Setting an explicit line-height addresses that.
This is due to differences in how browsers handle subpixel text positioning. If your line-height is 20 pixels but font-size is 15 pixels, then the text needs to be positioned 2.5 pixels from the top of the line box. Gecko actually does that and WebKit just rounds positions to integer pixels. In some cases, the two approaches give answers that differ by a pixel.
In any case, making sure that your half-leading is an integer (i.e. that line-height minus font-size is even) will make the rendering more consistent if you really need that.
Try this:
div h1 {
-webkit-padding-before: 1px;
}
Another possible solution:
#media screen and (-webkit-min-device-pixel-ratio:0) {
div h1 {
line-height:19px;
}
}
I'm using a basic list in my website which works fine with FF and IE. However, there is one line of pixel missing with Chrome.
JsFiddle thanks to Jared in comments.
If you don't see the missing line, change the value of zoom, it will appear at some values (90% for instance on my PC).
Any idea of the source of the problem?
Screenshot:
The grey line jumps of one pixel.
The main problems found:
On some screen sizes, the width of the dt and dd, plus the horizontal margins and padding, may be adding up to more than 100% for each line. The safest approach is to use % values for the widths, as well as the horizontal margins and padding, rather than em.
The use of margins to place the dd tags on the same line as the dt tags is problematic. A safer way to implement the layout is to float every dt and dd tag and specify clear:both for each dt tag. It may be possible to do this correctly using margins, but floating the elements is much simpler.
Updated demo. (note: This demo hasn't had any margins or padding added to it. The widths of the dt and dd should be reduced by however much is added to the horizontal margins or padding.)
Minor font problems found:
What's consistent
No font-family was specified, so the default serif font is used.
No font-size was specified, so the default of 16px is used.
line-height:2em is twice the font-size, which is twice 16px, which is 32px (shown by the height of the gray first line.
The height of the gray first line is 32px in both Chrome and Firefox.
What's not consistent
In Chrome, the default serif font with a font-size of 16px renders with a baseline height of 12px (the height of a capital H).
In Firefox, the default serif font with a font-size of 16px renders with a baseline height of 11px.
What can be avoided
The default serif font renders inconsistently in different browsers. There's no way to prevent that font from doing so. But you can avoid some of the inconsistency by choosing a font other than the default serif font. Some fonts, like Arial, render more consistenly from browser-to-browser.
What can't be avoided
Even then however, there will still be some inconsistencies in how text renders. Within the line-height space used by the text, the position of the text will often vary by at least 1px from browser-to-browser. That's not something that can be prevented. It's a result of how the operating system happens to render that particular font-family at that particular font-size with that particular line-height in that particular browser. But the inconsistency can be minimized by always specifying an explicit line-height, which has already been done in this case.
Summary
Choosing a font-family, a font-size, and a line-height helps to minimize the inconsistency. But beyond that, there will always be little inconsistencies in the text that cannot be avoided. Every website on the internet has some amount of this. It's usually not very noticeable.
I've noticed when using ruler tools from my browser extensions (I've tried multiple) that pixel specifications are typically short by 2 pixels. After noticing this on a site I'm working on, I tried a very simple html page with a div specified with a width and height of 200px and no border or padding. Measuring it out afterwards across multiple browsers and with various ruler tools, the actual rendered box both width and height is 2 pixels shy of my css.
So, curious why this is. What contributes to the "physical" size of the box, screen resolution perhaps? Not the end of the world if this is really how it is, seeing as how it seems to be a consistent thing.
EDIT
Per the comments and reply, my code, very simple:
<html>
<body>
<div style="width: 200px; height: 200px;background: red"></div>
</body>
</html>
And I'm measuring from outside-to-outside. Like here:
If the box you are drawing with your cursor starts inside the box you are measuring, it will be 2 pixels less than if the box you are using to measure starts outside the box you are measuring.
Here is a little graphic:
best is use reset css to ignore such issue
http://yuilibrary.com/yui/docs/cssreset/
I just measured the height of the box above with the (freeware) pixel ruler I wrote, A Ruler for Windows, and it measured just fine as 200 pixels.
I'm a little confused by your box inside the big red box, but the inside box measures a width of 50 if you count the burgundy boarder as part of what needs to be measured.
Of note, with A Ruler for Windows (when it is horizontal) the line on the left edge of the ruler counts as pixel one, and if the ruler is set to a length of (for example) 200, the line on the right edge of the ruler counts as pixel 200.
In other words if you are measuring something that is, for example 3 pixels wide, you would see the 1 pixel on the left to start the ruler, only one pixel in the middle, and finally one pixel on the right to end the ruler.
This is done in this way to allow the ruler to be moved to the two edges of your screen and to have those pixels on the edges counted.
Would it be possible that the two pixels you seem to be shy are the two 1 pixel widths on either end of the ruler?
ref: www.arulerforwindows.com
I'm chalking this up to browser weirdness. Taking screenshots of pages and comparing them in photoshop, they line up perfectly.