Answered
The best answer below was good for the bounty, but user Aaron's answer is the correct answer. Setting:
.sIFR-flash {
width:100%;
}
corrects the issue in Chrome. Sadly, I cannot change my best answer as I guess that's how bounties work.
Answered
I seem to be having some issues with Chrome specifically rendering sIFR replaced text stretched out (and blurry) in it's flash container. No other browser does this (looks good in IE6,7,8, FF, Safari, Opera). Is this a known bug/does anyone have a workaround?
Here's an example you can look at on this site: http://uvph.com/
And here's the replace code:
// -- configure sifr
var futura = { src: '/swf/bfuturah.swf' };
sIFR.activate(futura);
sIFR.replace(futura, {
css: [
'.sIFR-root { background-color:transparent; color: #999999; font-size:24px; text-transform:uppercase; }'
],
fitExactly : true,
forceClear : true,
forceSingleLine : true,
selector : 'h2',
transparent : true
});
I can't use #font-face as my font embeds poorly and I need selectable text. To fix the vertical stretching for my sIFR in IE9 I added
display:block;
height:1.45em;
to the .sIFR-flash
which seemed to match up to IE8 and Firefox
I also used a body font-size of 70%
It gives an extra little flicker while loading but the stretching has stopped.
I noticed that setting the width of .sIFR-flash to 100% seems to correct the issue.
hmmm this is a really strange one. i've uploaded a testcase of your site to my server and everything works fine in chrome. the much better alternative to sifr is http://cufon.shoqolate.com/generate/ its much smaller and much faster, but you cant select the text anymore
Use #font-face property of CSS. It is now supported across all popular browsers(including IE and Chrome). http://www.useragentman.com/blog/2009/09/20/font-face-in-depth/ has a very good post about using #font-face across all browsers and the page itself uses custom fonts. Worth checking =)
First of all: set "forceSingleLine" to "false".
If this still doesn't help: check the CSS properties of the text you want to be rendered. Display-type of the rendered element itself (not the parent!) should be "block", otherwise "width: 100%" has no effect at all. The best results for Chrome can be achieved if sIFR is applied to a block element with fixed width - but this approach will not always be feasible.
I suspect it's something odd between Chrome and the Flash player. It's as if the Flash movie is scaled up incorrectly. The movie fixes itself when you click on it.
What if you set sIFR.useDomLoaded = false before sIFR.activate()?
Related
On one of our websites, we use a font from typotheque.com by importing it as follows:
#import url( "http://fonts.typotheque.com/WF-XXXXX-XXXXX.css" );
The font is displayed correctly on Chrome and the like. In Internet Explorer 11 on Windows 7, the font is rendered, but the width of it is not correct. It seems as if the width of the text is rendered before the font is applied.
As a consequence, the text gets overlapped and the words are not wrapping accurately:
On Chrome, the font width is calculated and the words are wrapped correctly:
Other things we tried:
We followed the instructions here on typotheque.com
We made sure to link the css files prior to the javascript files, as stated here.
Any hints or pushes in the right direction to solve this issue are much appreciated. You can find the website here: http://www.claireundgeorge.ch/fr/
Edit:
Added word-break: break-all; : no change
Removed all the font-awesome-stuff: no change
When you compare what is calculated in FireFox with what is calculated in IE you can see whats the bad boy here.
In IE the padding-bottom property of the h2 is 4px.
When i uncheck this property it looks fine for me.
I cannot upload pictures here due to the stupid reputation limit thing but i hope i descriped it good enough...
I also have typotheque webfont + IE problem. My workaround for now is a bit dirty: I use jquery $(window).load to adjust element padding by 1px, and then IE redraws the font correctly.
Site in question:
http://www.sedulity.tk/
Site using Chrome 19 dev:
Site using IE9:
as you can see on the homepage using IE it seems like it not recognizing the height of the DIV of each picture, whereas on chrome and firefox there is no issue.
I think this is probably my fault, won't blame IE for it...but I can't figure it out :|
In your css folder there is a css file ie7style.css and it's being used for ie (I've tested in ie8) and it has a class (.item-image) that is
.item-image{
height:142px;
}
Try to fix it or just remove it.
Css file: http://www.sedulity.tk/wp-content/themes/DeepFocus/css/ie7style.css
See in this developer Tool screenshot I've removed the css entry height:142px from class (.item-image) from file ie7style.css
After that (without .item-image{height:142px} in file ie7style.css) see the page in ie8
Try adding a height to the .item
CSS
#portfolio-items .item {
height:500px;
}
you might wanna check this article for a cross-browser inline-block that doesn't overlap. your case is most likely caused by the "baseline", where the next set of elements base their tops on the last elements' baseline (which would be somewhere in the middle of the element).
I'm working on a site and I have some problems that I hope you guys can help me with :)
If I put bold on my text in the menu it looks too bold in Firefox :S, but it looks fine in Chrome.
In Firefox the double border on the #content container is outside of the shadow effect :S, but looks good in Chrome.
Screen shot on Mac Firefox 5.0.1 and Chrome 13.0.782.112:
This is my project.
I hope some one can help me out with this.
If you have something I better I can do, I will be glad to hear that too :)
Your first issue regarding bold font looking different between the browsers is just because of the way browsers render text differently. There is nothing you can do about it, unless you go the horrible route of using images instead.
Your second issue is not about the border but rather the outline. It is caused because of the way Firefox interprets the outline when box-shadow is applied. It applies it outside of the shadow instead.
You can put the code below in your css to target Firefox and bring the outline back in:
#-moz-document url-prefix() {
#content{
outline-offset: -11px;
}
}
Live example: http://jsfiddle.net/tw16/n8bet/
#1: There differences in font rendering in every browser. You can try numeric values instead of simply bold to narrow the results ( http://clagnut.com/blog/2228/ ). Also read the answer on this SO entry: Same font except its weight seems different on different browsers
#2: remove this line from #content css:
outline: 1px solid #B9BDBE;
Little background information here: I have narrowed down the problem, but can't determine what the fix is. In IE6 the input box won't allow me to use my mouse to select it.
Please go here to see the problem: http://www.malahatautoparts.com/business-application/
The problems stems from an IE6 fix for the CSS background.
#main{
background-position:-9999px -9999px;
filter: progid:dximagetransform.microsoft.alphaimageloader( src='http://www.malahatautoparts.com/wp-content/themes/malahat/images/bg-main.png', sizingmethod='crop');
}
If I remove that from my IE6 css file, input box all of a sudden works.
Any ideas on what I can use to fix this?
The conditional comment you have there for "less than IE 7" isn't even working right for the PNG transparency it's supposed to fix in IE6: I'm seeing grey background around the transparent corner areas. In IE7 the transparency works natively without loading that stylesheet.
The method you're using in the IE stylesheet relies on the alphaImageLoader filter, which I suspect is blocking over top of the HTML form controls on the page.
There's an alternate method that uses VML instead: check out DD_BelatedPNG. I'm not 100% sure if it will solve your problem, but I have a hunch it will, and it's a cleaner solution than what you're using now.
<textarea> and <input> selections: selectionStart and selectionEnd are not implemented in IE, and there's a proprietary "ranges" system in its place, see also Caret position in textarea, in characters from the start.
Also see What are the typical reasons Javascript developed on Firefox fails on IE for common reasons of failure of Javascript/CSS in IE which work in Firefox & other browsers (or vice versa).
Some excellent tips so you can get a uniform look & usage in all browsers.
use css with
#main{
background-position:-9999px -9999px;
filter: progid:dximagetransform.microsoft.alphaimageloader( src='http://www.malahatautoparts.com/wp-content/themes/malahat/images/bg-main.png', sizingmethod='crop');
position: relative;
}
Sometimes IE6 will render the text of a <ul> list the same color as the background color. If you select it, they show back up, or if you scroll the page up and back down.
It is obviously a rendering bug, but I was wondering if anyone knows of a workaround to make it reliable?
try giving it hasLayout with
zoom: 1
Have you tried explicitly setting a line-height? For some reason this seems to be the solution to a great many IE6 rendering bugs!
e.g.
.mylist {
line-height: 1.6em;
}