1 line of pixel missing with <dl> in Chrome - html

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.

Related

font-size varying on container width in iOS

We have a number of divs on a page containing text. The text is explicitly set to a certain font-size via CSS. In some circumstances the font-size is increasing without our intervention. It seems to be related to the length of the text in the DIVs. i.e. once it gets to a particular size adding a character increases the font-size, removing it again reduces the font-size.
We haven't got any fancy libraries included to scale the font.
In chrome dev tools it shows the variation in the font set via CSS, and then the computed size here:
Why does the font go from 16px to 19.555555px? What are we missing?
thanks!

How to calculate the height of an inline element

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.

is there a css text reset?

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

How to achieve same line heights in firefox and chrome?

When using same font, chrome and firefox give them different line heights, and sometimes you need them to be the same across browsers... Right now when encountering this issue, i have to give both font size and line height in pixels, but it doesn't seem like the best solution. Should different units be used may be? How do i make chrome and firefox render fonts similarly?
You can set line height as a pure number, which will by definition be taken as relative to the element’s font size, e.g. line-height: 1.2.
You can alternatively use the em unit, e.g. line-height: 1.2em, but then inner elements would inherit (unless they have their own line height set) the computed value, not the relative number. This matters if nested elements have different font sizes, and usually it’s the relative line height that should be used.
Please use a CSS reset from Yahoo, that should resolve cross browser issues.

font-size different in -webkit and -moz browsers

Check this jsfiddle
Why is there a difference in size of the datepicker when font-size is set to 1.5em?
The amount of em's is not important I have tryd different font-sizes and I still get the same problem. The red box is set to 460px and is there for you to see the difference in size of the datepicker in firefox and chrome/safari.
Edit: I have already try'd using px insted of em
Firefox uses DirectWrite to render text, and Chrome doesn't.
That is the reason for the ever so slightly different size of the rendered text.
There is no way to make the text pixel-perfect the same size between the two browsers.
Read this: http://www.basschouten.com/blog1.php/font-rendering-gdi-versus-directwrite
And this, particularly the "Hinting and spacing differences" section: http://blog.mozilla.com/nattokirai/2011/08/11/directwrite-text-rendering-in-firefox-6/
Because 1.5em isn't a precise size and depends on what the browser decides the relevant font metrics to use are.
If you want a precise size, use either px or points.