Deprecate `em()` and `rem()` functions #691

tysongach · 2015-03-03T19:31:45Z

I think the em and rem functions should be deprecated because they do not properly indicate the true output and make the em to pixel conversion more confusing.

Ems are powerful because they are not an absolute unit, but rather based off their parent’s font size. So if the font size through an entire website or app remained at 16px, then this function would make sense. But that is not always the case.

Consider this example:

.element {
  font-size: 20px;

  .nested-element {
    margin-right: em(48);
  }
}

The code above makes it appear that margin-right is equal to 48px. However, the output of will actually be 3em, which equates to 60px. This is because the parent font size has changed and the function has no way of taking that into consideration automatically.

Of course, you can pass a second argument into the function (e.g. em(12, 24)), but this adds unnecessary overhead and our Sass has now become more verbose and less DRY:

.element {
  font-size: 20px;

  .nested-element {
    margin-right: em(48, 20);
  }
}

Done many times throughout stylesheets and it makes for lots of repetition.

I have found that if you give up thinking about layouts in exact pixels and instead align things relationally, everything still falls into place nicely.

Remove from _grid in Neat (PR)
Remove from Neat’s readme
Remove from Bourbon’s modular scale function
Deprecate $em-base since it would no longer be used

The text was updated successfully, but these errors were encountered:

tysongach · 2015-03-03T19:36:25Z

Also, Bitters has $base-spacing and $small-spacing which provide more chosive means of adding margins and other spacing.

mborsare · 2015-03-03T19:51:26Z

I get the argument for removing the em function, but rem is constant so why remove it? Would there be a way to make the em function cognizant of the parent's font-size via some Sass magic?

tysongach · 2015-03-03T19:55:59Z

While rems are more constant than ems, they are not totally absolute. Rems are based off the root element (<html>) and if you change the font size there, the rem function no longer makes sense either. I think if one is removed, they both should be removed.

Unfortunately, there is no Sass magic to be had in which these functions can automatically be aware of changes to the font size of a parent.

ethangl · 2015-03-03T21:21:41Z

It shouldn't be deprecated -- I'm writing a vertical rhythm mixin and being able to set the parent value of em() is extremely useful.

On the other hand I don't think it should be used simply as a pixels-to-ems convertor, for the reasons you stated above.

tysongach · 2015-03-03T21:26:39Z

@ethangl Can you provide an example?

joshuaogle · 2015-03-03T21:46:37Z

I'm in favor of getting rid of them. It feels like most of us are using them as training wheels, and we would be much better off using em or rem values directly and stop thinking in pixels. Or when the situation calls for px, use pixels and don't feel bad about it.

Keep in mind these are used a bit in the rest of the suite as well, but I don't see anywhere that shouldn't be easy to convert.

@ethangl Sounds like a great place to use rem instead, no?

ethangl · 2015-03-03T22:29:00Z

This is the mixin with the non-salient bits removed:

@mixin vertical-rhythm($size, $top: 1, $bottom: 1) {
  margin-top: em($base-rhythm, $size) * $top;
  margin-bottom: em($base-rhythm, $size) * $bottom;
}

@joshuaogle I definitely could use rems but I'd generally rather not use them with typographic elements.

ethangl · 2015-03-04T15:51:14Z

On second thought: ✂️

elomatreb · 2015-03-04T17:29:54Z

Why remove something this useful? em(30) is definitely more readable than 1.875em, and that em is relative to font size should be common knowledge.

tysongach · 2015-03-04T18:19:51Z

@elomatreb I consider both of them very readable, simply from a code perspective. I’m more suggesting that in the case above, em(30) will not necessary output a value that is equal to 30px. I think this is mis-leading.

That being said, I put this up to open a discussion about these functions. May I ask how you typically use em() and rem()?

elomatreb · 2015-03-08T18:10:39Z

These functions are especially useful for people who previously wrote everything in px. seeing how they work and using these functions took, for me, the magic out of em and rem.

I don't think in em/rem when designing (yet?), and I don't think I am the only one with that problem (if it is a problem).

tysongach · 2015-03-15T15:56:49Z

