I’ve long sized text only in px. Even when it was patently uncool to do so – the days in which smart people cared about the fact that text set in px couldn’t be resized in IE 6-8. I’ve switched over to using ems now. I haven’t moved every single project over yet, but my mind has switched. Why? I finally found some compelling reasons that I now grok.
You’re going to need to change font sizes for different screen sizes
The same size body type that looks good on a phone sized screen does not look good on a widened desktop layout. Look at Trent’s site for a good example of this. Text should be a bit bigger on large screens.
Let’s say you look through your stylesheet and find 50 different font-size
declarations in px. That’s 50 places you need to change that font size through a media query when the screen size changes. That’s 50 suck points.
First of all 50 places is too many for all but the most enormous of websites. But let’s say those 50 places were all in em. Now through media queries you only need to change the font-size on the body and that change will cascade all the way through the document and adjust the sizes accordingly.
body {
font-size: x-large;
}
@media (max-width: 1000px) {
body { font-size: large; }
}
@media (max-width: 500px) {
body { font-size: medium; }
}
It’s arbitrary anyway
Devices do try to normalize the physical size that “1px” is despite their screen density. What a funny thing. A pixel has nothing to do with a real pixel on your screen. It’s actually an angular measurement.
You might feel more comfortable sizing in px because you’ve done it longer, but that doesn’t make it more intuitive. You’re picking a value that looks right on the screen. What does it matter if it’s 1.35 or 17?
Relative Space
Let’s say you are going to use image icons in your design. You want to apply them to headers at will. You want the size of those icons to be commensurate with the size of the header. You can’t reserve space like padding-left: 20px
, because that will always been 20px regardless of the font-size of the header. If you set that padding in ems, you can reserve an amount of space relative to the current font-size
of that header.
Relationships
If you go all-in with ems, you can start setting things like margin
and padding
with ems. That means when you notch that body font-size
down, spacing around your site also notches down. This ties the design of your site to the typography, which is some major ying/yang #synergy action.
Minor Blahs
There are still a few obnoxious things with ems, like the cascading. If you decide that list items should be font-size: 1.1em
and then have nested lists, it will cascade and grow the font size of the child lists. You probably didn’t want that. You can fix it with li li { font-size: 1em; }
but that’s the kind of thing that can grind your gourd. That’s where rem’s can come in, but that can be tricky as well since there is less browser support (IE 9+).
Should be Rems, thats the path Root Ems :)
I mention rems in the article. I love them. You just either need to be all IE 9+ or write fallbacks. (mixin for that)
I often use EMs for my font sizes, but when it comes to margins and padding, I stick to px because it’s almost impossible to align text of different sizes along an edge if there are different font sizes involved. I guess the browser support for REMs is deep enough now that it’s a viable solution.
Use rems with a px fallback to align text of different sizes ;)
Sry, overlooked the second part of your comment (I cannot delete my comment though)
I’m with Andy: font sizes in EMs, layout and positioning in PXs. It’s worked well for me for many years. :)
If you add the padding to the parent element that contains your text it works beautifully, particularly if you’re using border-box as well
I actually prefer
em
torem
, because (as you mentioned above) relative space is much easier when usingem
. Also, by usingem
, you can easily tie line-height and bottom margin to the font-size (as it should be), not to the root. Congrats on the switch! Your life will (probably) be easier now, I know mine is.I’ve also worked all my life with px. I’m going to give it a try.
You could also write some mixins (assuming you’re using a preprocessor) that could do all your conversions for you. Then you can use whatever unit you prefer in your less and have it compile out to the correct ems.
For example: font-size: fsize(17);
And then fsize would convert that 17 to the corresponding em/px value. Personally I still am more comfortable with pixels as every design I get is using specific pixels sizes for the typography and it’s just easier to look it up in the type explorer and paste it in to the CSS.
You could set font-size: 10px on the body, then every 1em is 10px. Then just operate as normal except add the override on child li elements and such. This is how I started using em without changing my way of thinking too much.
this saved my wordpress and my life, along with hours in mobile optimization, thank u css-tricks, my new favorite code website!!
I too am still using pixels to set everything, but am intrigued by the use of ems. Can you give some good examples of them being used in real life? From what I can tell this site and Trent Walton’s which you linked seem to be using px not em. Since 1 em is relative to the current font size, do you still set the font size in pixels? If I set
body { font-size: 16px; }
andh1 { font-size: 2em; }
how big will an em be in my h1? 16px or 32px?Sizing your h1 to 2em with a body fontsize of 16px will give you the equivalent of 32px as far as I know but I believe it would be better to set your body using percents up front and then changing that percentage within media queries to adapt to different screen sizes. Lets say body { font-size: 100%/1.5 } then h1 { font-size: 3em; 163=48 } h2 { font-size: 2.25em; 162.25=36 }.
Then if you go to @media query (min-width: 30em) for example you could do body { font-size: 120% } and all your headings and paragraph styles would follow suit.
Thanks. What exactly do the percentages mean. If I set
body { font-size: 100%; }
what am I setting it to 100% of? To me it looks like the font should be the same height as the whole page body. Obviously this isn’t the case, but how does this work?Not sure if this is going to post under your last question or what because I can’t directly respond to your last comment but setting font-size to 100% on the body will set the text to whatever the browser considers to be 100%. This is, more often than not, 16px. So thats how we get 3em is equivalent to 48px. This is why Chris Coyier was mentioning the relative spacing between things. If you change this one percentage it changes everything else so you only have to change it one place. If you want smaller text for a mobile screen set the body font-size to 75% for example. It will automatically scale down every other text size you have set using em units. Then as you get to a ‘tablet’ screen size you could set the body font-size to 100% and on a ‘desktop’ size you can set it to 120% if you want. It is just way easier to change font sizes this way.
You can use this rem mixin for sizing all your elements, not just font-size: https://github.com/bitmanic/rem
While that mixin is a cool solution, the issue that I have ran into using similar solutions is that your Sass code gets weird to read later. All your rules are made up of mixins and I prefer to leave using mixins for larger more complex CSS rules.
Here is a Sass function I wrote that does the same thing, but allows your CSS writing to be a little more normalized.
https://github.com/Anotheruiguy/stipe/blob/master/stylesheets/stipe/typography/_functions.scss
Using this function you simply need to set a value for the
$font_size
variable. Example would be$font_size: 12
Then in your Sass you could write the following rule
.block {
padding: em(30);
line-height: em(16);
}
Your CSS would then do this
css
.block {
padding: 2.5em;
line-height: 1.33333em;
}
The em function takes two arguments,
$target
and$context
. By default the context uses the$font-size
value, but if you need to over-ride the context because of the compounding nature of em-based sizing, simply pass in the value of the appropriate context.Funny timing I’m writing my first website in rems right now. I’ve been using percentages and ems to size my page elements. And rems with a px fallback for fonts.
My project requires that I support IE7 and up, and to be honest the process so far has been fairly painless. Up to this project I was a long time px user. I wanted to see what kind of challenges I’d run into making the change to a more fluid measurement system but so far it’s been pretty simple.
But the real reason I switched to ems really had little to do with fonts. I was happy with pixels, they were comfortable like an old pair of shoes. Rather I switched because of em based media queries. Here’s a link for reference:
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
After reading that and seeing the benefits of em based media queries, I figured it was time for some new shoes. ;)
Great article, I shall be scoring through my project looking for those pesky px font sizes and blasting them with a liberal dose of ems :)
I’ve just started using em’s for a new production site I’m doing – it’s actually quite fun! My CSS looks something like this:
And so on…I find it does help to maintain consistency with spacing, because even if I change the size of a
h1
for some particular element, the margins will also size down accordingly but still be proportional to the biggerh1
‘s.I’m experimenting with using %’s for all widths though which requires side margins / padding to also be sized using %’s – this will probably cause issues if I were to increase the base font size as the screen got smaller (margin / padding above and below would not be equal) but I guess I will overcome that obstacle when I come to it! For now I’m just liking the flexibility em’s bring!
Becky, I’m sure you’ll find a solution to your problem but I wonder if it’ll be a problem at all. wouldn’t you want your top and bottom margins and paddings to be relative to your font size anyways? I think it would allow for better vertical rhythm if your top and bottom spacing was related to font size as opposed to the screen width.
Hey Becky, you can always use media queries to adjust when you get to smaller font sizes. Even if sizes stay relational as expected, you’ll find that depending on your screen-size/viewport sometimes things need further tweaking anyway.
I use a SCSS function to help with this:
That allows me to use it with the default context of 16pt, but also supply the context for when it would inherit something other than 16px:
I am with Doug, this is a valid and clean way to do it. Instead of relying on the compatibility of
rem
on various browsers, it is nice to delegate the responsibility to our code.Are we developing sites for users or developing sites for screen sizes?
Unfortunately EM approaches and responsive style web development assumes the user wants their screen ‘filled’.
However, while viewing a site like trentwalton.com I end up ‘zooming out’ so that I can see more of the page in the browser window – not just have the window’s extra space filled in with content or on trents site the extra space is filled with bigger font – which is not why I opened the page larger – I opened it larger to see more of the content…
As web developers we need to think of how we affect users that prefer a certain viewing style, without forcing them to interact with a design / layout that expands and grows in size due to EM type development.
As mentioned – for me to get the preferred viewing style (due to trentwalton.com using EM fonts and responsive design) was to zoom out to 50% so I can have my browser be opened fully without being forced to see font large enough for a blind person to read.
If as web developers we are only concerned with shoving as much content into the viewing screen we will continue to ignore the idea of delivering a pleasant site to our viewers with logical organization.
I’m not sure that is the point being made here. Trent’s website is certainly a testing ground for what is possible and not necessarily what is best for everyone. Quite frankly I like it because I can actually sit back and read. The point of using ems isn’t to bother users but to allow for a more flexible solution to a large problem.
What many people don’t know is that you can use ems for widths, margins and positions, for example: You have a fixed nav, which has a font size and a padding, but no set height.
You want to add padding to the body that is equal to the height of the nav.
You can set the padding of the body in ems so that it changes automatically with the font size :D Also awesome for text indentation and floated images.
I use ems on boxes all the time and it’s wonderful :D
Good point william,
I put up a code pen example on how to set breakpoints on ems but the widths in percentages.
If you change the base font size in the pen you can see how it affects the breakpoints.
@Justin Avery, without having done much testing myself here, lets say that you want to adjust the body font size within a media query. If the query itself is using ems (a good practice) will changing the font size on the body effect when your breakpoints occur or will the media queries still rely on the base body font size outside of any media queries. Or for that matter does changing the font size effect media queries at all?
actually just answered my own question by forking Justin’s pen and trying a few things out there. I set the body font-size to 3em for the 75em breakpoint and it did not affect the media query firing. The media query set in ems seems to relate to the browser standard maybe?
@christopherisaak
It doesn’t seem to affect the break point, I suppose if it did you could find yourself in an infinite loop of your page expanding and contracting.
Something that I did to show the affect on sizing other elements within that pen was to set the max-width of the container to 64em. That most definitely is affected by the body size.
If you were to increase the
body
font size to 1.1em then themax-width
becomes 64em x 1.1em.I <3 the em. For readers that are curious here is another good article on the em.
http://v1.jontangerine.com/log/2007/09/the-incredible-em-and-elastic-layouts-with-css
I used % and EMs for more than ten years, this year I switched to PX, because of few very important reasons:
– the time of development in PX is much less
– fonts and line-heights looks more identical between browsers
For everyone who just stared with EMs I suggest to look over Yahoo: YUI 2: Grids CSS
I’d agree on the lesser development time, but I had no idea that it using px makes for more identical fonts/line heights crossbrowser. Is this really true?
Yes, it’s really true. Even between versions of webkit, how ems inherit varies.
I like that you used ‘grok’ in a sentence. Needed to wiki that one.
I have used px but this article has me rethinking that. Will look into it in my mockup designs and see if I can get it to work for me. I like that rem seems to be a nice new sizing unit.
Did you know that originally, the CSS em unit was derived from the width of the capital letter M, which is where its name came from?
Pretty interesting fact if you ask me.
I do use pixels despite the obvious issues associated with them. However I disagree with your point of it being a pain to change things across the site when you use pixels. I set the font-size in pixels on the body (usually 16px) and the rest in percentages. It’s super easy to maintain and the browser appears to make the percentage calculation currently.
Pain starts when it’s the other way: body in % and the rest in px.
I’d be wary of advocating the use of
em
‘s in this manner. The maintenance of calculations in nested elements is nightmarish. I’ve found that usingem
‘s can in some regards increase the amount of work when migrating from usingpx
‘s.What I’ve found useful is to use, as mentioned,
rem
‘s withpx
fallbacks.rem
‘s are a free variable, and allpx
fallbacks can be declared by referencing a variable for default font sizee.g.
$default-unit-px
This alone is enough reason to start using Sass for all projects.
em
‘s are useful for font relative measurements such as calculating the padding within a button relative to the block’s font size:There was a time when I thought using
em
values was unnecessarily complicated.I’ve obviously changed my mind since and I’ve been using
em
instead ofpx
for quite a while. First for fonts, then for stuff likewidth
/padding
/margin
/border-radius
because of the flexibility I get in return. Though sometimes for the same flexibility reasons I use %. It ultimately depends on what exactly I want to achieve.For example, if make a button/ logo and I want to make the whole thing bigger/ smaller, then I just have to adjust the
font-size
and it’s all done if its dimensions or paddings are set inem
.But when it comes to stuff like
padding
for something like articles on a blog, then I have to think how exactly I want it to vary with different screen widths and then decide whether I use%
values (which depend on thewidth
of the parent element) orem
values (which depend on thefont-size
of the element itself). And in this situation I’ve actually found myself using%
values for small screens (because I want the padding to decrease fast as the screen width decreases) andem
values for large screens (because I don’t want to end up having huge paddings on large screens)And finally I started using
em
for media queries as well, after I realized my own site looked horrible on zoom. I was usingpx
-based media queries and from something like800px
up, I was making the menu at the bottom move on the right side of the content and I was giving it a fixedwidth
andposition: fixed;
.I pestered so many people to check how it looked on their different mobile phones, but it never occurred to me that I should check how it looks on my own laptop when zooming in. Until I read this article. I felt like Wile E. Coyote upon realizing his perfect plan to catch the Road Runner backfired.
Well, but the question is if you really need huge margins/paddings if your font is huge (eg. zoomed in with page-zoom)? I don’t think so, since it can completely destroy the appearance of a design. If somebody wants to have bigger text they don’t automatically want bigger space. I think to use ems everywhere is very, very dangerous and can ruin your design much more then when using px. But that doesn’t mean you should use the latter. rem is definitely the way to go!
I’ve struggled with switching to ems from PX for a long time, mostly because px is just second nature to me after all these years. Em’s seems so arbitrary, and not consistant…
But since we’re all using pre processors now that support variables (SCSS), I wonder if I might have some success with setting font sizes and some margins with variables and working with variables instead of numbers throughout my style making it easier to tweak and change.
Just an idea!
I should have read everyone’s comments before posting this #blushes
Just a noob question here. If I set my body font-size: 1em, it would be 1em of what? And if I set my margin/padding to em as well, it would be em of what, the body font-size?
It would be 1em at the browser font size (usually 16px). Margin and padding in ems would be based off the last declared value; if you declare margin/padding in ems on the body where you’ve declare a 1em font size, then it would calculate the values off body. If you declare a lower font size in ems on paragraphs in the same document, then declare margin/padding on paragraphs, it’ll calculate the margin/padding based on the paragraph font size.
(If that clears it up at all!)
I’d like to use rem/em, but haven’t taken the plunge yet, knowing there are some issues and complications to deal with…
Looks like there’s a zoom issue in webkit that would effect use of ems in media queries: http://alastairc.ac/2012/01/zooming-bug-in-webkit/
Also, I wonder if webfont rendering suffers with ems, when they would end up at fractional sizes. Does anyone know if the browswer rounds to hinted sizes when using ems? I’ve seen some fugliness with webfonts (even popular paid ones) that end up with no Truetype hinting when the size isn’t in whole increments. Not sure if that’s related.
A small tip with using ems. Setting the font size to 62.5% makes 1 em = 10px. This allows for more rapid on-the-spot calculations.
For example,
10px = 1em.
20px = 2em.
14px = 1.4 em and so on.
Finding out what 28px in ems is a lot easier this way than if your font size was set to 16px or 100%.
… or for a more pixel-perfect layout, set font size to 10px to be safe.
The problem is that not all users like you to overwrite their settings. There’s a very good reason why the basic font-size is ‘normalized’, but possible to override with user stylesheets.
In a responsive environment, I would always encourage you to use %-based font sizes (or em if you want, though %-based seems to scale better in older browsers) and em based media queries. This works best when you actually care about giving your users control over their own styles.
Pixel based media queries are terrible if you ask me, because they’ll ‘break’ when you zoom in for example. Since em’s are relative to the font-size, the media queries respond much better.
Food for thought ;-)
I bet there are some good Codepens which can be forked for demonstrating em inheritance. Does anyone know of one?
Also useful for proportional media queries such as:
@media screen and (max-width:50em) {}
In case you missed it we talked a bit more about proporational media queries further up in the comments.
It’s a difficult topic.
The main reason behind your analyses is that people have their eyes further away from a small device than a big device but the DPI doesn’t change (not talking about HiDPI/retina, same story goes). So the actual visual DPI (so with distance) is actually different. And that’s where EM’s can play a role. But be very aware, that the actual size of a screen is still in pixels. So if you take em for div width adjustments, you are sure your text fits at any device, but on the screen itself, it can look way off comparing to sizing your browser on a desktop. Since users can have their base font size different
I don’t know if “small” as font-size on a mobile compiles as the same px as on a desktop. I think that should be different, cause of the above reasons, but probably isn’t since the complexity for webdevs and eventually users seeing websites all screwed up.
On a mobile, productivity(readability and speed) stand well above a desktop experience. So I think layout should take the hit and text should always be good readable. That way webdevs adjust their things, and not vice versa.
Now that I just wrote this, I wonder if it’s true what i said.
Hasn’t Apple for instance, who created the first standard as in DPI for mobiles, just coped with making sure the visual DPI looks the same as the visual DPI on a desktop?
That would make a lot more sense. And than your article is a bit wrong. Since it’s well analysed to make sure those two fit.
In my experience, I often think fonts on mobile are too small. In “reader” for instance (iOS), I make text a bit bigger.
Or is the general arm length, so the visual DPI about the same globally? And the Visual DPI of desktop way different, since people all have different desks and ways to easy work?
Interesting topic, that I am sure of Apple has spend 3 years into this deciding what the exact DPI should be on an iPhone which created the standard.
I sure hope DPI isn’t going to be like mega pixels on camera’s. Since it must chosen carefully to create good proportions.
Anything vertical I use
em
and anything horizontal I use%
.There are a few times when I use
em
for horizontal things when I don’t want the distance to diminish depending on the screen size.hi !!
I agree with you…
This is what I do in all the templates that I design.. :)
Em’s for margin widths: A quarter column width divided by base font size(rounded to nearest odd number) = Em Margin width
Yes, I love ems for font sizing stuff but I never found my way around for width and height thing.
I switched from px to % a while back.
Maybe I am missing something but are % and em basically interchangeable in terms of their benefits and functionality?
Another words is there a reason you would choose em over % specifically? If so, can you point me to some articles explaining the pros/cons/differences? Thanks!
They’re pretty much the same, but there are some differences.
The main difference is that the
em
unit takes its relative measurement from the base body text size.If you set 16px as the
body
size then:1em = 16px, 20em = 320px, 60em = 960px.
If you set 10px as the
body
size then:1em = 10px, 20em = 200px, 60em = 600px.
The other issue is that the
em
is related to its parent measurement (which is why people have been suggestingrem
‘s as they are always relavent to the root measurement).Strangely though setting the width of an element in
em
‘s has no bearing on any other child width elements that are also set inem
‘s, nor does it have any affect on thefont-size
.If you apply a
font-size: 2em;
to a container then any child elements that are set inem
‘s will be doubled, as well as the container itself if the widths are set inem
‘sActually I’d like to clear up a discussion from earlier in the feed. I’ve used px for years and find it quite successfull however since displays have begun to vary intensely and the dnsity of pixels as well (like the new MacBook Pro for instance) it’s become common sense to switch over to ‘what feels like’ a much more professional method using em or %. When I’ve built dynamic sites in the past I tend to go with % over em purely because I find the results to be more favourable- you don’t have to rely on the parent measurement for one. I found this out when working on a site that was effectively full width and wanted a header that adjusted to fit the sites width, I don’t think it would have been as flexible in em so I went with %. I’ve got a couple of sites I’m working on http://www.reynoldsdigital.com that will be using em in the future so I can report back with more findings!
I am glad to see I am not the only one who stuck with px for font sizes over the years (I did try ems but found them confusing to keep track of). However I am now using ems as I want my sites to be responsive from now on and as far as I am concerned this is the best way to go for my site fonts (also my recent steps into using SASS makes it much easier to keep track of the ems required to achieve the font sizes without having to remember calculations and which parent element I am relating the font size to).
I’ve used rem for a few projects now and I’m pretty comfortable with it. Before I’ve used em on pretty much everything, but the nesting drove me crazy sometimes. However I’m still struggling if I should use em instead of rem on certain elements, so that the spaces adapt accordingly.
But on the other side, if someone bumps up the font-size, that doesn’t automatically mean that they also want huge margins/paddings. Because if set everything in rem and use page-zoom all the elements and spaces get also bigger, but not related to the element itself but to the body (and that’s a big difference). But if you use em for say an H1 and set the margin also in em it gets very big very quick if you zoom in. And therefore rem is the unit to go for: px is to restricting and em too lax, too unpredictable.
I’ve also written an article about this topic: http://www.css3files.com/2012/10/11/relative-is-the-new-absolute-the-rem-unit/
I think the reason many people used px instead of em and still do is because they desire control. They dont want or cant cater for a user setting personal font preferences. It’s very hard to code a design that looks good across many font sizes. The other reason is that px is more reliable (assumption, not 100% sure) in dictating font sizes across different browsers.
What I find interesting is that many em implementations do the exact same things as exact pixels sizing: they establish a baseline, usually 10pixels, and then do the math from there, reverse engineering pixels into ems. We’re chasing the same goal as before: control, and we optimize our designs for those specific em values, which, let’s admit it, we treat as px values.
How many of you actually change the base em values to highly diverse values and then check if your design still works? How do you cater for the fact that 0.8em as a header sub text of a 10px base works great with that 10px base but falls apart when using a base of 9 or 8 pixels? How do you deal with the fact that padding and margins in facts are not always procentually related to the size of a font, and that there are a lot of border cases in a responsive design where that relation simply falls apart?
Don’t get me wrong, I’m all for em over px (personally using rem), but I do think there are still serious issues with it that are too little discussed. I also think that not everybody is on board with the true goal: designs that work across font sizes. That should be the point of em, instead of realizing pixel perfection through a different method. Right now, I see a lot of people resizing their browsers all day to make it responsive. I don’t see people changing font sizes that much.
This is no complaint to anyone or anything, I’m just ranting out loud.
Some really good points to think about, thanks.
Ems for everything, except borders.
Why would you ever want your layout to not be proportional?? This is the main problem I have with rems, they don’t scale proportionally. The other major turn-off is the doubling of css required to provide backward compatibility. Yeugh.
If you are having issues with cascading then you have almost certainly overcomplicated either your markup or your css.
Ems are all good, but use them wisely while creating layouts.
Suppose you want to switch to a font that has a different x-height. If it’s font with a lesser x-height, you should naturally want to increase the font size. But since you use ems for widths, margins, paddings etc. increasing the font size will make the layout zoom in and your new font will look smaller proportionally.
In essence, if you use for ems everything, know that you won’t have an easy way to switch to a font with a different x-height later on. I prefer percentages over ems for any design / template where the user is given the ability to change fonts for the same reason. ‘px’ doesn’t have this issue either but it’s not ideal.
Watching this thread is interesting. Ems over px is clearly the way to go when engineering a UI, but I also agree that how ems work is a real pain in the arse. So we need to look at better tools.
Sass gives us these tools. Check out this codepen I put together. It’s a quick ‘how-to’ on solving this problem.
http://codepen.io/blackfalcon/full/wlzhv
I was mainly referring to the people who can’t utilize CSS pre-processors yet. And they may not think about this issue at an early stage, either. Yes it can be fixed by a CSS pre-precessor [1] (not a very elegant solution) but not everyone has access to CSS pre-processors either.
If you’re designing an interface that’s inherently and totally (widths, margins, paddings) tied to the typographical proportions (hence, ’em’), you better decide not on switching to very different font families. It’s one of the foundations of em-based layouts, they’re tied to font-sizes.
Any changes in your font size will create a zoom in/out effect. For example, in an em-based layout, if you wanted to replace PT Sans (13px equivalent), for example with Open Sans (higher x-height, so 12px is needed now), how would you do it without zooming in the whole layout? SCSS example at end.
P.S. I am not saying em-based layouts should be not used. Rather, I am pointing out something that should be kept in mind for creating templates where people would wish to customize it by changing fonts. You could use a smart CSS pre-processor function to keep the layout fixed by a ratio or just use px or % without many drawbacks.
[1] http://codepen.io/joe/full/Jqzru (modified version of the original posted by Dale).
this mini-rant was the result of having to tangle with UI on a recent project.
I’d agree with the poster who said working with ems ( or anything relative ) is a pain. It’s another area where CSS is such an awful implementation. Overly complex, working out specificity weighting for every friggin’ thing, many constructs are just bizarre and intuitive as Aramaic written by a drunken clown.
I started on the front-end and I am so glad I moved to the application side of things. All these years later, CSS is still a train wreck.
Don’t blame your tools.
@Chris Coyier
Here at css-tricks.com you are using px for most sizes.
Have you changed your opinion again or haven’t you changed the code yet?
Which is you current recommendation: em for everything (margin, width, font-size, media queries)?
That seems to be the approach ZURB Foundation 5 uses (with rem instead), but Bootstrap 3 e.g. uses px for nearly everything.
Great article. I can’t remember when I stopped using px for most things but it has been a while. Having said that I understand why most people still make use of them and are not quick to change on existing projects in particular. I would imagine that with the size of this site it would be a monumental undertaking to change them all over to em or rem. Remember though that we are designing for the end user and not for other designers. I doubt that a user is going to say hey this isn’t in px so it’s crap. They won’t know the difference. They may or may not complain that the text is too small on a large screen which is a different issue. For that you just need to take it case by case. Focus on things that matter to the user and you can’t go wrong!
Thanks for the great article. I am facing a problem in which when I zoom-out my site, site looks different (font-size and margins and padding) because I use em and px both. But I don`t know the exact way to use them properly.
I want that even on x-large screen, site looks exactly same as I see in my 15in laptop. What should be my action plan for that.