Chris Coyier writes:
Cool, right? But still, how actually useful is that? What are the major use cases? I think we’re still seeing those shake out.
Read more from the source: CSS-Tricks
On the Slack Engineering Blog, Felix Rieseberg writes:
In practice, switching the analysis and the compiler on without changing code means that TypeScript will immediately attempt to understand your code. It uses built-in types and type definitions available for third party dependencies to analyze the code’s flow, pointing out subtle errors that went previously unnoticed. Wherever TypeScript cannot understand your code, it will assume a special type called “any” and simply move on.
Read more from the source: Several People Are Coding
Last week, I wrote about how I created the bitsofcode logo animation with CSS. After that, it was suggested that I attempt a comparison between a CSS animation and the Web Animations API, so here it is! Introduction to the Web Animations API As with last week, I’ll start this
Read more from the source: bitsofcode
Read article by Jasper Cashmore
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 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