@elomatreb I see your point, but it feels like a crutch to me. I think the community as a whole has been moving away from pixel-based lengths for awhile now. That’s not to say that pixels should never be used; they have their time and place. But this function is masking relational units behind—possibly non-indicative—fixed units.

The discussion in this thread leans towards removing these functions. At the end of the day, Bourbon is just a library of Sass mixins and functions, so these can easily be added to a project on a case-by-case basis by the author(s).

elomatreb · 2015-03-15T17:20:20Z

Again: Why remove them? If you wan't to use em/rem directly, you are free
to do so, and these functions don't require any real maintenance, do they?

2015-03-15 16:56 GMT+01:00 Tyson Gach notifications@github.com:

@elomatreb https://github.com/elomatreb I see your point, but it feels
like a crutch to me. I think the community as a whole has been moving away
from pixel-based lengths for awhile now. That’s not to say that pixels
should never be used; they have their time and place. But this function is
masking relational units behind—possibly non-indicative—fixed units.

The discussion in this thread leans towards removing these functions. At
the end of the day, Bourbon is just a library of Sass mixins and functions,
so these can easily be added to a project on a case-by-case basis by the
author(s).

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

Ole B.
https://elomatreb.eu

PGP: #31E36AEC
https://keybase.io/elomatreb

XMPP: ole@elomatreb.eu

tysongach · 2015-03-15T17:57:11Z

@elomatreb Bourbon 5.0 will be tightened up a lot. We’re cleaning house, a bit.

If a feature isn’t used very much or doesn’t provide meaningful value, we should remove it. In return, documentation gets shorter and more concise, and the overall codebase becomes easier to maintain. Also, in the case of em(), a few other features in Bourbon and Neat use it (in a not so meaningful way) and so those will also get cleaned up.

Part of Bourbon’s purpose is not only to make stylesheets more maintainable, but also human readable. While em(20) is quite readable, it’s quite possibly highlighting a completely meaningless value.

I know that I never use these functions. So this discussion was opened to help understand how others use them, if at all. Nothing is final, yet.

elomatreb · 2015-03-15T18:05:14Z

@tysongach OK, I wasn't really aware of these plans for 5.0. I guess I could live without these functions, I only want to highlight that they were really helpful when getting started with em/rem, since they removed some of the magic from these units.

tysongach · 2015-03-15T18:09:11Z

@elomatreb I can see that. And I think that’s exactly why I see it simply as a crutch and less of a meaningful function.

I know you pitch in a lot here on Bourbon, so know that I do value your opinion!

brendastorer · 2015-03-16T19:57:15Z

I totally support this. @tysongach Your first sentence sums it up, they do not, and cannot properly indicate the true output. I have stopped using them because they are so unreliable, especially when used as a value for a variable.

conchan · 2015-03-17T01:38:02Z

@tysongach @brendastorer I don't personally use these often actually, but I always thought they could be useful if people still rely on thinking in px. However, it seems I've also misunderstood how they worked, so I withdraw my earlier hesitation.

tysongach · 2015-03-17T01:52:33Z

@conchan Thanks for your input.

ryanburnette · 2017-03-20T17:32:47Z

I'm intentionally opening my coding style up to ridicule here, and please bring it on if anyone has a comment, but I wanted to add that since the deprecation notice on em() and rem() I've quit using them and I find myself constantly hitting ⌘+space typing out a quick calculation like 100/16 and returning to Vim to type a property like width: 6.25rem. Maybe I just need to quit thinking in pixels and I've been doing it for too long, but there are a lot of cases where I'm styling the sizes of elements down to the pixel because I want everything to line up perfectly. I feel like life was better when I was using em() and rem(). I might end up patching them back in on my own. Feedback is appreciated ... brutal if necessary.

tysongach · 2017-03-20T18:00:37Z

@ryanburnette Couple thoughts:

Maybe I just need to quit thinking in pixels

For me, the moment I started not thinking in pixels, my style of building out front-ends changed a lot (for the better, I think). I think it goes along with the whole idea of truly responsive design, as well, in that the web is a fluid medium, so the more fluid we are with our designs and design thinking, the better.

styling the sizes of elements down to the pixel because I want everything to line up perfectly

Flexbox and good Sass variables do this for me.

I might end up patching them back in on my own

I think that is a fine idea if you do find them useful.

