I use em as units for my fonts in combination with body {font-size:12px} (an absolute number, can be 20px or 14px...)
That works fine, but if I have multiple nested things,
like
h4{
font-size:2em;
}
h4 span{
1.6em;
}
.parent_elementofthespan span.superspan{
font-size:1.3em;
}
.basecamp3rdpartyclass h4.span{
font-size:1.9!important;
...
Now, things get pretty complicated in calculating the actual absolute font-size of .parent_elementofthespan span.superspan for example.
Is there any chance of "seeing" the absolute font-size within a tool or something besides calculating it manually?
In Chrome Dev tools
F12 > Elements > Computed > font-size
A value in pixels will be displayed.
You should use rem unit wherever possible.
rem is relative to :root font size (html element in HTML but it could be <svg> or in other cases) so no hard calculations!
In a nutshell, it's em without the cascade and 95% of the time it's what you need in your CSS.
Its compatibility is IE9+.
CSSViewer (a Firefox/Chrome extension) is way faster for checking font sizes (and other typographical properties like font weights and line heights, also color) on elements one after another than DevTools/Inspect.
Chrome extension
The original Firefox extension (has worked flawlessly for years BUT last update was 9 years ago: it may not work on Firefox 57+ coming in a few days :( RIP)
Related
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
For example, if I have:
td { font-size: 1.3em }
h2 { font-size: 2em }
h3 { font-size: 1.6em }
p { font-size: 1.2 }
And I have headings/paragraphs inside my table-cells, I know that I can avoid compounding the font-sizes by the following:
td h2, td h3, td p { font-size: 1em }
Which would result in the headings/paragraphs in my table-cells having font-size of 1.3em (that of the td).
But what I'm looking for is a nice, clean way for each child element to have it's original font-size, not that of the parent.
I'd really like to avoid doing the following (and of course I'd like to avoid using px):
td h2 { font-size: 1.54em } // 1.3 x 1.54 ~ 2
td h3 { font-size: 1.23em } // 1.3 x 1.23 ~ 1.6
td p { font-size: 0.92em } // 1.3 x 0.92 ~ 1.2
For anyone familiar with LESS, I'm using that, and thought I should be able to use it to do the calculations for me, e.g. Using accessors:
td h2 { font-size: h2['font-size'] / td['font-size'] }
This at least would use the original values to do the calculation but feels just as clumsy as the above and besides, it seems LESS no longer supports accessors anyway.
This seems so simple in concept, I feel like the answer's staring me in the face, but I've been banging my head against this for a while and can't find the answer anywhere.
What you want can be achieved by using rem units.
rems are relative ems which base their calculations on the font-size declared on the body element.
Compounding issues simply disappear.
http://snook.ca/archives/html_and_css/font-size-with-rem is an excellent article to articulate this.
note: IE8 requires a px fallback, but this won't be an issue since you're already making use of a preprocessor.
EDIT: I've written a Sass mixin which outputs rems with their respective px fallbacks for most CSS properties:
https://gist.github.com/larrybotha/4153104
I'll answer the same as my question, use Pixels!
A pixel is a relative unit, it's relative to the screen resolution, users can set their own desired minimum pixel size, and zoom zooms pixels. I'd venture that it is more difficult for a designer to approximate non pixel font-sizes at every perceivable resolution than it is to relax and let the browser tools take care of it?
It used to be that a font declared in pixels wouldn't resize in IE which was very annoying for some, not very accessible if a user deliberately chose to view on a lower resolution for instance for eyesight reasons - that's where the "em's were best for fonts" thing came from, but that was never true IE could be foiled using percentages instead which then offers the same problems ;).. I remember getting annoyed when the fad was for "teeny text", but then the joys of discovering CTRL+ in non-ie .. anyway now the pixel sized fonts will scale perfectly well, if you're building a fluid site you can build it with a mixture of em's for widths and pixels for font-sizes - if it looks OK at your resolution try zooming it, both up and down - you have to go pretty far up or down before it becomes illegible, and who's zooming it that far up/down except designers ;)
Have you considered adding a class to the headings that are in table cells? The extra level of specificity would override the effect of the cascading styles compounding each other, I think.
How to use em perfectly without getting nested issue?
How to get perfect needed size for every needed element?
If i use #Wrapper (font-size:62.5%) because it's easy to calculate font sizes.
How to deal with nested issues of font-size and line-height?
puts on flameshield
I've been using the 62.5% + em method for 3 years but I just made the switch back to pixels.
Why?
Pixels are a relative unit
There's less and less IE6 users ( meaning more people are able to resize properly now and you don't have to worry about IE6's caveats as much )
Modern browsers having better support for zoom in/out
You save time - everyone understands pixels and there's no math involved in regards to inherited em font size and calculating relative to that
With that said:
Do still use pt for printing because it's more reliable
If you still want to use ems that's fine. The best strategy, as counter-intuitive as it sounds is to make more specific rules so the em font size doesn't get inherited by everything.
Instead of:
body { font:62.5% arial; }
div#content { font-size:1.2em; }
p { font-size:0.9em; } /* have to calculate to try to get 11 px */
Do:
body { font:62.5% arial; }
div#content p { font-size:1.1em; }
Of course there exist utilities to do the pixel calculation for you ( an entire stylesheet or web page ) in ems but to me that's just a complete waste of time.
If you need to nest list elements (li tags), you can use the following CSS to make them not continue to grow or shrink:
li li {
font-size: 1em;
}
jsfiddle: http://jsfiddle.net/Sy92u/6/
Similar concepts can be applied to other situations, but may not work for your exact use-case.
What should i keep for body, {font-size: 100.01%; } or { font-size: 100%; }?
what is {font-size: 100.01%; }? and is it really good to mention font-size in html{} even
If I'm using body {font-size: 62.5%;}
Edit : 3 May 2010
Today i found info about 100.01% at here - http://www.communitymx.com/content/article.cfm?cid=FAF76&print=true
This odd 100.01% value for the font
size compensates for several browser
bugs. First, setting a default body
font size in percent (instead of em)
eliminates an IE/Win problem with
growing or shrinking fonts out of
proportion if they are later set in
ems in other elements. Additionally,
some versions of Opera will draw a
default font-size of 100% too small
compared to other browsers. Safari, on
the other hand, has a problem with a
font-size of 101%. The current "best"
suggestion is to use the 100.01% value
for this property.
Is it good to keep body { font-size:100.01%} in place of {font-size:100%}
The declaration body (or html) { font-size: 100.01% } compensates rounding errors, in particular in older versions of Opera and Safari. Both would otherwise display fonts that are too small.
A relative font-size (%, em) is always interpreted relative to the font size of the parent element. So it's not a bad idea to implement kind of a initial reset in the top element, which you can achieve with body {font-size: 100%}.
Never seen 100.01% before, but it seems like some sort of browser hack that will force some browsers to ignore or calculate size correct if you use this "fix".
I wouldn't use it myself though, as errors tends to be fixed and there are often more nice ways of dealing with the same option.
html {
font-size: 100.01%;
}
100.01%, not a hack or a kludge, has been around for many years. Google "100.01%" and read up. It is as valid as 100% and does cover some territory 100% doesn't.
An initial font-size should always be declared. Set a base font-size on an outer container -- either <html> or <body> -- for it is from that container which all relative and inherited font-size values will derive. Using 100% or 100.01% makes the starting font-size equal to the user's browser preference.
Setting that base font-size to the user's browser preference gives your visitors maximum readability. Read that again, please, about the USER's preference. Your visitor will have set their browser font-size for their own best legibility and reading comfort. Your design, magnificent and fragile though it may be, is only a second-string player. Content is king, assuming you have some. But if that content is un-readably tiny, you lose. The visitor surfs on. Your design, then, has failed your needs and your expectations. Therefore, the design really wasn't all that great, was it?