Recently a client has complained about the appearance of a system font in IE6. Basically th issue is that IE6 doesn't support font-smoothing/anti-aliasing (I know you can turn it on in an OS setting or something). But someone threw out this gem:
"You can force font anti-alias in css by using pt instead of px."
I did a quick POC in various browsers and saw no difference. I found one reference to it online, last post on this forum:
http://www.webmasterworld.com/css/3280638.htm
This sounds like the equivalent of a web developer urban myth, my feeling is it's BS. Has anyone ever encountered it?
Oh yes you can:
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
font-smoothing: antialiased;
Source for Firefox, thanks Justin for the heads up.
There's these exciting new properties in CSS3:
font-smooth:always;
-webkit-font-smoothing: antialiased;
Still not done much testing with them myself though, and they almost definitely won't be any good for IE. Could be useful for Chrome on Windows or maybe Firefox though. Last time I checked, they didn't antialias small stuff automatically like they do in OSX.
UPDATE
These are not supported in IE or Firefox. The font-smooth property is only available in iOS safari as far as I remember
No, there's not really any way to control this as a web developer.
Small exceptions are that you can do some fake forcing of anti-aliasing by using Flash through sIFR, and some browsers won't anti-alias bitmap/pixel fonts (as they shouldn't, more info: Anti-Aliasing / Anti-Anti-Aliasing).
Also, as Daniel mentioned, it's ideal to be using em units for all fonts, see The Incredible Em & Elastic Layouts with CSS for more information about this.
I found a really awkward solution using the zoom and filter ms-only properties
Example (try with no aa, standard and cleartype):
http://nadycoon.hu/special/archive/internet-explorer-force-antialias.html
How it works:
-zoom up text with zoom:x, x>1
-apply some blur(s) (or any other filter)
-zoom down with zoom:1/x
It's a bit slow, and very! memory-hungry method, and on non-white backgrounds it has some slight dark halo.
CSS:
.insane-aa-4b { zoom:0.25; }
.insane-aa-4b .insane-aa-inner { zoom:4; }
.insane-aa-4b .insane-aa-blur { zoom:1;
filter:progid:DXImageTransform.Microsoft.Blur(pixelRadius=2);
}
HTML:
<div class="insane-aa-4b">
<div class="insane-aa-blur">
<div class="insane-aa-inner">
<div style="font-size:12px;">Lorem Ipsum</div>
</div></div></div>
You can use this short jQuery to force anti-aliasing, just add the ieaa class to anything:
$(function(){ $('.ieaa').wrap(
'<div style="zoom:0.25;"><div style="zoom:1;filter:progid:DXImageTransform.Microsoft.Blur(pixelRadius=2);"><div style="zoom:4;"><'+'/div><'+'/div><'+'/div>'
); });
Adding the following line of CSS works for Chrome, but not Internet Explorer or Firefox.
text-shadow: #fff 0px 1px 1px;
I disagree with Chad Birch. We can force anti-aliasing, at least in Chrome using a simple css trick with the -webkit-text-stroke property:-
-webkit-text-stroke: 1px transparent;
I say its a myth.
The only difference I've found between pt, px, and percent based fonts is in terms of what IE will scale when the Menu > View > Text Size > ?Setting? is changed.
IIRC:
the px and pt based fonts will NOT scale
percent based fonts scale in IE just fine
AFAIK:
The font anti-aliasing is mostly controlled by the windows setting for "ClearType" or in the case of IE7/IE8 the IE-specific setting for ClearType.
I think you got it a bit wrong. Someone in the thread you pasted says that you can stop anti-aliasing by using px instead of pt, not that you can force it by using the latter. I'm a bit sceptical to both of the claims though...
The px to pt fix worked for me on a site that uses a font from Google Web Fonts. On Win7 - IE8 it correctly fixed the lack of anti-alias rendering.
Using an opacity setting of 99% (through the DXTransform filters) actually forces Internet Explorer to turn off ClearType, at least in Version 7. Source
Here's a nice way to achieve anti-aliasing:
text-shadow: 0 0 1px rgba(0,0,0,0.3);
I doubt there is anyway to force a browser to do anything. It would depend on the system configuration, the font used, browser settings, etc. It sounds like BS to me too.
As a note, always use relative sizes not PX.
Seems like the most exhaustive solution can be found at http://www.elfboy.com/blog/text-shadow_anti-aliasing/. Works in Firefox and Chrome, although Firefox is not quite as effective as Chrome.
As a side note, Gecko and WebKit support the the
text-rendering
property as well.
Not a pure CSS but natively supported method without any font replacement hacks:
Simply convert your font to SVG and place it higher(before WOFF or TTF) in #font-face order. Voila! Fonts are smooth now, because they're no longer treated as a font but an SVG shape which will be nicely smoothened.
Note: I noticed that SVG can weight more than WOFF or TTF.
I found a fix...
.text {
font-size: 15px; /* for firefox */
*font-size: 90%; /* % restart the antialiasing for ie, note the * hack */
font-weight: bold; /* needed, don't know why! */
}
Related
I've been building this site for a while, however the font I use for headers looks ragged on Windows using Chrome, although it looks perfect on Mac or using Edge: Link
I did try the various font smoothing properties to no avail and using text-shadow makes it look strange.
Is there anything else I can try?
The font I use for headers looks ragged on Windows using Chrome
Your webkit-font-smoothing rule is missing a - prefix, it should be -webkit-font-smoothing
To solve the issue of Chrome font-rendering, add -webkit-text-stroke: 0.3px;
Difference:
Final code:
h1, h2 {
-webkit-font-smoothing: subpixel-antialiased;
-webkit-text-stroke: 0.3px;
}
* You may need to apply the above CSS to all selectors that use the custom font.
Preview
Original answer: https://stackoverflow.com/a/11493510/877671
voting to close as duplicate.
I've began working on a new site using REM units with PX fallbacks. Now, I have a question that may be silly, but I can't find anything specifically mentioning it so I'll just go ahead and ask here.
Using property shorthands and specific properties seems to both load take effect in the browser Chrome.
body{ font:16px/23px sans-serif;
font-size:1rem;
line-height:1.438; }
whereas using both shorthand or both specific properties cancels one or the other out (e.g. uses primary or fallback, not both)
body{ font-family:sans-serif;
font-size:16px; font-size:1rem;
line-height:23px; line-height:1.438; }
or
body{ font:16px/23px sans-serif;
font:1rem/1.438 sans-serif; }
Now which is exactly best practice here? All examples validate.
Is there a reason why the shorthands AND specific properties both load in the browser Chrome even though they're targeting the same properties? Are they actually both loading?
Does this have any adverse effects to how the browser/device is rendering the styles?
I've only looked into this via Chrome and I haven't been able to discern any differences through testing. But, You can see how it would be a little bulky if you HAD to use two iterations of the same code for all elements using rem's.
UPDATE:
Tested only in latest versions of all browsers below, all tests pertain to the first code snippet
In Firefox this doesn't seem to be an issue, it just replaces the font-size/line-height in the shorthand code with the rem sizing.
In IE, safari, & Opera it takes the shortcode and separates it into specific properties, but still loads the rem units ignoring the px units.
It seems to be specific to Chrome, at least in modern versions. So the question now, how to figure out how Chrome is handling it? The image, displayed at the bottom of this post, may explain a little more. See how BOTH font properties are loaded and neither are ignored or take precedence?
UPDATE#2:
When using margins, Chrome acts properly. I'll use the following "off the wall" example to demonstrate:
margin:16px 0 19px 0;
margin-top:1rem;
margin-bottom:1.188rem;
reads in chrome as:
margin:1em 0 1.188rem 0;
(source: leftdeaf.com)
This two resources will answer all of your questions:
http://snook.ca/archives/html_and_css/font-size-with-rem
http://blog.typekit.com/2011/11/09/type-study-sizing-the-legible-letter/
With line-height, use the unit, but not the value:
body {
font:16px/23px sans-serif;
font: 1rem sans-serif;
line-height:1.438;
}
or
body {
font-size:16px/23px;
font-size: 1rem;
font-family: sans-serif;
line-height:1.438;
}
You can't use FONT and FONT-SIZE, just use one or the other. Otherwise the browser will attempt to use both.
After a lot of wasted time and confusion... It actually does render correctly in Google Chrome. feeling silly now... I overlooked the drop-down arrow to the sub-properties in the Chrome Tools. Image displays what I overlooked. Example shows multiple examples of shorthand properties and specific properties, more importantly it shows the font property working, it wasn't crossed out but it was still being overridden. Not sure why it doesn't comply with the strike through like everything else, probably due to the font-weight, variant, style properties remaining unchanged. But it works.
I am using Google's web font api with the font "Lato", font-weight of 100.
On the desktop browsers I have tested everything displays fine. However if I view the web page with iPad or iPhone (both iOS5) I notice that the font is extremely thin and the only thing that seems to be displayed correctly are the dots.
I tried implementing the font using the Javascript, LINK-Tag and CSS #import methods, all produce the same results.
I saw that in the FAQs they state:
The Google Web Fonts API works reliably on the vast majority of modern mobile operating systems, including Android 2.2+ and iOS 4.2+ (iPhone, iPad, iPod). Support for earlier iOS versions is limited.
Which means it should work, right?
Is there anyway to solve this?
Thanks
Something I have seen to help really thin Fonts (Incidently also Lato) is this:
-webkit-text-stroke-width: 0.1px;
Anyway it's only a case by case basis, I would use a class / media query to make sure to only apply it when needed (safari(with a class set by js) on a scale under 1.0 or something). Try higher float values if needed.
It seems to me that it's an unlucky combination of an ultra thin typeface with the way Mobile Safari scales the website to fit in the screen. Normally fonts have hinting that allow your computer to interpret how to paint pixels if it gets to subpixel levels, but this is overridden by Mobile Safari's scaling, and thus paints half pixels as semitransparent.
You could prevent mobile safari from downscaling your website by adding the following meta tag:
<meta name="viewport" content="initial-scale=1.0; minimum-scale=1.0">
If you want the font to appear smaller in mobile safari, the solution would be to keep the previous declaration and declare the font size a media query:
#media only screen and (max-device-width: 480px) {
font-size: 15px;
}
If all else fails, I'd add a 0px text shadow:
.selector {
text-shadow: 0 0 0 white;
}
Maybe it's -webkit-text-size-adjust 's fault.
Try
-webkit-text-size-adjust : none
You could try adding this to your CSS for the element in question:
-webkit-font-smoothing: subpixel-antialiased;
Similarly, you may have transforms effecting the antialiasing. You could also try:
-webkit-transform: translate3d(0,0,0);
And even...
-webkit-backface-visibility: hidden;
Crazy, I know.
Are you using Ultra-Light 100? If you set it to 100 but the file is another weight Mobile Safari could be trying to simulate the thinner variant.
Either way, try -webkit-font-smoothing: antialiased;, if that doesn't work you're out of luck, try the 300.
I have a website which uses CSS for all of its styling, and in Windows, the line-spacing and font sizes are all consistant accross Firefox, Opera, IE, Safari, Chrome.
I have just tried it under Firefox on the Mac (Snow Leopard) and whilst the fonts generally look a little more bold than on windows, the general sizing looks about the same.
However, in Safari on the Mac, all of the fonts appear so much smaller, line-spacing is much tighter also.
What is the likely cause of this? Is it a known scenario, perhaps with a nice workaround?
If you would like to check the situation, the site in question is:
http://www.marcusstarnes.co.uk
Thanks
Since you set font-size in em (a good thing - don't change that!) the font-size depends on the browser settings / user preferences. You've probably got a smaller font set on Safari.
On the other hand, if you are in the "all browsers must look a-like, or the world will end" camp, then you shouldn't be using ems.
I'm unsure about the line-height: 1 in the reset style sheet. That just seems wrong to me...
EDIT:
Oh wait, I just discovered font-size:62.5%;. Doesn't change what I said, but that is uncomfortably small for many, because you are using two thirds of the users preferred size.
I know this is an older post, but I recently ran into the same issue. The only browser I was having trouble with was Safari on Mac. What I ended up doing to resolve the issue was change my reset from :
html { font-size: 100%; overflow-y: scroll; -webkit-text-size-adjust: 100%; -ms-text-size-adjust: 100%; }
to
html { font-size: 16px; overflow-y: scroll; -webkit-text-size-adjust: 16px; -ms-text-size-adjust: 16px; }
This just forced the browsers to all use the "medium" font size and then scaled it from there. The only reason I am adding this is because there really wasn't an answer given. Hopefully this will help someone that comes across this.
For IE 6 we have plenty of bugs to bug us as a designer.
incorrect box model etc etc.
i have searched for fixes via JavaScript and found
[link text][1]
IE7.js
IE7 is a JavaScript library to make Microsoft Internet Explorer behave like a standards-compliant browser. It fixes many HTML and CSS issues and makes transparent PNG work correctly under IE5 and IE6.
but do we have real life saver other than javascript via css.
Ways to deal with IE6 bugs with CSS? Sure.
See: http://www.quirksmode.org/css/condcom.html
for conditional comments
There are other ways, such as adding some specific characters in some CSS properties that get ignored in some browsers but not in others.
However, in some cases, web designers should be very cautious when using these.
The alternative is to live within the IE 6 world of bugs and design your pages to look right despite them. You can serve up different css for your IE6 clients, or even different html if necessary, depending on your design. In some cases, you can use one CSS file that will mean different things to IE6 clients, but that technique is problematic with respect to IE7 and 8.
this link is also handy one
How do you deal with Internet Explorer?
I never knew this - thanks svinto
"IE6 doesn't have the incorrect box model unless you have the wrong doctype. – svinto"
There are some simple stylesheet hacks that can modify the presentation in various internet explorer versions to solve your CSS problems. For example these three:
Simplified box model hack for IE4, IE5, IE5.5:
div.values { margin: 10px; m\argin: 20px; }
star html hack for IE4, IE5, IE5.5 and IE6:
* html div.values { margin: 5px; }
star first-child+html hack for IE7:
*:first-child+html div.values { margin: 5px; }
PNG transparancy issues could be solved with solutions like this:
<div style="width:50px;height:50px;filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='/images/logo/logo.png');">
<img src="/images/logo/logo.png" height="50" width="50" alt="" style="filter:progid:DXImageTransform.Microsoft.Alpha(opacity=0);" />
</div>
Great info so far but one thing to note is that IE7.js doesn't fix pngs in all cases (at least last I looked). For instance, you won't be able to tile a background image with transparency.
In the case of DXImageTransform you may find that when this is applied to elements that contain links, those links are no longer 'clickable'. You can sometimes fix this by giving the parent element that has the transform applied to it static positioning and to position the child anchor element e.g.,
h2{
position:static;
zoom:1;
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src="/images/mypng.png", sizingMethod="scale");
}
h2 a{
position:relative;
}
<h2><a href="" >a link!</a></h2>
If you have to do this sort of garbage put it in a separate stylesheet and control loading with conditional comments. If the design is of any complexity try you best not to support ie6 or <. If you can't avoid doing it, charge more ;). Sometimes that is enough to persuade someone that supporting ie6 isn't "worth their while".
why don't you try FireBug Light for IE? It's not as powerful as FireFox FireBug but can be helpful
Many bugs can be worked around in CSS using conditional comments or CSS selector hacks. But there are some bugs that CSS hacks alone cannot handle such as IE6's .multiple.class.selector.bug
There's another quick and dirty hack for IE6 styles
for e.g.
You can define the CSS as;
.divTitle
{
padding: 5px;
width: 600px;
_width: 590px;
}
All the other browsers picks up 600px as the width value & IE6 overwrites it & take 590px;
I've tested this in IE7 & FF as well.
Also you may want to check this link;
link text