zachtownsend · 2017-03-29T11:11:38Z

Does anyone have good advice for coding directly in rems to those of us who use the rem() function extensively? The designs I receive are in PSD format, so all values are in pixels - how do I translate these quickly and reliably into rem values? Is it just a case of manually calculating it every time?

zachtownsend · 2017-03-29T11:13:52Z

To answer my own question - I've found this Sublime package that might be a better approach: https://packagecontrol.io/packages/REM%20PX

Anyone else have any other tips?

benfurfie · 2017-04-19T15:46:38Z

The problem with saying we should just stop thinking in pixels is that it completely ignored the reality that a whole chunk of the front end development community works off designs that are based on px values.

As others have said, if you don't use rem(), then don't use it. But for those of us who work off pixel-based designs, they are invaluable to helping us not constantly need to use a calculator or adding the functionality back in anyway via our own mixin.

jpdevries · 2017-04-19T18:22:11Z

works off designs that are based on px values

Designs are displayed on screen in px but they aren't based off px. They are based on grids, columns, gutters, and relative typographic units. Type in PSDs are set in pts, a unit that existed long before pixels.

I can understand the maintainers reasoning for deprecating these mixins. I just hope it doesn't result in even more widespread use of setting layout and type declaratively in pixels. Hopefully developers roll their own mixins or come up with some other solution.

laustdeleuran · 2017-06-02T17:25:51Z

@benfurfie is spot on.

The problem with saying we should just stop thinking in pixels is that it completely ignored the reality that a whole chunk of the front end development community works off designs that are based on px values.

When @tysongach writes:

I have found that if you give up thinking about layouts in exact pixels and instead align things relationally, everything still falls into place nicely.

I totally agree from a theoretical point of view, and most good UI designers understand this. However, many designers (and clients) doesn't have the experience or background to provide designs that doesn't rely on pixel values - and those designs come with those expectations.

I, for one, find myself reimplementing these functions locally in most of my projects, except the ones where I can allow myself not to think in pixels.

It's a beautiful dream, but I'm not sure we're there yet.

tysongach · 2017-06-02T17:28:07Z

Pixels are just the unit of rendering, they don’t form the design.

laustdeleuran · 2017-06-02T17:31:01Z

@tysongach I get that, and I agree.

But I also live in a reality where I have to build designs I get delivered from clients with a wide range of backgrounds, some in print. Most of these still use pixels to form the design, as they would use inches in print. For those projects, I am still forced to either rely on pixels or take a huge step back and try to educate the designer.

Most of the time, the latter isn't a practical solution.

mistergraphx · 2017-06-02T17:43:26Z

@laustdeleuran why d'ont you use a pre-process or post-process to convert your css px values in rem or what you want ? You can do it with a gulp task or npm script or any build tool …

ex: https://www.npmjs.com/package/postcss-px-to-em

tysongach · 2017-06-02T17:43:33Z

or take a huge step back and try to educate the designer.

I wouldn't consider this a huge step back.

These functions are being removed from Bourbon, but that doesn't mean you can't re-create them in your project if you need them. Most of the web has moved on from pixels and as outlined above, the functions ran the risk of actually lying about what actual pixel value would be output.

laustdeleuran · 2017-06-02T17:51:28Z

@mistergraphx Thanks, will definitely check that out.

@tysongach Hehehe. To be clear, I love Bourbon, and I'm super grateful for what it's contributed to my own ease of coding and the community. Been using it for years.

But asking me to educate the designer seems like imposing a pretty big ask on the parts of the front-end community that's not as lucky as you are in terms of who they get to work with. In most projects, starting that education process is way out of scope / budget / timeline, not to say that far from all clients / designers are receptive to that kind of feedback.

Most of the web has moved on from pixels...

To me, this is a very privileged stance to take. I get what you're saying, and asking people to recreate them if they need the functions is WAY more helpful than just saying that they should "design better". An even better way would be to push these two functions into a new repo where people could get at them instead of just removing them, referencing the thoughts behind moving them and why some people might still need them. Just my five cents.

tysongach · 2017-06-02T17:59:38Z

An even better way would be to push these two functions into a new repo where people could get at them instead of just removing them

