Well, since you wouldn’t see those in FF, Opera or webkit either… I’d suspect there’s something wrong with your embed method.
The use of multiple SRC declarations could be a contributing factor when you only have one target. There’s a reason I like the “fontsprint syntax” for handling that. It’s pretty much bulletproof everywhere.
If you don’t have the formats for other browsers, font squirrel does a great job on conversions and even gives you sample code to work from.
Pretty much your entire second line of “src” is probably what’s messing things up… given what a rare/uncommon font droidsans is, I’d not even waste time TRYING to check for a local copy.
Oh, and be sure it’s the VERY FIRST THING in your CSS, or it may get ignored in legacy browsers – needs to go before ALL other code… including @charset – not that there is ANY reason to use @charset since valid CSS is restricted to ASCII7… meaning the character encoding should be a total non-issue!
Probably the ONLY reason it’s working for you in IE7+ is the check for the local copy, since the TTF link is also macha pookah. I’m not seeing them here in ANY version of IE because I don’t have that font installed locally. Again, probably why I don’t bother with checking for ‘local’ is you can’t test if the web version is working with those present.
– edit – oh, and if you have to target EVERY version of IE with it’s own stylesheet and IE conditionals, there is likely something DISASTROUSLY wrong with how you’re trying to build the page.
I found the solution. My relative URL to the font file was incorrect. My mistake was making it relative to the root folder of my testing area, where the html files were, and instead it should have been relative to the root folder of my whole web site.
since ‘test’ is a folder in the root of my website. Now IE displays the embedded font.
Really if you have to absolute path them or up-tree link them (as per Scallio’s last example) IMHO there is something flawed with your directory structure. HTML > CSS > stuff called by CSS… Down-tree for the win.
breaks the font embedding for IE, but not Firefox. I read somewhere that the path was related to the root of the domain, even though I am just working inside a buried test folder on my site. I’ll try and find the reference.
Should work just fine. CSS paths are relative to the path of the CSS file itself. Since it’s in the same DIRECTORY…
Of course you’ve got three separate CSS files in two directories with NO media types… talk about over-complicating the page… but then you’ve also got that IE conditional comment nonsense for nothing too, alongside “classes on everything” for no good reason, that clearfix bull like it’s still 2003… and of course the layout breaking from the use of dynamic fonts inside px metric containers…
OK, the source I had read about the path being related the root of the entire web site it sat on was wrong (whew!, so glad for that). I changed it to this, since the fonts and the embedded font css file are in the same directory, and it seems to work:
But CSS? Based on the location of the CSS file.
It’s the odd man out, but that can actually be quite handy as if you put all the stuff that’s “presentational” under the CSS in it’s own directory, it makes having multiple skins for the same markup easier.
Hence the difference between content images and presentational images. Content would be images that are the same regardless of the skin – presentational would have to be customized for the skin.
Since that’s one of the other reasons to use CSS; multiple appearances off one HTML.