Using selectivzr and @font-face breaks layout in IE8 and below

Not sure if we can do much to fix this problem within Omega. It's really a bug in selectivizr it seems which I am not the maintainer of. Maybe it would be better to bump the issue on github (last comment was nearly a month ago) and describe your findings there. Putting the @font-face declaration into really isn't a nice solution to the problem.. Rather an ugly workaround. Really not sure how we are supposed to fix this :).

I ran into this a while back when trying to use selectivzr with Omega 3.

Other than the suggested hack of adding the @font-face declaration directly to the markup (which does work, but is nasty) I've found that the JS technique for using web fonts as employed by the @font-your-face module when using the Typekit service (and possibly other services? - untested) seems to side step this bug entirely.

I realise that this restricts font choice to those services that are working in this way but if you're aware of this parameter up front it doesn't have to be too painful. UPDATE: see #4 below for solution.

Agreed that we need to bump the issue on Github though (have already done that).

I've been playing with this a bit more lately and the best solution I can find is to load all web fonts via JS. The @font-your-face module may not do this for you on its own as it uses a variety of different import methods depending on where you are importing your fonts from.

So you need all fonts loaded via JS. The Web Font Loader library from Google/TypeKit makes this a bit easier given its flexibility and support for various sources (including custom/local). The Webfont Loader module makes this even easier in that you won't have to write or see a single line of Javascript and offers integration with the fancy interface provided by the @font-your-face module (though I've not tried this part yet).

I use a combination of web fonts served up from certain remote services (TypeKit, Google Fonts) as well as locally served custom web fonts for icons. The above solution caters to my needs, plays nice with Selectivizr and even chucks in a few bonus features for the hell of it. Save yourself any more IE testing agony than is necessary and give it a whirl :D

Yeah... I guess since we can't do much on the side of Omega to fix this issue we can just as well close it. We should probably document it though... Who's up for that?

Who's up for that?

A leading question if ever I saw one ;)

I'd be happy to do it but it'll have to wait as I'm completely rammed at the moment.

Short term solution: stick a placeholder page up in the docs, point to this thread so that people have something to go on and I'll look at writing something a bit better when I get more free. Otherwise, if anyone else feels like jumping in sooner - the info's all here, go for it.

Ohm has the fonts imported in _typography.scss and people will pick pieces of it to use in their own layouts ... as I did ... which causes this problem. Took me 3 hours to figure this one out ... maybe add a comment in the _typography.scss file?

Thanks for mentioning Google Webfontloader in this issue.

I stumbled across the same issue this morning - by using https://drupal.org/project/google_webfont_loader_api it could be solved very easy. Just take the custom sample font provided by the module and create .fontinfo files and some CSS including the @font-face rules for the fonts you want to embed.

SteffenR

@SteffenR It's fairly easy to do it with the Web Font Loader library directly, without an additional custom module. That way your theme is solely in charge of the fonts it's using, rather than having to depend on a module (there are a couple other small benefits to this approach too). Read https://drupal.org/node/2091805 for a comparison of either approach.