Yes, but that means maintaining them, which (at least speaking for myself) I have no interest in because I wouldn’t use them. If you feel strongly about having such a thing, I think you should totally make that open-source project. Here’s the code for the two functions:

tysongach added [type] deprecation question labels Mar 3, 2015

tysongach added this to the 5.0.0 milestone Mar 16, 2015

tysongach mentioned this issue Mar 23, 2015

Remove em() function thoughtbot/neat#327

Merged

tysongach closed this as completed Mar 23, 2015

tysongach mentioned this issue Mar 16, 2016

missing pixels to ems function in version 5 beta 4 #877

Closed

tysongach mentioned this issue Jul 19, 2016

Bourbon + bootstrap: and use of REM function #921

Closed

tysongach mentioned this issue Dec 20, 2016

rem function removal without mention or recommended replacement #986

Closed

tysongach changed the title ~~Deprecate Pixels to Ems and Pixels to Rems~~ Deprecate em() and rem() functions Dec 20, 2016

thoughtbot locked and limited conversation to collaborators Jun 2, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deprecate `em()` and `rem()` functions #691

Deprecate `em()` and `rem()` functions #691

tysongach commented Mar 3, 2015

tysongach commented Mar 3, 2015

mborsare commented Mar 3, 2015

tysongach commented Mar 3, 2015

ethangl commented Mar 3, 2015

tysongach commented Mar 3, 2015

joshuaogle commented Mar 3, 2015

ethangl commented Mar 3, 2015

ethangl commented Mar 4, 2015

elomatreb commented Mar 4, 2015

tysongach commented Mar 4, 2015

elomatreb commented Mar 8, 2015

tysongach commented Mar 15, 2015

elomatreb commented Mar 15, 2015

tysongach commented Mar 15, 2015

elomatreb commented Mar 15, 2015

tysongach commented Mar 15, 2015

brendastorer commented Mar 16, 2015

conchan commented Mar 17, 2015

tysongach commented Mar 17, 2015

ryanburnette commented Mar 20, 2017

tysongach commented Mar 20, 2017

zachtownsend commented Mar 29, 2017

zachtownsend commented Mar 29, 2017

benfurfie commented Apr 19, 2017

jpdevries commented Apr 19, 2017

laustdeleuran commented Jun 2, 2017 •

edited

tysongach commented Jun 2, 2017

laustdeleuran commented Jun 2, 2017 •

edited

mistergraphx commented Jun 2, 2017

tysongach commented Jun 2, 2017

laustdeleuran commented Jun 2, 2017

tysongach commented Jun 2, 2017

Deprecate em() and rem() functions #691

Deprecate em() and rem() functions #691

Comments

tysongach commented Mar 3, 2015

tysongach commented Mar 3, 2015

mborsare commented Mar 3, 2015

tysongach commented Mar 3, 2015

ethangl commented Mar 3, 2015

tysongach commented Mar 3, 2015

joshuaogle commented Mar 3, 2015

ethangl commented Mar 3, 2015

ethangl commented Mar 4, 2015

elomatreb commented Mar 4, 2015

tysongach commented Mar 4, 2015

elomatreb commented Mar 8, 2015

tysongach commented Mar 15, 2015

elomatreb commented Mar 15, 2015

tysongach commented Mar 15, 2015

elomatreb commented Mar 15, 2015

tysongach commented Mar 15, 2015

brendastorer commented Mar 16, 2015

conchan commented Mar 17, 2015

tysongach commented Mar 17, 2015

ryanburnette commented Mar 20, 2017

tysongach commented Mar 20, 2017

zachtownsend commented Mar 29, 2017

zachtownsend commented Mar 29, 2017

benfurfie commented Apr 19, 2017

jpdevries commented Apr 19, 2017

laustdeleuran commented Jun 2, 2017 • edited

tysongach commented Jun 2, 2017

laustdeleuran commented Jun 2, 2017 • edited

mistergraphx commented Jun 2, 2017

tysongach commented Jun 2, 2017

laustdeleuran commented Jun 2, 2017

tysongach commented Jun 2, 2017

Deprecate `em()` and `rem()` functions #691

Deprecate `em()` and `rem()` functions #691

laustdeleuran commented Jun 2, 2017 •

edited

laustdeleuran commented Jun 2, 2017 •

edited