Facebook fixes several problems with npm; will yarn become the new standard, will npm make changes, or will developers not care?
We’ve used the npm client successfully at Facebook for years, but as the size of our codebase and the number of engineers grew, we ran into problems with consistency, security, and performance. After trying to solve for each issue as it came up, we set out to build a new solution to help us manage our dependencies more reliably. The product of that work is called Yarn — a fast, reliable, and secure alternative npm client.
Read more at Facebook Code
If you’e ever dealt with trying to make complex emails look good on every email client, you’ll know how big of a deal this is.
Big news email designers: Gmail announces that they will support responsive email design, as well as improved font styling and CSS for accessibility.
Read more at Litmus
Remote-First: a company culture that hires without regard to location, with a culture of productivity to match
Thoughts on building a remote culture, from a remote CEO.
Paul Farnell, CEO of Litmus writes:
One misconception about remote work is that it hinders collaboration. In my experience, the inverse is more likely: offices hinder independent work. Collaboration tends to happen in short bursts, followed by longer periods of writing, designing, coding and thinking. It’s more important to give employees quiet time than it is to cram them into an open office.
Litmus is a remote company with a collective 15,000 square feet of office space. That might sound crazy, but I believe offices afford some benefits that distributed work simply can’t replace.
We’ve had a remote-first mindset since the beginning, but we’ve also always had some kind of office space for meetings, collaboration and socializing. First it was a little corner of coworking space, then a small office and eventually a full-fledged HQ.
Read at Medium
How to use @supports in CSS to specify CSS that targets browsers capable of implementing a certain feature
So when do you want to use @supports? A Feature Query is a tool for bundling together CSS declarations so that they’ll run as a group under certain conditions. Use a Feature Query when you want to apply a mix of old and new CSS, but only when the new CSS is supported.
Let’s look at an example using the Initial Letter property. This new property initial-letter tells the browser to make the element in question bigger — like for a drop cap. Here, the first letter of the first word in a paragraph is being told to be the size of four lines of text. Fabulous. Oh, but I would also like to make that letter bold, and put a bit of margin on its right side, and hey, let’s make it a nice orange color. Cool.
We don’t want to change the color of the letter, or add a margin, or make it bold unless it’s also going to be made bigger by the Initial Letter property. We need a way to test and see whether or not the browser understands initial-letter, and only apply the change to color, weight, and margin if it does. Enter the Feature Query.
Read more from the source: hacks.mozilla.org
The better you understand the newest HTML and CSS, you’ll find that much of the code we write can be eliminated altogether
But it turns out the only surefire way to make performant Web Stuff is also to just write less. Minify? Okay. Compress? Well, yeah. Cache? Sounds technical. Flat out refuse to code something or include someone else’s code in the first place? Now you’re talking.
Read more from heydonworks.com
If you use target=”_blank” you need to also use rel=”noopener noreferrer”
Ben Halpern writes:
If you use the target=”_blank” attribute on a link, and do not accompany it with a rel=”noopener” attribute, you are leaving your users open to a very simple phishing attack.
When a website uses target=”_blank” on their links in order to open a new tab or window, that website gives the new page access to the existing window through the window.opener API, allowing it a few permissions. Some of these permissions are automatically negated by cross-domain restrictions, but window.location is fair game.
In order to restrict the behavior window.opener access, the original page needs to add a rel=”noopener” attribute to any link that has target=”_blank”. However, Firefox does not support that tag, so you should actually use rel=”noopener noreferrer” for full coverage. Some amount of prevention can be acheived through scripting, though, as observed with Twitter, this seems to fail on Safari.
Read more from The Practical Developer