I want to ask if there is a solution to tackle browser inconsistencies when it comes to text positioning (vertical offsets). With just a few px, the differences are small and not a big problem if there is enough space around the text. But when there is a visual border near the text, different distances to the top and bottom can be annoying.
Here is an example with screenshots from various browsers:
Relevant CSS:
div {
padding: 0;
font: bold 2em/1 Tahoma;
}
(Codepen: http://codepen.io/anon/pen/MwQemQ)
The differences depend on the font which is being used. In this example, it's only 1 px with Tahoma, but with other fonts, like Helvetica on OS X, the offset is bigger. Is there a solution (apart from browser sniffing) for this issue? Thank you!
Related
I am working on a label printing app in Electron and seeing strange behavior on elements that are rotated -90 degrees. The behavior is the same in Chrome's Print Preview window:
Rendered html on left, print preview on right (Sorry, I can't embed images)
You can see all of the barcode fields, as well as the firstname, lastname, children, pager fields are being rendered in the Print Preview window like there is a line break before the content, making it overflow out of the parent container. Other elements with the same rotation are not rendering that way (pagerno, securitycd, datetime).
I have tried making the font size much smaller in those elements, down to like 10-12px and they still have that behavior when printing, so it doesn't actually appear to be content size related.
Edit - On further inspection, the behavior does go away once the font gets to about half the size. So in the example below, the barcode font is 23px - at 13px, it stops wrapping or inserting a new line or whatever it's doing...
The HTML on a rotated element looks like this:
<div style="left:3.535in;top:0.125in;width:0.31in;height:2.03in;">
<div style="transform-origin: left top; text-align: center; transform: rotate(-90deg); width: 2.03in; height: 0.31in; top: 2.03in; left: 0px; font-size: 23px; font-family: Code128;">
<span>barcode text</span>
</div>
</div>
The CSS looks like this:
body,div {margin:0;padding:0;font-family: arial, sans-serif;}
div {position:absolute;border:1px solid #ccc;overflow:visible;display:inline-block;}
#font-face {font-family:"Code128"; src:url("./fonts/Code128.woff2");}
*, *:before, *:after {box-sizing: border-box;}
I have tried removing the width and height from the outside div, removing the width and height from the inside/rotated div and still see the same behavior.
We have three different varieties of thermal label printers on hand with different size labels and the behavior is similar, but different in each. Meaning, rotated elements wrap like this in all of them, but some printers more than others.
I appreciate any feedback or insight and will keep an eye out here for any questions or request for further info.
Thanks!
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 was creating some HTML/CSS to display a key, but ended up with a weird vertical misalignment if the text for the title vs the text for the items.
After a lot of experimenting I found that the problem only seems to happen when the text is bolded, and furthermore only when using the Lucida Sans font.
You can see a demonstration of this problem here... http://jsfiddle.net/Ufa69/
HTML...
<div class="key">
<div class="t1">title:</div>
<div class="item">item</div>
<div class="item">item</div>
<div class="item">item</div>
</div>
<div class="key">
<div class="t2">title:</div>
<div class="item">item</div>
<div class="item">item</div>
<div class="item">item</div>
</div>
CSS...
body {
font-family: "Lucida Grande","Lucida Sans","Arial",sans-serif;
}
.key {
padding: 2px;
font-size: 10px;
overflow: hidden;
border: 1px solid #666666;
background: #eeeeee;
margin-bottom: 4px;
}
.t1, .t2 {
float: left;
margin-right: 4px;
}
.t2 {
font-weight: bold;
}
.item {
float: left;
margin-right: 4px;
}
In the demo you'll see that the text aligns correctly in the first div, but in the second it's misaligned. The only difference between the two is that the second one used bold.
You might be thinking, "So, use a different font".
But there's the catch - Lucida Sans is the default font for jQuery UI.
So I'm hoping that some clever CSS-guru can maybe find another way to get this text to behave correctly when bolded.
(The problem appears for me on Windows in Chrome, Firefox, and Safari, but not IE)
they are misaligned because bold and normal text allocates space differently as if bold increased font-size comparing to a normal text.
My solution here is to increase font-size to the normal text so that it will be still normal text but same size as the bolded one.see my update to your fiddle below.
.t1{
font-size:12px;
}
http://jsfiddle.net/Ufa69/1/
NOTE: there are a lot of options you can do so the bold and normal text align properly. You can use tables td's or divs with fixed widths.
Maybe I'm not good for this kind of thing. But I ain't see the misaligned issue, it really seems aligned here. (Chrome v31)
Things that happen:
To make font bold, a couple of pixels are added in font letter to do the effect.
Obviously, it gets more visible in text with small size.
Each browser, and even version, renders the font differently.
Each text, each line of text, have their font-size and the line-height. By default, line-height is auto and will squeeze to height of content. All this behavior is called, line box.
In text, with font-size: 10px, line-height will be a couple of pixels higher.
As much you will increasing line-height size, the content gets more space to go up, down, middle, etc, as defined in attribute: vertical-align
As size is added to the text, fatally it will increase line-height too.
So, I have a lot of options to do to make up this. Almost all, by changing font-size, line-height, vertical-aligns, margins.. and it's very hard to accomplish a strictly successful result.
One particularly that is often used and I like is just reduce the size of bold text in 1 or 2px.
.t2 {
font-size: 9px;
font-weight: bold;
}
You can also limit height & line-height of wrapper container to improve to leave it more equal.
See fiddle to confirm you like the result.
Nice ..
I saw that line-height differs from your .t2 (11px) and .item (14px) but even firebug doesn't mention 'why' or inheritance.
Fix line-height to 14px all around with .key{line-height:14px;}.
[edit]
After seeing it in action, i can't figure out why the line height is not inherited from .key classes elements to their children <div>
I fiddled here the same solution of 'line-height' but applied to children divs.
.key,.key div{line-height:14px;}
Some browsers apparently use odd box height calculations. This can be seen even in a simple setup like
<style>* { font-family: Lucida Sans }</style>
<p>foo<p style="font-weight: bold">foo
Inspecting this in Chrome dev tools shows the height of the first p element as 15 pixels, the height of the second p elements as 14 pixels. This makes little sense; we could expect a boldface font to require more height, but hardly less. Note that height calculations are up to browsers and do not necessarily use line-height values directly.
In your case, the best workaround is probably to use some logical table markup rather than floating. In a table, lines normally get aligned even though the box heights vary.
CONCLUSION: small sizes of Lucida Sans bold renders incorrectly (on some systems).
After a lot of testing all sorts of options, like setting line-height, using tables, trying different sizes, and vertical-alignments, and making measurements, I finally concluded that the problem is simply with the rendering of small sizes of Lucida Sans bold.
If you create two divs with borders, one using regular Lucida Sans at 10px and the other using the bold version, you can see that the bold one is noticeably shorter (in height).
When aligned to top, the bold font is a couple of pixels higher than the normal font.
Align to bottom, and it's a couple of pixels lower than the normal.
Even aligning to middle, it's still a pixel higher than the normal.
The BAD NEWS:
Lucida Sans is a default font for jQuery UI, and is generally a very popular font, which means this affects a lot of web pages.
It's not consistent across browsers, so tweaking
it to work for Chrome might throw it out on IE.
The GOOD NEWS:
It only happens on small versions of the font. I found that anything 13px or larger seems to render correctly.
At these small sizes you can easily substitute "Arial", "Helvetica" or similar, without anyone noticing the difference.
Thanks to everyone who gave their ideas, like using tables, line-height, etc. In the end though I think the only sane option is to avoid small versions of Lucida Sans. You can still use it for most of your web page, and just substitute with a similar more reliable font for sizes less than 13px.
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.