I have a page that is multi lingual and I have an issue with the Japanese version only.
For some reason in IE8, when I hover over an element, a sibling's font-size will increase/decrease.
Even stranger, is that this doesn't happen on every hover, sometimes I cannot reproduce straight away, I need to keep hovering over different elements in the same area of the page. Eventually this bug will rear its ugly head.
This bug only occurs on the Japanese page, all other languages seem to be fine.
This could be happening on other versions of Internet explorer, I haven't tested on all.
To clarify, I have not got any font-size changes on any :hover rules.
I work for a Japanese site and recently came across this issue. After spending more time than was reasonable, I found the answer from these detailed write-ups in Japanese:
http://freesoft.tvbok.com/sonota/ie8-fontsize.html
http://social.technet.microsoft.com/Forums/ja-JP/internetexplorerja/thread/70d700f4-0bda-48b1-9476-d31993b7cbf4/
The top link includes the ways to deal with it. For those who can't read Japanese I will summarize:
The problem only affects IE8 showing pages using the MS P Gothic font (generally the default Japanese font on Windows) at a font-size that is between 9px and 11px. Unlike many IE bugs, it has nothing to do with floats/margins/line-height/etc. As Oldie has pointed out, the bug is not consistent, sometimes it happens right away and sometimes it takes a few hovers, and it seems to enlarge/shrink the text randomly.
The three primary solutions are as follows:
Set the font to MS Gothic or some other Japanese font using font-family style.
Change the font size to be anything outside the 9px ~ 11px range (Under the default IE8 font settings, 1em sized text will not be affected, but slightly smaller text (eg, 0.8em) will be affected).
Force IE8 to display the page as if it was IE7 by adding the following in the header:<meta http-equiv="X-UA-Compatible" content="IE=7" />
I went with #2 because MS Gothic looked jarring next to all the other MS P Gothic text, and felt #3 had clear disadvantages for our site.
It's not an ideal solution, but it works. Best of luck.
Related
I’m experiencing an issue with Safari where a block of text using webfonts (not sure webfonts are the issue) is wrapping differently in Safari than it is in any other browser. In this particular instance, we’re designing these blocks to look like they’re set to text-align: justify; but they’re actually set to text-align: left;. text-align: justify; is undesired in this setting as it does a poor job of calculating the space between words.
Important things to know:
As I mentioned, the layout uses webfonts. It doesn’t matter which webfonts (I’ve reviewed hundreds and it happens for all).
The entire page, including padding and font-size, uses viewport width (vw). The idea here is that the block of text scales equally for all browser sizes and retains it’s layout, including rags.
A visual aid:
Details about the layout and dimensions:
Frame 1: Safari desktop.
Frame 2: Chrome desktop.
Frame 3: Chrome at 50% opacity over Safari.
Window width in this screenshot is 1220px.
Left/right padding is padding: 0 calc(129 / 1220 * 100vw); which computes to 129px.
That leaves the available content space of 962px.
letter-spacing is set to 0 by default for all content.
So, anyone have any idea why Safari seems to have exaggerated tracking/letter-spacing?
EDIT
We just launched the site in question, so you can see the issue in action here: https://www.typography.com/fonts/hoefler-text/overview
Well, there's a bunch of stuff at play.
First of all Chrome and Safari use different defaults for rendering text, But in addition to that Chrome on different versions of MacOS or Windows will render text differently too because of how the system font rendering works.
You can typically make Safari and Chrome (on the same system) feel a bit closer by setting your text CSS to:
text-rendering: optimizeLegibility Since this is the default on Chrome but Safari defaults to optimizeSpeed
It might also be wise to explicitly set: font-feature-settings: "kern"; and font-smoothing: antialiased (note those both need vendor prefixes)
Next, make sure to specify a numeric font weight. Eg: font-weight: 400 for "regular". (The browsers might not pick the same weight for the normal/bold keywords)
Finally, make sure you're serving up the most optimized version of a webfont (Typekit & Google usually do this for you, but it's an issue if you're self-hosting the fonts)
Edit:
It might be worth forcing both Chrome and Safari to create a "compositing layer" (basically means its GPU accelerated). You can do that with backface-visibility: hidden. Though I suspect this is a MacOS specific thing and there may not be a solution in the browser.
Adding font-feature-settings: "kern"; to the element for the fonts solved my problem with Safari not rendering the letter-spacing properly.
I had the similar issue while building an html banner using a .woff font: Safari was applying an exaggerated tracking/letter-spacing.
Bryce's suggestion to use font-weight: 400; fixed the issue.
Please see the above image. I'm using the icon font 'FontAwesome' on my website. In the website header, I'm using them for navigation icons. Each of these icons are links, that have the 'fa' and 'fa-2x' classes attached.
I'm not overruling any default font sizes or rendering modes for FontAwesome, so this is a clean state. All screenshots are from Windows 8.1, testing several browsers. Here are my findings:
Firefox: perfect rendering, optimal balance between legibility and anti-aliasing
Chrome: font rendering too thick and harsh, hurting legibility
Safari: reasonable legibility, yet a bit too thin and harsh
IE10: Very close to FF, acceptable as-is
Opera: Same as Safari
Mu ultimate goal would be to have ideal rendering across browsers, as per the Firefox example. A perhaps more realistic goal is to beat Chrome into submission, as it presents the biggest issue.
Font-Awesome by default has this applied:
-webkit-font-smoothing: antialiased;
I've tried setting this to the other text rendering modes, yet none seem to make a meaningful difference, the same is true for setting the text-stroke property, even at 0 the 'thickness' problem remains. That problem is best seen from the 'members' icon.
You can see the rendering live at www.jungledragon.com
Any clues/tips on how to improve rendering quality and consistency?
That's old issue I can see, but I had similar problem with FontAwesome and discovered that weight of these icons can be different depending on font-weight attribute (that's a font, after all).
So, my problem was that narrow holes in icons becomeing invisible in my app and the solution was setting the font-weight attribute to normal in CSS.
For my liking, icons in Chrome version of your issue are just "overweighted" that way.
Here is an example:
First - how it looks in Chrome, second -in Firefox (hardly readable).
CSS:
font-family: Arial,Liberation Sans,DejaVu Sans,sans-serif;
font-size: 13px;
Can you please provide an example, how I can make this element's font bold only if browser is Firefox?
When I test 13px Arial, it looks slighty lighter in Chrome than in Firefox, rather than the other way around as in your case. Stay tuned to variation across browser versions, platforms, and settings, as regards to font rendering.
Usual browser detection techniques could be used in JavaScript to check whether the browser claims to be Firefox and modify CSS code accordingly. But this would be a shot in the dark, partly due to the variation mentioned, partly because there is really nothing you can do to fix the assumed problem. Bolding tends to change the overall appearance of text, not just slighly thicken strokes, and bolding often reduces readability.
Ways to avoid creating problems like this: Do not set font size to something as small as 13px. Especially for small font sizes, use black (or something very dark) on white (or other very luminous) background, instead of the opposite, and in particular avoid making the color contrast too small.
it seems firefox can only take 2 background url in css... if it has a 3rd the font makes that blurry/pixelated effect. NEVER THE LESS.... i found that its true on a windows XP. the same firefox on a windows 8 works fine. (I was surprised) i might think it has something to do with the "use hardware if available" option in forefox.
Try removing a background "image" or "color" from one of the table's CSS.... if its solved then... firefox sucks.
I have one very surprising issue with Google Fonts. This is the site in question.
The title is normaly showing in one ligne but a friend of mine with the same Opera version like me sent me this screenshot. You can see that the title goes in two lines and brakes every think.
It's the first time I use Gfonts and must admit that there is another problem in Firefox too - the font appears so jagged!
Thanks for your advises!
The line break can be prevented simply by adding
h1 { white-space: nowrap; }
Font rendering depends on the font, on the font size, on the browser, on the operating system, on the device, their settings, and probably phase of the moon, too. Some fonts are more difficult than others, so the practical move is to pick up another font.
Unfortunately, not all browsers render all fonts exactly the same way. I guess your problem with the title in Opera is caused by the font being rendered bigger. You can try to target a specific stylesheet for Opera to solve that.
As for the jagged font, well... you have to deal with that, and choose fonts that will look sharp on every browser.
Take a look here : http://css-tricks.com/font-rendering-differences-firefox-vs-ie-vs-safari/
The jagged issue was solved thanks to this Joomla! extention - KC Cufón Font Replacement. A have included just the characters of my text - only 3KB of js and I left the same Google Web Font loading too in order the text to be shown until the extention loads.
I have come across an odd problem using 'Helvetica Neue W01 97 Black Cn' #font-face font from webfonts.fonts.com
When used in Windows based browsers (tested FF and IE), in this case in a submit button, the text seems to acquire an extra 4px or so of padding (see ff-pc-style.png). In the case of my current design, this centers it perfectly in the submit box.
In OS X, across Firefox, Safari, Chrome and Opera, the padding is lost, yet an extra 0.4px is added to the line height and height (see ff-pc-style.png).
If I remove the custom font, the fallback font (Arial), appears properly centered in OS X.
Why does this occur? And how would I get round it?
Platform detection seems like overkill just to fix a font ...
ff-pc-style.png
ff-pc-style.png
E-mail reply from fonts.com support:
A fault has been found in the font
data hinting. It is being looked at
now. Once the data has been updated, I
expect that you will only have to log
into your account and just save and
update your stylesheet to update your
page.