Pixels vs EM & Vertical Rhythm #1943

Closed
ifesdjeen opened this Issue Feb 13, 2012 · 71 comments

Comments

Projects
None yet
@ifesdjeen

Hi,

Would you be interested in getting rid of Pixel measurements and taking a more flexible approach, using EM?

For things like, for example Legend size, paddings for headings, alert blocks, buttons nav tabs. These things are more likely to be relative than absolute.

Also, sizes of input controls, sizes or labels and many more things. All of them rely heavily on the base font size, and it will such an improvement to have all those things in a relative measurements (em) rather than absolute (px).

@mdo

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Feb 13, 2012

Member

Nope, no em units. They complicate simple values and scales unnecessarily and for little reward. Pixels are fine as browsers just zoom the page without any problem.

Member

mdo commented Feb 13, 2012

Nope, no em units. They complicate simple values and scales unnecessarily and for little reward. Pixels are fine as browsers just zoom the page without any problem.

@mdo mdo closed this Feb 13, 2012

@ifesdjeen

This comment has been minimized.

Show comment
Hide comment
@ifesdjeen

ifesdjeen Feb 13, 2012

@markdotto is it possible to get a response from a technical rather than designer person?

"Complicate simple values" is simply not true. Things like 60px, 40px don't really let you do nice vertical rhythmical composition.

It's not about zoom. It's more about other people using a different base font size, therefore requiring having different margins, paddings and sizes of different elements.

@markdotto is it possible to get a response from a technical rather than designer person?

"Complicate simple values" is simply not true. Things like 60px, 40px don't really let you do nice vertical rhythmical composition.

It's not about zoom. It's more about other people using a different base font size, therefore requiring having different margins, paddings and sizes of different elements.

@chrisnicola

This comment has been minimized.

Show comment
Hide comment
@chrisnicola

chrisnicola Mar 26, 2012

Actually I'm more than happy to accept @markdotto's expertise here. What I'd like is some source to reference so I can understand why every design article on typography and vertical rhythm I've read on this is wrong. I assume it's because something has changed, but I'd like to dig in a bit before either committing to an entirely pixel based typography or spending time overriding all of bootstrap's values with an em based one.

Actually I'm more than happy to accept @markdotto's expertise here. What I'd like is some source to reference so I can understand why every design article on typography and vertical rhythm I've read on this is wrong. I assume it's because something has changed, but I'd like to dig in a bit before either committing to an entirely pixel based typography or spending time overriding all of bootstrap's values with an em based one.

@davideicardi

This comment has been minimized.

Show comment
Hide comment
@davideicardi

davideicardi Jul 18, 2012

As far as I known pixel doesn't works when someone (maybe with vision problems) change the default browser font size.
In my test seems that bootstrap doesn't work in this case. I am right?

thanks

As far as I known pixel doesn't works when someone (maybe with vision problems) change the default browser font size.
In my test seems that bootstrap doesn't work in this case. I am right?

thanks

@DrummerHead

This comment has been minimized.

Show comment
Hide comment
@DrummerHead

DrummerHead Aug 23, 2012

Can we at least have support for em based settings? Right now if I set $baseFontSize to 1em everything explodes. Thanks

Can we at least have support for em based settings? Right now if I set $baseFontSize to 1em everything explodes. Thanks

@opensource21

This comment has been minimized.

Show comment
Hide comment
@opensource21

opensource21 Sep 10, 2012

+1 for an explanation or at least support for em based settings.

+1 for an explanation or at least support for em based settings.

@Undistraction

This comment has been minimized.

Show comment
Hide comment
@Undistraction

Undistraction Oct 23, 2012

+1 I would love to hear a detailed explanation. Browser zoom is not equivalent to resizing text for someone who is vision-impaired.

+1 I would love to hear a detailed explanation. Browser zoom is not equivalent to resizing text for someone who is vision-impaired.

@martent

This comment has been minimized.

Show comment
Hide comment
@martent

martent Oct 24, 2012

davideicardi is correct, sizes set in pixels are not influenced by the base font size set in most browsers. The problem with px is not only an a11y thing, users change the base font size up or down if they have high or low density screens. Zoom is a great thing, but there is a good reason why browsers have a base font size setting.

martent commented Oct 24, 2012

davideicardi is correct, sizes set in pixels are not influenced by the base font size set in most browsers. The problem with px is not only an a11y thing, users change the base font size up or down if they have high or low density screens. Zoom is a great thing, but there is a good reason why browsers have a base font size setting.

@RonaldV

This comment has been minimized.

Show comment
Hide comment
@RonaldV

RonaldV Oct 25, 2012

+1 I also would like to hear a clear explanation or support for an em based setting (at least for headers and possibly padding ).
Other than that you guys are doing a great job! That needs to be said too, so keep up the good work.

RonaldV commented Oct 25, 2012

+1 I also would like to hear a clear explanation or support for an em based setting (at least for headers and possibly padding ).
Other than that you guys are doing a great job! That needs to be said too, so keep up the good work.

@Charuru

This comment has been minimized.

Show comment
Hide comment
@Charuru

Charuru Oct 26, 2012

If anything em removes complexity.

Having px line-heights instead of relative ones are also another weird thing in boostrap.

Charuru commented Oct 26, 2012

If anything em removes complexity.

Having px line-heights instead of relative ones are also another weird thing in boostrap.

@martent

This comment has been minimized.

Show comment
Hide comment
@martent

martent Oct 27, 2012

@markdotto Setting sizes in pixels is not responsive at all. Not responsive to the device and it's settings and not to user preferences. After all, responsive web design is not just about letting boxes move around and change size depending on the width and orientation of the device.

martent commented Oct 27, 2012

@markdotto Setting sizes in pixels is not responsive at all. Not responsive to the device and it's settings and not to user preferences. After all, responsive web design is not just about letting boxes move around and change size depending on the width and orientation of the device.

@luishdez

This comment has been minimized.

Show comment
Hide comment
@luishdez

luishdez Nov 2, 2012

Contributor

