I'm using this CSS to style a div:
#mainSection .mainArticle .text {
width: 600px;
margin-top: 0px;
margin-left: 20px;
line-height: 26px;
color: white;
float: left;
font-family: 'Open Sans', sans-serif;
font-size: 15px;
}
The image below shows the difference between Safari and Chrome:
I can't tell why it's this different. The font looks 'bolder' in Chrome, yet each character takes an tiny bigger length in Safari, meaning it sticks on average less chars on each line. Because the div box size is fixed length, the result is that the text ends too close to the bottom border.
I can't have variable length boxes. You can see the site here (go to MENTORING section):
enter link description here
Is there a convenient way around this problem? I know the font engine is different for each browser...
i think it is because the browser size is not same for all the browsers, and you have defined your CSS in terms of pixels., try to convert from pixels(px) to percentage(%) or em/rem values.
i hope this helps.
Safari renders open sans bolder than in chrome so you would need to apply a lighter font weight for safari Open Sans Google Web Fonts Rendering in Chrome
The reason is that whereas other browsers render the font at the exact size specified, Safari renders fonts in a series of steps.
I assume that the Apple team feels that fonts rendered at 10.3px look better than fonts that are rendered at 10.0px. (made up values).
The consequence is that you get different results between Safari and other browsers.
The easiest way to see this in action is to define a font size as a percentage, then slowly resize the window:
Test page at svija.love
In other browsers, the font will resize smoothly with the window. In Safari, the font size will increase in a series of jumps.
I am looking for a workaround for this (help, somebody!) because this behavior is screwing up my layouts and making it look like I have spelling errors at Ozake.com.
[update fall 2021] I wrote a program that combines the various text blocks into a single line, eliminating spacing problems. See svija.love for more information.
Related
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 must have went through every page of google but haven't found the solution yet. I have a custom font that I'm using through css font-face. The font adds extra padding on the bottom depending on the browser and OS that I am using. The picture below shows an example with mac being on the left and windows on the right. It looks correct on the right (in windows) and i want it to be the same on mac.
#font-face
{
font-family: universLight;
src: url('http://www.viggi.com/fonts/UniversLTStd-Light.otf');
font-weight: normal;
font-style: normal;
}
#button{
font-family: universLight;
border: 1px solid black;
background: #ccc;
}
The code is located at http://jsfiddle.net/ZDh5h/
Here is what I already know won't work from my research.
line-height adds padding to the top and bottom so the extra padding on the bottom remains.
using different extensions such as .otf or .ttf also doesn't work. Just produces the same results
changing the font-size also doesn't really do anything
I use this font a lot through out the site and don't really want to add different CSS sheets for mac vs windows. If anyone knows anyway to fix this without having javascript add extra padding I will be very grateful.
Thank you.
See http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height
normal
Tells user agents to set the used value to a "reasonable" value
based on the font of the element. The value has the same meaning as
. We recommend a used value for 'normal' between 1.0 to 1.2.
The computed value is 'normal'.
I think the behaviour you observe comes from different "reasonable" values across browser as normal is the default line-height value.
So specify your value (say line-height: 1.5em;) to get rid of the differences.
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.
Image below displays the result for:
div.test { background: #00F; font-size: 50px; line-height: 50px; color: #FFF; margin: 50px 0; font-family: Wiesbaden; }
One using Wiesbaden (which is font-face) and the other without.font-face font seem to ignore the line-height property.
Is it font-face issue or the font?
The property line-height only specifies the vertical distance between the start of one line and the start of the next. If you typed out something that took up two lines, the start of the 2nd line should be in the same vertical position using either font.
It seems like that's just how your font looks at 'font-size: 50px'. If you wanted to, you could increase the font-size while keeping line-height: 50px to correct it.
In short, it's not an issue with either. They're behaving exactly how they should be. See your blue background? That's your line-height. Line-height doesn't affect the font itself, but rather the spacing of the lines of the text.
Some fonts are different sizes even when set to the same font-size. It's the way the glyphs are rendered. If you want your text larger, increase the font size. If you want fallbacks to be the same size, you can use similarly-sized fonts (look up "font stack generators" for help on this), or check out the CSS3 font-size-adjust property (do note that it is CSS3, so you'll want to double-check support of it).
I had a similar issue, but I used a Cufon script instead of fontface to avoid browsers issues. To solve my line-height issue I changed the doctype from transitional to strict. Try that.
The following fiddle illustrates the differences between 4 fonts (3 being very common fonts found on Macs, PCs, etc). One is a Google-font. Regardless, 4 fonts - four different results. If a design is going to rely heavily on a 'non-standard' font, be sure the fallbacks don't blow the whole thing up.
Pay particular attention to the differences in:
the top spacing between the capital Q and its parent's border
the various heights of the Xx (especially, the lower-case vs capital)
descender of the lower-case G (some actually come out of their
parent)
_http://jsfiddle.net/suK2U/
I tried this and it works perfectly!! just play with percentage until you find the needed result.
Apply this on your #font-face:
ascent-override: 90%;
Hope it helps!
More info:
https://developer.mozilla.org/en-US/docs/Web/CSS/#font-face/ascent-override
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.