Skip to content
This repository has been archived by the owner on Sep 13, 2024. It is now read-only.

Deprecate em() and rem() functions #691

Closed
4 tasks done
tysongach opened this issue Mar 3, 2015 · 32 comments
Closed
4 tasks done

Deprecate em() and rem() functions #691

tysongach opened this issue Mar 3, 2015 · 32 comments

Comments

@tysongach
Copy link
Contributor

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.


@tysongach
Copy link
Contributor Author

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

@mborsare
Copy link

mborsare commented Mar 3, 2015

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
Copy link
Contributor Author

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
Copy link

ethangl commented Mar 3, 2015

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
Copy link
Contributor Author

@ethangl Can you provide an example?

@joshuaogle
Copy link
Contributor

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
Copy link

ethangl commented Mar 3, 2015

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
Copy link

ethangl commented Mar 4, 2015

On second thought: ✂️

@elomatreb
Copy link

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
Copy link
Contributor Author

@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
Copy link

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
Copy link
Contributor Author

@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
Copy link

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
Copy link
Contributor Author

@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
Copy link

@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
Copy link
Contributor Author

@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
Copy link

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.

@tysongach tysongach added this to the 5.0.0 milestone Mar 16, 2015
@conchan
Copy link
Contributor

conchan commented Mar 17, 2015

@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
Copy link
Contributor Author

@conchan Thanks for your input.

@ryanburnette
Copy link

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
Copy link
Contributor Author

@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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

laustdeleuran commented Jun 2, 2017

@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
Copy link
Contributor Author

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

@laustdeleuran
Copy link

laustdeleuran commented Jun 2, 2017

@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
Copy link

@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
Copy link
Contributor Author

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
Copy link

@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
Copy link
Contributor Author

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:

@thoughtbot thoughtbot locked and limited conversation to collaborators Jun 2, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests