I have an apparently identical element that's rendering slightly differently on two web pages. I'm sure it's down to some subtle difference in the CSS between the pages, but I can't pin down what it is. One is a live server with various layers of asset compilation and minification, the other is a static mockup.
The HTML is pretty simple:
<div class='category-icon'>
<span class='glyphicon glyphicon-globe'></span>
</div>
And the most immediately relevant CSS isn't much more complicated:
.category-block .category-icon {
font-size: 6em;
}
.glyphicon {
position: relative;
top: 1px;
display: inline-block;
font-family: 'Glyphicons Halflings';
font-style: normal;
font-weight: normal;
line-height: 1;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
}
.glyphicon-globe:before {
content: "\e135";
}
Here's how it renders in Firefox, with the inspector on so you can see the bounds:
Note the height difference -- 120 vs. 84.
Here are the computed styles from Chrome, which shows the same behavior. Again note the difference in the rectangle height, and the grayed-out height values. (The Firefox inspector shows the same results, but doesn't give height.)
As you can see, it's nothing in the margin, border, or padding that's causing the difference; it's something about the rendering of either the <span/> itself or the surrounding text elements. (Note that the line-height is correctly 120px for both. Is there some reason the line-height would affect the height in one version but not in the other?)
As far as I can tell, the actual HTML is byte-for-byte identical. So I assume the problem is somewhere in the hairier parts of the CSS.
How should I go about diagnosing this problem? What else is likely to be causing the height difference, if I've drilled down this far and can't see anything in the inspector?
Edited to add: The applied styles (from the Chrome 'styles' tab) also appear identical -- see overlaid screenshots here.
David, you need to look at the truncated styles in your DOM inspector through the styles tab. The heights are different in your two examples. Computed styles will tell you what the page has rendered and the style tab will show you all the CSS rules being applied to your element. Look for a rule that is similar to height: 120px;
You will find the culprit there.
Related
I'm working on a project where the height of the content container is limited, and on a few select browsers (mostly Chrome on Android) the text seems to be breaking in different places, even though almost all font properties seem identical, so far I've checked:
Width of the container element
font-size
line-height
font-family
letter-spacing
All of which are identical, both in their given and computed values.
This wouldn't usually be a massive problem, but because of the content container height constraint, these discrepancies are causing me a massive headache.
I've managed to replicate the problem in a fiddle with the following code:
HTML
<p>We are not able to sleep or We cannot sleep.</p>
CSS
p {
font-family: "Times New Roman", serif;
font-size: 11px;
font-style: italic;
letter-spacing: 0;
max-width: 200px;
}
The text in this example renders on one line in the majority of browsers, however in some the last word "sleep." appears on a new line.
You can see screenshots of this example in a number of different browsers at:
http://www.browserstack.com/screenshots/cf75bb4fa9a22db2e660a0073698be86b55becb6
Is there something I'm missing here? Is there any way to ensure the text will render in the same way accross a number of devices and browers?
The details of font rendering vary by browser and platform, and they cannot be controlled in CSS. Besides, different computers may have (slightly) different fonts under the same name, or e.g. lack Times New Roman entirely (most smartphones lack it, for example).
As a workaround, if specific line division is crucial, consider writing the text as preformatted (i.e. dividing it into lines in HTML source the way it should appear in display) and using white-space: pre. The drawback is that some lines might hit or even cross the right edge of the area reserved for the element. But if you do not set a background or border, this will be barely noticeable.
I'm afraid that the only solution here is using an image using width="XXX" or tell the client that is completely impossible to make a web identically on every browsers unless you use disgraceful methods just like using an image instead of text.
I was able to solve the problem in my browser by replacing the max-width with min-width see this http://jsfiddle.net/79j57L8L/4/
p {
font-family:"Times New Roman", serif;
font-size: 11px;
font-style: italic;
min-width: 200px;
}
It's been a while (2 years?) since I've done a bigger website. I'm now developing one and as usual, I ran onto some cross-browser difficulties.
The problem I'm solving now can be seen on the picture below - I have a page with a h2 element, which displays differently in Chrome and IE 11. The element has all the properties like line-height, font-size, padding, margin and so fort specified, but still displays differently. In one browser, the text is right on the top of the element, in the other one, it is in the middle. This causes some graphical issues and I can't seem to find a way to resolve this without writing a browser-specific css definition for each browser (Firefox does something similar to and is somewhere in the middle of these two - the text is in the upper part of the element, but not on the very top of it).
The other similar elements like h1 are affected as well.
I understand this is likely related to the way these browsers handle fonts and calculate their positioning, but at the moment, this doesn't help me much. I'd be grateful for any advice you might have, since I'm probably not the first one to be solving this.
EDIT:
I won't insert the HTML code here since this affects all these elements regardless of where they appear. For an instance, the text highlighted in the page is a normal h2 with the following CSS attributes:
color: rgb(0, 0, 0);
display: block;
font-family: 'Myriad Pro', Arial;
font-size: 22px;
font-weight: bold;
height: 27px;
margin-bottom: 0px;
margin-top: 20px;
text-transform: none;
width: 634px;
normal has this css:
font-size: 14px;
margin-top: 10px;
margin-bottom: 12px;
line-height: 17px;
So I've found a solution. Little surprising, but makes sense.
I'm using Typekit from Adobe, which is something like google fonts. I actually found out that the cause of this text-shifting is the fact that I'm using the typekit font. When I switched to Arial, everything was fine.
I also came acrticle which describes the topic: http://blog.typekit.com/2010/09/13/updating-vertical-metrics-for-cross-platform-consistency/
The problem has to do with baseline and em boxes set wrong in the given font I used. Switching to another font which had these properties set correctly fixed my problem.
Thanks for all your help guys.
I have been wracked for days trying to find why I can't use the MS blur & glow filters to generate a drop shadow in Internet Explorer as appearing on this page:
http://kilianvalkhof.com/uploads/ieshadow.html
Here, a second text element is positioned under the first element, offset a bit, and the filters applied. My layout is using the same technique, for a drop shadow on the H1 element at the top, which shows fine in standards-compliant browsers, but the filtered element is not showing in IE8 or IE9:
http://a11.cosd.com
My markup uses a <span> like the working example:
<h1>AREA11<span class="IEshadow">AREA11</span></h1>
with CSS the same except for the selectors:
#headerContainer header h1 span.IEshadow {
display: none;
}
.lt-ie10 #headerContainer header h1 span.IEshadow {
display: block;
position: absolute;
left: -4px;
top: -4px;
z-index: -1;
zoom: 1;
filter: progid:DXImageTransform.Microsoft.Glow(Color=#000000,Strength=2) progid:DXImageTransform.Microsoft.blur(pixelradius=5,enabled='true');
-ms-filter: "progid:DXImageTransform.Microsoft.Glow(Color=#000000,Strength=2) progid:DXImageTransform.Microsoft.blur(pixelradius=5,enabled='true')";
}
But in my layout the filters aren't applied at all, even though I can see the filter: properties are listed in IE8 and IE9 with the (F12) Developer Tools. This isn't the first time I've used Visual Filters in a design, but in this case I've copied the code character by character.
One odd thing: when I view the filter: property in IE8 developer tools, it shows the other properties lumped together on the same line, though they appear normally in IE9 where the problem is still happening.
I have tried everything I can imagine, including disabling all other Javascripts from the page and simplifying the markup and CSS, as well as avoiding font-face and putting the <span> in IE conditional comments as in the working example... no change. (I need to avoid the IE conditional comments to eventually implement this in jQuery.)
There must be something very basic I am missing here about why MS filters won't work in this context. I will absolutely summarise any progress & findings here if my layout changes in the course of testing.
This is a z-index issue. The .IEshadow is positioned behind the background.
Give your h1 a z-index of 10 and it should work.
#headerContainer header h1 {
...
z-index: 10;
}
You might also want to change the color of .IEshadow
.lt-ie10 #headerContainer header h1 span.IEshadow {
...
color: #000000;
...
}
Must be something basic I'm missing here. I thought that font-weight:bold should not change how much vertical space the text takes. Especially when the line-height is set to be higher than the font-size.
http://jsfiddle.net/Arkkimaagi/7xAyy/
On my OSX chrome those three text heights do not match. The second one with font-weight:bold is 1px higher than the rest. The third div is just an example of fixing the problem (poorly)
I'm trying to set the line-height to something specific (18px) here, to have "vertical rhythm"
My question is, how can I have bold and normal text both with same line-height as in the example?
[edit:]
here's what I see on my mac
Also, here is what I ment by "vertical rhythm": http://www.alistapart.com/articles/settingtypeontheweb
- the baseline grid is more visible in the example: http://www.alistapart.com/d/settingtypeontheweb/example_grid.html
Sometimes adding top vertical align will solve this (depending on font size/family).
strong { vertical-align: top; }
In your fiddle example, because you have set a line height on the container (div), you can simply add the following:
span { line-height: 1em; }
It completely depends on the fonts you are using. Nothing about OSX or Chrome text rendering would ensure that two different fonts (and Helvetica-neue and Helvetica-neue-bold are two different fonts) would have the same vertical space even at the same font-size and line height.
Even though that is too much to ask you might think that two different fonts from the same family might be consistent, and usually they are, but sadly the two fonts you have chosen are not.
Setting an absolute line-height on both the container and the bold text, or giving bold text a line height of 1em (as DaveC says above) both fix this, e.g. from the jsfiddle you just need to add line-height: 1em
.bolded span {
font-weight:bold;
line-height: 1em;
}
Or why not follow HTML standards and use the correct tags instead of bolded spans? E.g.
strong, em { line-height: 1em }
I've encountered very similar problem with Chivo font: http://www.fontsquirrel.com/fonts/chivo. Right now I'm using the ugliest hack (works on current Firefox and Chrome, IE untested yet):
strong { vertical-align: top; position: relative; top: -1px; }
I try not give up on Chivo quite hard as you see ...
I think this is a font issue. I found differing line heights for the italic variant of Nunito (Google Web Font). When I switched to a reworked version of that font called "Nunito Sans" the issue was resolved.
A few days ago I re-skinned my website. Development of this skin was primarily done using safari, and as expected, it all renders fine using firefox and opera. I've had to make a few small tweaks for IE7, but nothing much, except for one problem...
The date indicators for a post are cut off in IE. This problem seems to occur only on nested span tags inside a left floating div. I think I need the floating div's in order to layout text on the left and the right side of the screen.
Do any of you know how to stop IE7 from clipping my text?
Edit: I have sort of given up on this problem. My scripts now check for IE7 and feed it somewhat simplified HTML that its limited engine can handle. It works in IE8, so, for now, just the special case for IE7 will have to do...
In most cases where IE6 or 7 clips off the bottom of text, just add:
line-height: normal;
to the CSS rules concerned. Should fix it nicely, but as you'll understand, it expands the box too.
There's a hack I figured out that fixes the problem of cutting off text in IE. I noticed the last line in my headline was the only one being cut off.
My original CSS which was cutting off the last line in IE7 but looked fine in other browsers:
h2 {
font-size: 22px;
line-height: 1em;
}
See image of problem here: https://skitch.com/pablohart/f4g3i/windows-7-x64
The fix I did included simply adding padding to the bottom and then taking that padding back with negative margin. Like this:
h2 {
font-size: 22px;
line-height: 1em;
padding-bottom: 5px;
margin-bottom: -5px;
}
See picture of fix in this image: https://skitch.com/pablohart/f4g4h/windows-7-x64
The problem with line-height: normal; is that it takes on the default line-height for the font, usually 1.3em.
Try adding overflow: visible; to your .postdate class. Maybe that helps.
I had a similar problem. I changed my span to a div and the problem was resolved. I think IE7 might have an issue processing line-height on a span. Haven't confirmed that to be the issue. There were other CSS elements. (Working on someone else's code.) But changing from span to div (block) resolved the issue.
for the .bigdate class, try replacing margin with padding; seems to me that this has something to do with IE's margin-handling.
Adding a specific height to .title fixes it for me (in IE6):
.title {
PADDING: 0 10px 0 0; MARGIN-top: 0.3em; FLOAT: right; height: 1em;
Despite being unable to test it on my current machine: I would suspect that it's a hasLayout bug. The methods of dealing with it are listed in the "properties" section of that link.
In my experience its invariably the bottom of the text that gets clipped and that too basically because of the overlapping divisions. If you are able to ensure that the divs don't overlap then the issue does get resolved . That apart adding overflow: visible does help at times.
Try adding
div.postmeta { height: 100px; }
div.postdate { height: 75px; }
Arbitrary height value... but you'd know the exact height you want. That should keep the text containers from clipping in IE7.
I think the problem is with the padding. I tried removing a "padding: 3px" style and it worked properly. Previously it was not showing anything. Paul Hart's answer showed me that.
Probably also removing/overriding margin properties may also help.