I totally agree with @martent. sizes based on px are not responsive. The only but that I see, is that mostly of the people doesn't know how to work with em sizes properly and that's the main reason from others to reject it.

Contributor

luishdez commented Nov 2, 2012

I totally agree with @martent. sizes based on px are not responsive. The only but that I see, is that mostly of the people doesn't know how to work with em sizes properly and that's the main reason from others to reject it.

@Undistraction

This comment has been minimized.

Show comment
Hide comment
@Undistraction

Undistraction Nov 2, 2012

@markdotto Would be nice to know if this is on the roadmap? Or even being discussed?

@markdotto Would be nice to know if this is on the roadmap? Or even being discussed?

@alex-ross

This comment has been minimized.

Show comment
Hide comment
@alex-ross

alex-ross Nov 4, 2012

I agree with all of you who want em instead of px. I can accept px in some places like borders where you may just want something thin. But an em almost works like an variable. If i want my site more readable i can just set my font-size in body and everything works with it (i.e size of buttons and line heights will change to). I cud use % instead but thats more complex imo.

I agree with all of you who want em instead of px. I can accept px in some places like borders where you may just want something thin. But an em almost works like an variable. If i want my site more readable i can just set my font-size in body and everything works with it (i.e size of buttons and line heights will change to). I cud use % instead but thats more complex imo.

@livingincircuits

This comment has been minimized.

Show comment
Hide comment
@livingincircuits

livingincircuits Nov 7, 2012

+1 for more information regarding this.

+1 for more information regarding this.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Nov 15, 2012

+1 for explanation on preference for px vs ems or even rems
I get the point that not alot of people do change their browser base font size.
However, what is the benefit of using px?

ghost commented Nov 15, 2012

+1 for explanation on preference for px vs ems or even rems
I get the point that not alot of people do change their browser base font size.
However, what is the benefit of using px?

@austinbirch

This comment has been minimized.

Show comment
Hide comment
@austinbirch

austinbirch Nov 16, 2012

I'd love to be able to use ems rather than pixels too. An advantage of using ems is that you can adjust the base font size within a media query.

If, for example, you use large type on larger displays (to achieve a comfortable measure), you may find that on smaller displays your measure is far too short. Shrinking the base font size within a media query will cause type and line-height (and anything else you have set with ems) to reduce in the correct proportions for all elements.

Edit: I think this is pretty much what @izepax is saying, but through using media queries.

I'd love to be able to use ems rather than pixels too. An advantage of using ems is that you can adjust the base font size within a media query.

If, for example, you use large type on larger displays (to achieve a comfortable measure), you may find that on smaller displays your measure is far too short. Shrinking the base font size within a media query will cause type and line-height (and anything else you have set with ems) to reduce in the correct proportions for all elements.

Edit: I think this is pretty much what @izepax is saying, but through using media queries.

@danielmahon

This comment has been minimized.

Show comment
Hide comment
@danielmahon

danielmahon Nov 20, 2012

not a complete answer but found this #373

not a complete answer but found this #373

@Charuru

This comment has been minimized.

Show comment
Hide comment
@Charuru

Charuru Nov 20, 2012

That's the same answer as here. But a lot of people clearly disagree. Using em is really important for manageable themes, I'm really surprised that there are some people who have taken the side of px.

Charuru commented Nov 20, 2012

That's the same answer as here. But a lot of people clearly disagree. Using em is really important for manageable themes, I'm really surprised that there are some people who have taken the side of px.

@mdo

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Nov 20, 2012

Member

Okay, so here's a bit of a background on the decisions of yesteryear and plans for moving forward.

  • Pixels provide absolute control and consistent rendering across every browser.
  • Designers still mostly think and operate in pixels.
  • Browsers scale up entire pages these days, so it's not an issue with type scaling or anything.
  • Nesting ems historically has been a pain and can require extra math for figure computed/intended pixel values.
  • Mixing units of measurements is ugly and my inner OCD hates it.
  • Using units on line-height is generally discouraged, but provides immediate knowledge of what the computed value is. We'll probably try to steer away from this in the future.
  • In the future, we'll likely use ems for type sizing, perhaps rems even, but not for anything else. This is also debatable on font sizes for inputs and the like. It's just not how folks build pixel perfect sites.

That's a bit all over and hopefully coherent enough. I'll try to blog about these changes as they come up more, but I'm unsure how close 3.0 is and what that will all entail yet.

<3

Member

mdo commented Nov 20, 2012

Okay, so here's a bit of a background on the decisions of yesteryear and plans for moving forward.

  • Pixels provide absolute control and consistent rendering across every browser.
  • Designers still mostly think and operate in pixels.
  • Browsers scale up entire pages these days, so it's not an issue with type scaling or anything.
  • Nesting ems historically has been a pain and can require extra math for figure computed/intended pixel values.
  • Mixing units of measurements is ugly and my inner OCD hates it.
  • Using units on line-height is generally discouraged, but provides immediate knowledge of what the computed value is. We'll probably try to steer away from this in the future.
  • In the future, we'll likely use ems for type sizing, perhaps rems even, but not for anything else. This is also debatable on font sizes for inputs and the like. It's just not how folks build pixel perfect sites.

That's a bit all over and hopefully coherent enough. I'll try to blog about these changes as they come up more, but I'm unsure how close 3.0 is and what that will all entail yet.

<3

@gavrochelegnou

This comment has been minimized.

Show comment
Hide comment
@gavrochelegnou

gavrochelegnou Dec 18, 2012

I think this was not raised here, but using em instead of pixels is also important for web accessibility.
Using "px" results in a failure of test C14 from the W3C/WCAG http://www.w3.org/TR/WCAG-TECHS/C14.html

Quite a shame for all website under section 508 (and other accessibility laws around the world)

I think this was not raised here, but using em instead of pixels is also important for web accessibility.
Using "px" results in a failure of test C14 from the W3C/WCAG http://www.w3.org/TR/WCAG-TECHS/C14.html

Quite a shame for all website under section 508 (and other accessibility laws around the world)

@luishdez

This comment has been minimized.

Show comment
Hide comment
Contributor

luishdez commented Jan 11, 2013

@rossedman

