i am noticing in my web app that the same input form font size, currently set to 17px, reads smaller on chrome compared to firefox. i've attached a screenshot.
is there a more elegant method to resolve this than simply using
/*chrome*/
input {
font-size:17px;
}
/*firefox*/
#-moz-document url-prefix() {
input {
font-size:15px;/*reduce font size to match what is seen in chrome*/
}
}
I don't know what font you're using (or platform (Mac vs Win makes a difference too) , but some browsers render fonts using CLEARTYPE subpixel rendering, some use QUARTZ subpixel rendering (making appearance differ), then others use standard antialias-ing.
A good way around this is to use font-smoothing css in your html or body css:
html {
font-family: /*yourfont*/;
-webkit-font-smoothing: antialiased;
}
Read more about it and see more examples on Max Voltar's website
Also note that using em is preferable to using px for measuring your font. Large font sizes are especially harmed by pixelation if you don't use font smoothing, so in order to keep accessible text especially, it's better to use ems (this way you can still use large type sizes).
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 the google fonts api, the font looks great on Google, but when I try to use it, it doesn't render properly. Here is an example:
https://twitter.com/dontdie/status/129234318299111424/photo/1
this is in Chrome, two different tabs. For some reason, Chrome is not using "subpixel rendering" ( http://en.wikipedia.org/wiki/Subpixel_rendering ) on my site, but on google it is turned on.
I think I figured this out. adding these rules to my stylesheet seemed to fix it:
body, body * {
background-color: #fff;
-webkit-font-smoothing: subpixel-antialiased;
}
Just setting subpixel-antialiased didn't work, and just adding a background color to the body didn't work. This could probably be simplified to select just * or html *. Also, given that subpixel-antialiased is the default, removing that rule should work as well.
I have a css definition in the head of my page as follows:
#font-face {
font-family: "ownfont";src: url("../fonts/ownfont.ttf");
}
Then i give a css class to the body (on button click) which changes the font type from:
font-family: Verdana,Arial,Helvetica,sans-serif;
to
font-family: "ownfont",Verdana,Arial,Helvetica,sans-serif;
"ownfont" is a 4-character font where spaces and hypen will be shown in order to show some non-visual characters.
Firefox 3.6.3 shows everything as excepted (looks the same as before except for spaces and hypen), but Safari (on Mac and Win; Versions 4.0.5, 5.0) changes the heigth of my text lines (or at least it looks like that or as if a padding/margin has been increased - but nothing has been changed except for the font).
Why does this font setting yield to different results in firefox and safari?
Is there a way here to force both browsers to behave the same?
any help or suggestion is appreciated - thanks in advance
Try specifying line-height: 1ex; in your css.
If you know what font(s) you're going to be using it with, it might be simpler to remake your font to have metrics more like the others'.
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! */
}