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;
}
}
Related
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...
I am studying the Introduction to Linux as edX. The study page has a menu with 14px font size, and the actual content has 12px font size. I would like to reduce the font size of menu so that it takes less space. Simply making the div thinner is not a solution , it needs a smaller font size.
What CSS rule could I add to the menu's top-most div to affect all child divs' font sizes? I tried style="font-size:0.5em", style="font-size:50%", and style="font-size:8px" however none of these were able to overcome the CSS defined for the inner divs.
I stress that this question pertains to a website that I do not control, rather, I am trying to add a rule using the Firefox Inspect Element feature.
Not very pretty, but
.menu * { font-size: 11px !important; }
could be what you are looking for. Or,
.menu { transform: scale(0.8); }
although that could affect other things in undesirable ways.
You could also try using the non-standard:
.menu { zoom: 80%; }
Setting a font size of 0.5em on the parent element only works if the children also use em units. On the page in question, it seems that other units are used (px, probably). In this case, you can use the font-size-adjust property on the parent element to reduce the font size of all children. font-size-adjust is normally used to define the font size in terms of "x-height", so you should try values around 0.5.
Edit: As #Jackson pointed out, font-size-adjust only works on Firefox, but maybe that's good enough for you.
I have a span element with the following CSS:
span.test {
font-size: 20px;
line-height: 1;
}
Why the calculated height of the span seems to be 22px? Where do these 2 extra pixels come from?
Is it possible to make it tall 20px without using inline-block ?
Here is the simple jsbin I used to test: http://jsbin.com/tigevecemoco/1/edit
The CSS 2.1 spec says:
10.6.1 Inline, non-replaced elements
The 'height' property does not apply. The height of the content area should be based on the font, but this specification does not specify how.
As it happens the height, as opposed to the line-height, of a non-replaced inline element has very little effect on anything else so browsers are pretty free to report whatever number they like here.
However, a little reverse engineering can be instructive.
If we look at the font metrics for Times New Roman, we see EM size of 2048, WinAscent of 1825, and WinDescent of 443. Sum the ascent and descent, divide by the EM size, multiply by the font size (20px) and round to the integer and we get 22px.
Taking Arial as another font, we have EM size of 2048, WinAscent of 1854, and WinDescent of 434. Do the calculation again and we again get 22px.
What about a different font? Tahoma has EM size of 2048, WinAscent of 2049, and WinDescent of 423. Do the calculation again and this time we get 24px. And hey presto, if you try your JsBin with the Tahoma font, Firefox does indeed show a height of 24px.
The font metrics above were obtained from loading the fonts into Type Light 3.2.
Not conclusive, but a reasonable suggestion of how it all works.
Is it possible to make it tall 20px without using inline-block ?
Assuming the above is correct, you should be able to achieve it by using a custom font and modifying the font metrics of that font to suit. I wouldn't like to predict the knock-on effects of doing that though.
I couldn't find an answer to why it is applied. I found many forums with the same question...
But, as an answer to your request:
Is it possible to make it tall 20px without using inline-block ?
I managed to do it only by floating the element. It seems to lose whatever it was that was padding it... Then, setting the line-height to specific 20px makes it work.
span.test {
font-size: 20px;
line-height: 20px;
float: left;
}
<span class="test">A</span>
EDIT
Actually, adding float works because it makes inline elements behave like block elements.
See: https://developer.mozilla.org/en-US/docs/Web/CSS/float
'line-hieght:1' is inherited from parent. try own line-height.
MDN line-height
why the span's line-height is useless
Hope this helps.
I used JS Bin http://jsbin.com/siqabekoloja/1/edit to solve your issue. I was able to get it consistent in IE, Chrome and Firefox. I believe the problem is you need the element to be block not an inline element .
Hope this helps. If you want them to be next to each other just float them left or right.
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.
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