This comment has been minimized.

Show comment
Hide comment
@rossedman

rossedman Jan 11, 2013

I actually had a discussion about this today with some other developers and behold this conversation is happening. I have read the reasons why ems are not being used in bootstrap. However as someone who was a designer first and a developer second I can tell you I don't think in pixels and it's kind of belittling to here that designers still think in pixels. I know many designers who think much more deeply about their designs. I think of mine in ratios and in vertical rhythm more than pixels.

I hope you guys will reconsider but I have already cut this out of production based on this reason alone. Everything else is great about this framework.

I actually had a discussion about this today with some other developers and behold this conversation is happening. I have read the reasons why ems are not being used in bootstrap. However as someone who was a designer first and a developer second I can tell you I don't think in pixels and it's kind of belittling to here that designers still think in pixels. I know many designers who think much more deeply about their designs. I think of mine in ratios and in vertical rhythm more than pixels.

I hope you guys will reconsider but I have already cut this out of production based on this reason alone. Everything else is great about this framework.

@mdo

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Jan 11, 2013

Member

It's kind of belittling to here that designers still think in pixels.

I know many designers who think much more deeply about their designs.

I'm just going to call these two statements out and call it a day. There are no ill intentions in the statements I made and if you reread what I wrote, you'll see I'm explaining the thinking to date and not any decision that's been made for 3.0. We'll do whatever makes the most sense for the constraints that we can define and take it from there.

Member

mdo commented Jan 11, 2013

It's kind of belittling to here that designers still think in pixels.

I know many designers who think much more deeply about their designs.

I'm just going to call these two statements out and call it a day. There are no ill intentions in the statements I made and if you reread what I wrote, you'll see I'm explaining the thinking to date and not any decision that's been made for 3.0. We'll do whatever makes the most sense for the constraints that we can define and take it from there.

@kogcyc

This comment has been minimized.

Show comment
Hide comment
@kogcyc

kogcyc Jan 15, 2013

+1 for making em an option

kogcyc commented Jan 15, 2013

+1 for making em an option

@rossedman

This comment has been minimized.

Show comment
Hide comment
@rossedman

rossedman Jan 15, 2013

Hey I wasn't trying to start anything. There was no malice in this. I was just responding to your statement. Sorry for any problems you had with this. You don't owe me a reason for you thinking. It is your development. I thought this was a conversation and it seems many other people would like to hear you reconsider. I honestly don't care either way. I will continue to use what works for me and am thankful that someone even wanted to develop something like this.

Hey I wasn't trying to start anything. There was no malice in this. I was just responding to your statement. Sorry for any problems you had with this. You don't owe me a reason for you thinking. It is your development. I thought this was a conversation and it seems many other people would like to hear you reconsider. I honestly don't care either way. I will continue to use what works for me and am thankful that someone even wanted to develop something like this.

@simonwiles

This comment has been minimized.

Show comment
Hide comment
@simonwiles

simonwiles Jan 22, 2013

wow - this is a surprising discussion. hoping you'll consider em-based units for v3!

wow - this is a surprising discussion. hoping you'll consider em-based units for v3!

@stationkeeping

This comment has been minimized.

Show comment
Hide comment
@stationkeeping

stationkeeping Jan 23, 2013

For anyone looking for em-based, truly responsive layouts, we switched to Suzy a while ago and haven't looked back. It makes it easy to visualize in pixels, but execute in ems. Also Thoughtbot have been busy on Bourbon which has a Layout library and a new UI library. It's still early days, but is looking great. If you know Thoughtbot, you'll know this is worth keeping an eye on.

For anyone looking for em-based, truly responsive layouts, we switched to Suzy a while ago and haven't looked back. It makes it easy to visualize in pixels, but execute in ems. Also Thoughtbot have been busy on Bourbon which has a Layout library and a new UI library. It's still early days, but is looking great. If you know Thoughtbot, you'll know this is worth keeping an eye on.

@gavrochelegnou

This comment has been minimized.

Show comment
Hide comment
@gavrochelegnou

gavrochelegnou Jan 23, 2013

To comply with accessibility standards we switched to Yaml

To comply with accessibility standards we switched to Yaml

@aleemb

This comment has been minimized.

Show comment
Hide comment
@aleemb

aleemb Jan 28, 2013

Have you considered reevaluating this issue for the next major release?

Some pretty good arguments for it are made here:
http://trentwalton.com/2013/01/07/flexible-foundations/

The compounding problem is trivially remedied (1em or 100% sizing for base elements).

aleemb commented Jan 28, 2013

Have you considered reevaluating this issue for the next major release?

Some pretty good arguments for it are made here:
http://trentwalton.com/2013/01/07/flexible-foundations/

The compounding problem is trivially remedied (1em or 100% sizing for base elements).

@marinintim

This comment has been minimized.

Show comment
Hide comment
@marinintim

marinintim Jan 28, 2013

+1 for em support, 'cause px is not responsive. I truly hope for ems in v3.

+1 for em support, 'cause px is not responsive. I truly hope for ems in v3.

@Undistraction

This comment has been minimized.

Show comment
Hide comment
@Undistraction

Undistraction Feb 8, 2013

So there are no plans to support ems in V3?

So there are no plans to support ems in V3?

@vandigroup

This comment has been minimized.

Show comment
Hide comment
@vandigroup

vandigroup Feb 15, 2013

The reasoning as I see it is quite simple..EM based layouts are much more complicated for not just the framework dev team but also for developers who are contemplating adoption. I have tried more of the frameworks than I care to admit and ended up on Foundation for a while until I moved to Bootstrap. The reason i switched over to Bootstrap in the first place was that i liked the thought of a framework with amazing talent behind it as well an an exploding community. Having been using it for the past 6 months I have to say that I am now at a point to either port the framework over to an EM/REM based framework, switch back to Foundation (except I love the simplicity of LESS) or finish a framework that I was building myself.

