-
-
Notifications
You must be signed in to change notification settings - Fork 876
Deprecate em()
and rem()
functions
#691
Comments
Also, Bitters has |
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? |
While rems are more constant than ems, they are not totally absolute. Rems are based off the root element ( 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. |
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. |
@ethangl Can you provide an example? |
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 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 |
This is the mixin with the non-salient bits removed:
@joshuaogle I definitely could use rems but I'd generally rather not use them with typographic elements. |
On second thought: ✂️ |
Why remove something this useful? |
@elomatreb I consider both of them very readable, simply from a code perspective. I’m more suggesting that in the case above, That being said, I put this up to open a discussion about these functions. May I ask how you typically use |
These functions are especially useful for people who previously wrote everything in 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). |
@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). |
Again: Why remove them? If you wan't to use em/rem directly, you are free 2015-03-15 16:56 GMT+01:00 Tyson Gach notifications@github.com:
Ole B. PGP: #31E36AEC XMPP: ole@elomatreb.eu |
@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 Part of Bourbon’s purpose is not only to make stylesheets more maintainable, but also human readable. While 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. |
@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. |
@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! |
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 @brendastorer I don't personally use these often actually, but I always thought they could be useful if people still rely on thinking in |
@conchan Thanks for your input. |
em()
and rem()
functions
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 |
@ryanburnette Couple thoughts:
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.
Flexbox and good Sass variables do this for me.
I think that is a fine idea if you do find them useful. |
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? |
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? |
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. |
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. |
@benfurfie is spot on.
When @tysongach writes:
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. |
Pixels are just the unit of rendering, they don’t form the design. |
@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. |
@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 … |
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. |
@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.
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. |
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: |
I think the
em
andrem
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:
The code above makes it appear that
margin-right
is equal to 48px. However, the output of will actually be3em
, which equates to60px
. 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: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.
_grid
in Neat (PR)The text was updated successfully, but these errors were encountered: