This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
I love popping into the latest "Welcome" thread as part of my daily DEV routine. At the top of the recent Welcome Thread - v49, @celinemol introduced themselves. Consider hopping into these threads (you can jump there directly via dev.to/welcome) to welcome new members!
Hello! I'm Celine. I am visiting from beautiful, sunny Santa Barbara, California. I do software engineering for an awesome company called Apeel Sciences. We develop plant-derived technologies that help extend the shelf life of fresh produce.
I just started in the software space, been at it for a couple of years now. I come from a background in data science. I hope to give back to the data science community by recommending good coding practices to make your data science models more reproducible, scalable, and robust.
Thanks for having me! Excited to be here (:
Replying to What was the funniest thing, a non-tech ever said to you?, @gmkumar08 shares a truly hilarious misconception:
A guy I used to work with told me to put the cap over the USB drive else it would catch a virus.
@remibruguier talks about being there for a friend battling imposter syndrome in the What was your win this week? thread. There are a bunch of great articles about imposter syndrome on DEV, be sure to check them out.:
I spent a few hours after work with one of my co-workers who was struggling with a serious case of Impostor syndrome to help him realize how much value he had and it seems like it worked.
He looks way better now and I'm glad I could help him !
@ahferroin7 answered the following question with a tremendously helpful comment: %, px, em, rem, viewport...How to know which one to use in CSS for responsive design?:
All of them are usable interchangeably. In fact, you can even mix them in calc() calls and it will work correctly (a lot of CSS frameworks do this to properly account for padding and borders when computing sizes).
In general though:
- Inches, points (1/72 of an inch, or roughly 0.353mm), millimeters, and centimeters should all be avoided unless you need to (try) and have a 'real size' or properly scaled image. In CSS, they get computed from pixel counts based on the pixel size of the display. The problem is that this is unreliable except for print media (printers pretty much always know their dot-pitch), as modern displays may have different pixel sizes in the horizontal and vertical axis, and many displays lie about their DPI/DPM.
- Pixels should only be used when you need very thin lines (for example, borders) or are trying to set the exact size of an image to prevent it from getting scaled (though the second case doesn't work reliably, and should use one of the other physical units instead when dealing with print media (
1pxin print media for most CSS implementations is equal to1pt). They aren't responsive, aren't consistent, and sometimes interfere with zoom functionality. - Viewport units should be used sparingly for things like overlays that need to scale only based on the size of the display. Even then, they're tricky to get right and can cause issues (if not used correctly, they will cause problems at non-default zoom levels). They also have a number of odd quirks that vary from browser to browser (for example, everything but Firefox implements
100vwincorrectly (they include the scrollbar width, but should not)). You almost never want to use them for things like font sizes, as they can exhibit some really unexpected behavior there for users (imagine the font size changing when the user resizes the browser window or switches into or out of full-screen mode). - Percentages should be used when you need to scale a property based on the value of the same property in the parent element (or what the computed value for that property is for the parent element). For example, controlling how big sidebars are in text, or helping set some default number of elements per row/column in a flexbox layout. Percentages technically work for font sizes, but I would advocate avoiding using them for that, as EM's and REM's work just as well and behave in a slightly more logical manner for most people.
- EM's should be used when you need to scale a property off of the font size of the element (or the font size of it's parent if you're using them to set the element's font size). Usually this is just used for tweaking the font-size of small sections of text. An example use case would be the pages that some sites have with a big list of tags, with each tag's text size based on it's popularity. Many such sites use a single
<span>element for each tag, and change the font-size of that using EM units. - REM's should be used for almost everything else. They work like EM units, but scale off of the font size of the document root element (so the
<html>or<body>element in most cases), which means that they're consistent regardless of where they are being used in the hierarchy (IOW,1remis always the same size, no matter where it shows up in the hierarchy), and, as a result, are easier for most people to reason about.
Finally, @syntaxseed provides great context about the importance of inclusive and welcoming language in response to How to remove condescending language from documentation:
It's literally the foundation of what we do: create things for users. If you create libraries & tools that have documentation... that documentation is also something we create for the users.
And much like we try to be aware of tuning our creations to the accessibility, aesthetics, demographics, & skill levels of our users... a few simple adjustments to consider the confidence level of our users & not degrade them unintentionally is as valuable as any other usability feature.
Happy users = successful development, no matter how you ensure that happiness.
See you next week for more great comments ✌
Latest comments (3)
😄
Congrats to @celinemol , @gmkumar08 , @remibruguier , @ahferroin7 , and @syntaxseed for making the list this week!
Awesome!!!