Someone above stated that a fixed pixel based layout is not truly responsive and this is absolutely correct. The thought of using media queries to change PX sizes does nothing but bloat the code and really detract from the true nature of fluid measurements that adapt to screen size. Not that that you still don't use media queries, just not to micro manage fixed pixel sized elements. Furthermore, we only have a few break points to deal with right now but at the pace that tablets and non-desktop devices are gaining traction, it won't long before this won't be the case, at which point it will no longer be truly adaptive to ALL screen sizes.

In the end, I think that the Boostrap devs decision for a PX based layout was smart because many more entry to mid level developers could start using it easily and gaining experience with responsive layouts. For the rest of us, who care about things like accessibility, true vertical rythm and have no need for everything to be SO canned, the reality is that it is more effort to use than not. Trust me, I wish this wasn't true as I have just spent 6 month getting intricately familiar with a framework only to bail it, but that's how it goes in this biz...won't be the first time and surely won't be the last.

I would love to know if there is a REAL desire out there for an EM port of bootstrap...I would do it if I knew there was a decent interest.

The reasoning as I see it is quite simple..EM based layouts are much more complicated for not just the framework dev team but also for developers who are contemplating adoption. I have tried more of the frameworks than I care to admit and ended up on Foundation for a while until I moved to Bootstrap. The reason i switched over to Bootstrap in the first place was that i liked the thought of a framework with amazing talent behind it as well an an exploding community. Having been using it for the past 6 months I have to say that I am now at a point to either port the framework over to an EM/REM based framework, switch back to Foundation (except I love the simplicity of LESS) or finish a framework that I was building myself.

Someone above stated that a fixed pixel based layout is not truly responsive and this is absolutely correct. The thought of using media queries to change PX sizes does nothing but bloat the code and really detract from the true nature of fluid measurements that adapt to screen size. Not that that you still don't use media queries, just not to micro manage fixed pixel sized elements. Furthermore, we only have a few break points to deal with right now but at the pace that tablets and non-desktop devices are gaining traction, it won't long before this won't be the case, at which point it will no longer be truly adaptive to ALL screen sizes.

In the end, I think that the Boostrap devs decision for a PX based layout was smart because many more entry to mid level developers could start using it easily and gaining experience with responsive layouts. For the rest of us, who care about things like accessibility, true vertical rythm and have no need for everything to be SO canned, the reality is that it is more effort to use than not. Trust me, I wish this wasn't true as I have just spent 6 month getting intricately familiar with a framework only to bail it, but that's how it goes in this biz...won't be the first time and surely won't be the last.

I would love to know if there is a REAL desire out there for an EM port of bootstrap...I would do it if I knew there was a decent interest.

@newtriks

This comment has been minimized.

Show comment
Hide comment
@newtriks

newtriks Feb 27, 2013

+1 for em support

+1 for em support

@jfroom

This comment has been minimized.

Show comment
Hide comment
@jfroom

jfroom Mar 4, 2013

Contributor

+1 for em support

Contributor

jfroom commented Mar 4, 2013

+1 for em support

@jfroom

This comment has been minimized.

Show comment
Hide comment
@jfroom

jfroom Mar 4, 2013

Contributor

This issue has rattled me a bit as well - which is a bummer because I heart bootstrap's intent. Came across another write up about benefits of EMs:
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

Contributor

jfroom commented Mar 4, 2013

This issue has rattled me a bit as well - which is a bummer because I heart bootstrap's intent. Came across another write up about benefits of EMs:
http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

@binarylogic

This comment has been minimized.

Show comment
Hide comment
@binarylogic

binarylogic Mar 6, 2013

Couldn't agree me. Foundation uses a emCalc function to make it easy. Even line heights are px based, wtf...

Couldn't agree me. Foundation uses a emCalc function to make it easy. Even line heights are px based, wtf...

@jfroom

This comment has been minimized.

Show comment
Hide comment
@jfroom

jfroom Mar 6, 2013

Contributor

Found the Bootstrap 3 road map here: #6342

In the Type section is this comment: Explore use of rem instead of px as typographic unit... So that is a good sign. (I only recently discovered the utility of rem over an em - it does sound preferable in most cases.)

Foundation4 http://foundation.zurb.com/ is mostly em based (from what I've seen so far), has super organized sass libraries, and is mobile first. Looking forward to Bootstrap 3 because the community is so much larger - but until that stabilizes, I switched over to Susy and then to Foundation few days ago for my current project du jour.

Contributor

jfroom commented Mar 6, 2013

Found the Bootstrap 3 road map here: #6342

In the Type section is this comment: Explore use of rem instead of px as typographic unit... So that is a good sign. (I only recently discovered the utility of rem over an em - it does sound preferable in most cases.)

Foundation4 http://foundation.zurb.com/ is mostly em based (from what I've seen so far), has super organized sass libraries, and is mobile first. Looking forward to Bootstrap 3 because the community is so much larger - but until that stabilizes, I switched over to Susy and then to Foundation few days ago for my current project du jour.

@nathanpitman

This comment has been minimized.

Show comment
Hide comment
@nathanpitman

nathanpitman Mar 12, 2013

+1 for ems in place of pixels. It might be a lot of work to make it happen but I think the long term benefits are far greater. :)

+1 for ems in place of pixels. It might be a lot of work to make it happen but I think the long term benefits are far greater. :)

@cdeutsch

This comment has been minimized.

Show comment
Hide comment
@cdeutsch

cdeutsch Mar 28, 2013

+1 for ems. It's about the only thing on my wish list for Bootstrap. Love it otherwise.

+1 for ems. It's about the only thing on my wish list for Bootstrap. Love it otherwise.

@lenkite

This comment has been minimized.

Show comment
Hide comment
@lenkite

lenkite Apr 10, 2013

+1 for root ems

lenkite commented Apr 10, 2013

+1 for root ems

@evgenyneu

This comment has been minimized.

Show comment
Hide comment
@evgenyneu

evgenyneu Apr 11, 2013

+1 for EMs

+1 for EMs

@jahvi

This comment has been minimized.

Show comment
Hide comment
@jahvi

jahvi May 2, 2013

+1 for rems/ems, at least for type and line height that'd be a great starting point

jahvi commented May 2, 2013

+1 for rems/ems, at least for type and line height that'd be a great starting point

@luis-ca

This comment has been minimized.

Show comment
Hide comment
@luis-ca

luis-ca May 5, 2013

+1 for EMs

luis-ca commented May 5, 2013

+1 for EMs

@jahvi

This comment has been minimized.

Show comment
Hide comment
@jahvi

jahvi May 10, 2013

Sounds like it's not happening for 3.0 😢

We explored the use of rem units over pixels, but found little benefit to offset the implications of their use. IE8 would still need a pixel fallback, and that's a lot of duplicate lines of code. Moreover, using rems everywhere instead of pixels would exacerbate that problem. Mixing rems and pixels doesn't seem to make sense either right now. However, we can and will continue to evaluate this in future releases.

jahvi commented May 10, 2013

Sounds like it's not happening for 3.0 😢

We explored the use of rem units over pixels, but found little benefit to offset the implications of their use. IE8 would still need a pixel fallback, and that's a lot of duplicate lines of code. Moreover, using rems everywhere instead of pixels would exacerbate that problem. Mixing rems and pixels doesn't seem to make sense either right now. However, we can and will continue to evaluate this in future releases.

@vandigroup

This comment has been minimized.

Show comment
Hide comment
@vandigroup

vandigroup May 10, 2013

Due to the lack of support in older versions of IE, I only use rem units only in defining my initial typography styles from my base settings. From there I use regular em units which offer relative sizing to the parents of a selector. I find that this cuts down on the code needed in media queries as an adjustment to the parent relationally adjusts its siblings.

When I do use rem units, I simply add the pixel sizing preceding it to ensure proper fallback support. The additional code is very minimal to ensure this support. For example:

h1 {font-size: 30px; font: 2rem/1.2 sans-serif;}

While you could argue this is a bit redundant and not needed (you could just use pixel sizing), I do it because to me it is best practice with added fallback support, which will be dropped when the time comes.

In regards to an em port, I have been working on it but am only going to release it for v3 as the many of the changes are rather dramatic and for the most part, very positive (except for things such as changing the name to the .clearfix class that I haven't been able to figure out the reasoning for) so it doesn't make sense to maintain support for code soon to be deprecated.

Due to the lack of support in older versions of IE, I only use rem units only in defining my initial typography styles from my base settings. From there I use regular em units which offer relative sizing to the parents of a selector. I find that this cuts down on the code needed in media queries as an adjustment to the parent relationally adjusts its siblings.

When I do use rem units, I simply add the pixel sizing preceding it to ensure proper fallback support. The additional code is very minimal to ensure this support. For example:

h1 {font-size: 30px; font: 2rem/1.2 sans-serif;}

While you could argue this is a bit redundant and not needed (you could just use pixel sizing), I do it because to me it is best practice with added fallback support, which will be dropped when the time comes.

In regards to an em port, I have been working on it but am only going to release it for v3 as the many of the changes are rather dramatic and for the most part, very positive (except for things such as changing the name to the .clearfix class that I haven't been able to figure out the reasoning for) so it doesn't make sense to maintain support for code soon to be deprecated.

@Piedone

This comment has been minimized.

Show comment
Hide comment
@Piedone

Piedone May 10, 2013

@vandigroup May I ask if the em port you mentioned is or will be public, and if yes, where?

Piedone commented May 10, 2013

@vandigroup May I ask if the em port you mentioned is or will be public, and if yes, where?

@vandigroup

This comment has been minimized.

Show comment
Hide comment
@vandigroup

vandigroup May 10, 2013

I will create a repo for it here (on GH) soon and will be free for
anyone to use. I will post a link here when it's up...

Piedone mailto:notifications@github.com
May 10, 2013 12:14 PM

@vandigroup https://github.com/vandigroup May I ask if the em port
you mentioned is or will be public, and if yes, where?


Reply to this email directly or view it on GitHub
#1943 (comment).

Joe Conlin [download vCard
http://www.vandigroup.com/vCards/joeconlin.vcf]

Phone: (760) 705-4331
Email: joe@vandigroup.com
Skype: joe.conlin
Web: www.vandigroup.com http://www.vandigroup.com
Connect: LinkedIn http://linkedin.com/joeconlin | Twitter
http://twitter.com/joevandigroup | Google+
https://plus.google.com/u/0/100025626000241608217 | flikr
http://www.flickr.com/x/t/0097002/photos/vandigroup/

"Vandigroup is a full-service, digital agency, specializing in
technology and results driven solutions. Contact us today to see how we
can help you."

I will create a repo for it here (on GH) soon and will be free for
anyone to use. I will post a link here when it's up...

Piedone mailto:notifications@github.com
May 10, 2013 12:14 PM

@vandigroup https://github.com/vandigroup May I ask if the em port
you mentioned is or will be public, and if yes, where?


Reply to this email directly or view it on GitHub
#1943 (comment).

Joe Conlin [download vCard
http://www.vandigroup.com/vCards/joeconlin.vcf]

Phone: (760) 705-4331
Email: joe@vandigroup.com
Skype: joe.conlin
Web: www.vandigroup.com http://www.vandigroup.com
Connect: LinkedIn http://linkedin.com/joeconlin | Twitter
http://twitter.com/joevandigroup | Google+
https://plus.google.com/u/0/100025626000241608217 | flikr
http://www.flickr.com/x/t/0097002/photos/vandigroup/

"Vandigroup is a full-service, digital agency, specializing in
technology and results driven solutions. Contact us today to see how we
can help you."

@Piedone

This comment has been minimized.

Show comment
Hide comment
@Piedone

Piedone May 10, 2013

@vandigroup Great, thank you!

Piedone commented May 10, 2013

@vandigroup Great, thank you!

@jahvi

This comment has been minimized.

Show comment
Hide comment
@jahvi

jahvi May 11, 2013

Inuit.css uses a very nice mixin to handle type sizing in rems https://github.com/csswizardry/inuit.css/blob/master/generic/_mixins.scss#L13-L19

Fallback support could be suppressed fairly easy if needed later on.

jahvi commented May 11, 2013

Inuit.css uses a very nice mixin to handle type sizing in rems https://github.com/csswizardry/inuit.css/blob/master/generic/_mixins.scss#L13-L19

Fallback support could be suppressed fairly easy if needed later on.

@drgrumpy

This comment has been minimized.

Show comment
Hide comment
@drgrumpy

drgrumpy Jun 13, 2013

+1 for ems

+1 for ems

@gerardo-rodriguez

This comment has been minimized.

Show comment
Hide comment
@gerardo-rodriguez

gerardo-rodriguez Jun 19, 2013

+1 for ems. If you are looking for a semantic, em-based grid system, the Bourbon Neat Grid is a great option. Foundation 4 is much better than previous iterations and can work if you need a "full" package.

+1 for ems. If you are looking for a semantic, em-based grid system, the Bourbon Neat Grid is a great option. Foundation 4 is much better than previous iterations and can work if you need a "full" package.

@cvrebert

This comment has been minimized.

Show comment
Hide comment
@cvrebert

cvrebert Jun 20, 2013

Member

Quoting @mdo in Issue № 6342 (regarding v3, which is still under development), emphasis mine:

We explored the use of rem units over pixels, but found little benefit to offset the implications of their use. IE8 would still need a pixel fallback, and that's a lot of duplicate lines of code. Moreover, using rems everywhere instead of pixels would exacerbate that problem. Mixing rems and pixels doesn't seem to make sense either right now. However, we can and will continue to evaluate this in future releases.

Member

cvrebert commented Jun 20, 2013

Quoting @mdo in Issue № 6342 (regarding v3, which is still under development), emphasis mine:

We explored the use of rem units over pixels, but found little benefit to offset the implications of their use. IE8 would still need a pixel fallback, and that's a lot of duplicate lines of code. Moreover, using rems everywhere instead of pixels would exacerbate that problem. Mixing rems and pixels doesn't seem to make sense either right now. However, we can and will continue to evaluate this in future releases.

@ksclarke

This comment has been minimized.

Show comment
Hide comment
@ksclarke

ksclarke Jun 28, 2013

+1 for ems

+1 for ems

@tristanchambers

This comment has been minimized.

Show comment
Hide comment

+1 for ems

@jahvi

This comment has been minimized.

Show comment
Hide comment
@jahvi

jahvi Jul 9, 2013

Based on @mdo's response this meme express my feelings accurately towards this issue

Stop

jahvi commented Jul 9, 2013

Based on @mdo's response this meme express my feelings accurately towards this issue

Stop

@ipiz

This comment has been minimized.

Show comment
Hide comment
@ipiz

ipiz Jul 19, 2013

+1 for em

ipiz commented Jul 19, 2013

+1 for em

@gmx

This comment has been minimized.

Show comment
Hide comment
@gmx

gmx Jul 29, 2013

+1 for ems

gmx commented Jul 29, 2013

+1 for ems

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jul 31, 2013

+1 for rems/ems

ghost commented Jul 31, 2013

+1 for rems/ems

@lanthaler

This comment has been minimized.

Show comment
Hide comment
@lanthaler

lanthaler Aug 2, 2013

+1 for rems

+1 for rems

@declandewet declandewet referenced this issue in static-dev/axis Oct 18, 2013

Merged

Version 0.2.0 #79

@chrylis

This comment has been minimized.

Show comment
Hide comment
@chrylis

chrylis Dec 5, 2013

+1 again for relative units. My Galaxy S3's 2.5-inch-wide 720px screen displays px-valued styles tiny, and the whole point of using a responsive layout is to be able to use equivalent descriptions for desktop and mobile.

chrylis commented Dec 5, 2013

+1 again for relative units. My Galaxy S3's 2.5-inch-wide 720px screen displays px-valued styles tiny, and the whole point of using a responsive layout is to be able to use equivalent descriptions for desktop and mobile.

@tmaiaroto

This comment has been minimized.

Show comment
Hide comment
@tmaiaroto

tmaiaroto Dec 6, 2013

You can have all the gripes with em/rem in the world, but at the end of the day this framework has absolutely appalling typography. The grid system, various components, and JavaScript are all well and fine, but it needs to seriously step up its game with typography. +1 for rems and considering the use of a baseline grid.

Some people have already tried to work toward it...But for older versions of Bootstrap.
https://github.com/vwall/compass-twitter-bootstrap
https://github.com/jonschlinkert/vertical-rhythm

To be clear, I really like Bootstrap and think it's super awesome. It just needs to push the design a tiny bit farther. I'm trying to find a good solution to the problem myself...Including non-invasive add-ons so that it can be completely optional.

You can have all the gripes with em/rem in the world, but at the end of the day this framework has absolutely appalling typography. The grid system, various components, and JavaScript are all well and fine, but it needs to seriously step up its game with typography. +1 for rems and considering the use of a baseline grid.

Some people have already tried to work toward it...But for older versions of Bootstrap.
https://github.com/vwall/compass-twitter-bootstrap
https://github.com/jonschlinkert/vertical-rhythm

To be clear, I really like Bootstrap and think it's super awesome. It just needs to push the design a tiny bit farther. I'm trying to find a good solution to the problem myself...Including non-invasive add-ons so that it can be completely optional.

@carasmo

This comment has been minimized.

Show comment
Hide comment
@carasmo

carasmo Dec 6, 2013

Respond.js has supported ems for a few years.

Well, it's pretty easy to convert the media queries to ems and it's MUCH better, especially due to page zooming and because of the following:

The 62.5% value made sense on the desktop as we were trying to approximate physical print sizes on screens that somewhat varied in size but were by and large consistent at 72 dpi. Because of the much larger variance in dpi, big differences in physical size, and differences in browser implementation on mobile, if you are trying to make a responsive site, I don't think using this value to gauge a font baseline is relevant any more..(...unless you only use it for the largest and presumed desktop layout but then use a different set of values altogether for the presumed mobile layouts...and I say presumed because of certain tablets or larger mobiles whose landscape dimensions are similar to the size of a PC so end up matching to a 'desktop' media query)
scottjehl/Respond#18 (comment)*

Now I've got some mixins for rems on fonts, margins, and padding so IE8 can see the fonts in rem which I have to figure out based on a 16px baseline. BTW, IOS is 16px that's why the page zooms when you focus an input unless you have a fix in your css for that.

Target Size / Base Size = Value
Since we can assume that browsers use 16px as default (after all, that's what Jonathan Snook did to assume that 62.5% is 10px), then your Base is 16. If you want 32px, then 32 / 16 = 2, want 40px then 40 / 16 = 2.5, want 24 then 24 / 16 = 1.5.
The same goes for 75%... Determine what 75% is (it's 12) and perform the same calculation. If you want 32px, then 32 / 12 = 2.666, want 40px then 40 / 12 = 3.333, want 24 then 24 / 12 = 2.
http://stackoverflow.com/questions/11352783/how-to-calculate-rem-for-type

There's a thread on here on vertical rhythm #11601. It's been VERY good to remove all top margins and even just have a bottom margin on hr tags, no guess work and hardly any over-rides. Plus you can make some nice spacers with empty hr and use that visible-xs on them. Yum

carasmo commented Dec 6, 2013

Respond.js has supported ems for a few years.

Well, it's pretty easy to convert the media queries to ems and it's MUCH better, especially due to page zooming and because of the following:

The 62.5% value made sense on the desktop as we were trying to approximate physical print sizes on screens that somewhat varied in size but were by and large consistent at 72 dpi. Because of the much larger variance in dpi, big differences in physical size, and differences in browser implementation on mobile, if you are trying to make a responsive site, I don't think using this value to gauge a font baseline is relevant any more..(...unless you only use it for the largest and presumed desktop layout but then use a different set of values altogether for the presumed mobile layouts...and I say presumed because of certain tablets or larger mobiles whose landscape dimensions are similar to the size of a PC so end up matching to a 'desktop' media query)
scottjehl/Respond#18 (comment)*

Now I've got some mixins for rems on fonts, margins, and padding so IE8 can see the fonts in rem which I have to figure out based on a 16px baseline. BTW, IOS is 16px that's why the page zooms when you focus an input unless you have a fix in your css for that.

Target Size / Base Size = Value
Since we can assume that browsers use 16px as default (after all, that's what Jonathan Snook did to assume that 62.5% is 10px), then your Base is 16. If you want 32px, then 32 / 16 = 2, want 40px then 40 / 16 = 2.5, want 24 then 24 / 16 = 1.5.
The same goes for 75%... Determine what 75% is (it's 12) and perform the same calculation. If you want 32px, then 32 / 12 = 2.666, want 40px then 40 / 12 = 3.333, want 24 then 24 / 12 = 2.
http://stackoverflow.com/questions/11352783/how-to-calculate-rem-for-type

There's a thread on here on vertical rhythm #11601. It's been VERY good to remove all top margins and even just have a bottom margin on hr tags, no guess work and hardly any over-rides. Plus you can make some nice spacers with empty hr and use that visible-xs on them. Yum

@carasmo

This comment has been minimized.

Show comment
Hide comment
@carasmo

carasmo Dec 6, 2013

// Extra small screen / phone
// Note: Deprecated @screen-xs and @screen-phone as of v3.0.1
//@screen-xs: 480px;
//@screen-phone: @screen-xs-min;

@screen-xs-min: 480px;
@screen-xs-min: 30.000em;

// Small screen / tablet
// Note: Deprecated @screen-sm and @screen-tablet as of v3.0.1
//@screen-sm: 768px;
//@screen-tablet: @screen-sm-min;

@screen-sm-min: 768px;
@screen-sm-min: 48.000em;

// Medium screen / desktop
// Note: Deprecated @screen-md and @screen-desktop as of v3.0.1
//@screen-md: 992px;
//@screen-desktop: @screen-md-min;

@screen-md-min: 992px;
@screen-md-min: 62.000em;


// Large screen / wide desktop
// Note: Deprecated @screen-lg and @screen-lg-desktop as of v3.0.1
//@screen-lg: 1200px;
//@screen-lg-desktop: @screen-lg-min;

@screen-lg-min: 1200px;
@screen-lg-min: 75.000em;

html font-size is now 100%

IE 8 is behaving.

carasmo commented Dec 6, 2013

// Extra small screen / phone
// Note: Deprecated @screen-xs and @screen-phone as of v3.0.1
//@screen-xs: 480px;
//@screen-phone: @screen-xs-min;

@screen-xs-min: 480px;
@screen-xs-min: 30.000em;

// Small screen / tablet
// Note: Deprecated @screen-sm and @screen-tablet as of v3.0.1
//@screen-sm: 768px;
//@screen-tablet: @screen-sm-min;

@screen-sm-min: 768px;
@screen-sm-min: 48.000em;

// Medium screen / desktop
// Note: Deprecated @screen-md and @screen-desktop as of v3.0.1
//@screen-md: 992px;
//@screen-desktop: @screen-md-min;

@screen-md-min: 992px;
@screen-md-min: 62.000em;


// Large screen / wide desktop
// Note: Deprecated @screen-lg and @screen-lg-desktop as of v3.0.1
//@screen-lg: 1200px;
//@screen-lg-desktop: @screen-lg-min;

@screen-lg-min: 1200px;
@screen-lg-min: 75.000em;

html font-size is now 100%

IE 8 is behaving.

@ribzin

This comment has been minimized.

Show comment
Hide comment
@ribzin

ribzin Jan 8, 2014

I'm switching to Foundation. REMs !!

ribzin commented Jan 8, 2014

I'm switching to Foundation. REMs !!

@boulox

This comment has been minimized.

Show comment
Hide comment
@boulox

boulox Jan 8, 2014

Contributor

+1 bs v4 drop ie8 support and switch to rem unit :)

Contributor

boulox commented Jan 8, 2014

+1 bs v4 drop ie8 support and switch to rem unit :)

@carasmo

This comment has been minimized.

Show comment
Hide comment
@carasmo

carasmo Jan 8, 2014

I have ems and rems and all was rather easy to adjust myself and have fallbacks for IE8 which people still use

carasmo commented Jan 8, 2014

I have ems and rems and all was rather easy to adjust myself and have fallbacks for IE8 which people still use

@boulox

This comment has been minimized.

Show comment
Hide comment
@boulox

boulox Jan 8, 2014

Contributor

@carasmo if you use rem for every rules in your CSS, the ie8 fallback duplicate all lot of code.
It's personal opinion but i believe so much extra bites don't worth it.

Contributor

boulox commented Jan 8, 2014

@carasmo if you use rem for every rules in your CSS, the ie8 fallback duplicate all lot of code.
It's personal opinion but i believe so much extra bites don't worth it.

@carasmo

This comment has been minimized.

Show comment
Hide comment
@carasmo

carasmo Jan 9, 2014

I use a ZDroid pull request on the responsive utilities, which eliminated over 200 lines of compiled CSS, then I use one small reset file so I don't have to mess with the less files. I base my font size on 16px for the html (100%). Respond.js already supports ems.

This is the compiled less for all font-sizes which uses a mixin to create:

/* -------------- [ convert BOOTSTRAP font sizes to REMS ] --------*/
.close {
font-size: 21px;
font-size: 1.3125rem;
}
.badge {
font-size: 12px;
font-size: 0.75rem;
}
.dropdown-menu {
font-size: 14px;
font-size: 0.875rem;
}
pre {
font-size: 13px;
font-size: 0.8125rem;
}
.navbar-brand {
font-size: 18px;
font-size: 1.125rem;
}
.tooltip {
font-size: 12px;
font-size: 0.75rem;
}
.progress-bar {
font-size: 12px;
font-size: 0.75rem;
}
.popover-title {
font-size: 14px;
font-size: 0.875rem;
}
legend {
font-size: 21px;
font-size: 1.3125rem;
}
output {
font-size: 14px;
font-size: 0.875rem;
}
.form-control {
font-size: 14px;
font-size: 0.875rem;
}
.input-group-addon {
font-size: 14px;
font-size: 0.875rem;
}
.input-sm {
font-size: 12px;
font-size: 0.75rem;
}
.input-lg {
font-size: 18px;
font-size: 1.125rem;
}
.btn {
font-size: 14px;
font-size: 0.875rem;
}
.btn-lg {
font-size: 18px;
font-size: 1.125rem;
}
.btn-sm {
font-size: 12px;
font-size: 0.75rem;
}
.btn-xs {
font-size: 12px;
font-size: 0.75rem;
}

The gutters and all else is are in percentages and I use px when it's appropriate.

carasmo commented Jan 9, 2014

I use a ZDroid pull request on the responsive utilities, which eliminated over 200 lines of compiled CSS, then I use one small reset file so I don't have to mess with the less files. I base my font size on 16px for the html (100%). Respond.js already supports ems.

This is the compiled less for all font-sizes which uses a mixin to create:

/* -------------- [ convert BOOTSTRAP font sizes to REMS ] --------*/
.close {
font-size: 21px;
font-size: 1.3125rem;
}
.badge {
font-size: 12px;
font-size: 0.75rem;
}
.dropdown-menu {
font-size: 14px;
font-size: 0.875rem;
}
pre {
font-size: 13px;
font-size: 0.8125rem;
}
.navbar-brand {
font-size: 18px;
font-size: 1.125rem;
}
.tooltip {
font-size: 12px;
font-size: 0.75rem;
}
.progress-bar {
font-size: 12px;
font-size: 0.75rem;
}
.popover-title {
font-size: 14px;
font-size: 0.875rem;
}
legend {
font-size: 21px;
font-size: 1.3125rem;
}
output {
font-size: 14px;
font-size: 0.875rem;
}
.form-control {
font-size: 14px;
font-size: 0.875rem;
}
.input-group-addon {
font-size: 14px;
font-size: 0.875rem;
}
.input-sm {
font-size: 12px;
font-size: 0.75rem;
}
.input-lg {
font-size: 18px;
font-size: 1.125rem;
}
.btn {
font-size: 14px;
font-size: 0.875rem;
}
.btn-lg {
font-size: 18px;
font-size: 1.125rem;
}
.btn-sm {
font-size: 12px;
font-size: 0.75rem;
}
.btn-xs {
font-size: 12px;
font-size: 0.75rem;
}

The gutters and all else is are in percentages and I use px when it's appropriate.

@mdo

This comment has been minimized.

Show comment
Hide comment
@mdo

mdo Jan 10, 2014

Member

For those following along, we'll be able to change from pixels to REMs in v4 when we drop IE8 support. Can't do much until then.

Member

mdo commented Jan 10, 2014

For those following along, we'll be able to change from pixels to REMs in v4 when we drop IE8 support. Can't do much until then.

@carpeliam carpeliam referenced this issue in projecttacoma/bonnie Feb 6, 2014

Closed

Measure two-step delete, with sliding buttons #75

@jasny

This comment has been minimized.

Show comment
Hide comment
@jasny

jasny Mar 24, 2014

Contributor

If you want to use EM / REM with Bootstrap 3, try this gist.

Contributor

jasny commented Mar 24, 2014

If you want to use EM / REM with Bootstrap 3, try this gist.

@RogueSkolar

This comment has been minimized.

Show comment
Hide comment
@RogueSkolar

RogueSkolar May 25, 2014

Big up for that @jasny!

The pixel issue has been the only thing that has held me back in adopting Bootstrap to the fullest and thus mostly been working with Foundation. Big fan of both frameworks for various reasons, just that damn pixel issue... and to refactor, well it's a bit laborious especially for time starved folks. BS4 sounds real promising, this is a great development, great stuff @mdo! Very pleased about this.

Big up for that @jasny!

The pixel issue has been the only thing that has held me back in adopting Bootstrap to the fullest and thus mostly been working with Foundation. Big fan of both frameworks for various reasons, just that damn pixel issue... and to refactor, well it's a bit laborious especially for time starved folks. BS4 sounds real promising, this is a great development, great stuff @mdo! Very pleased about this.

@twbs twbs locked and limited conversation to collaborators Jun 9, 2014

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.