Fascinating look into the Web Animation API over at Smashing Magazine. Unfortunate to see we’re at very early stages:
It will be some time before this API is supported across the board. With half of browser makers waiting to see how developers will use it and most developers refusing to use a tool that isn’t widely supported, the API faces a chicken-and-egg scenario. However, in an on-stage conversation with Google’s Paul Kinlan at Fronteers, I suggested that, were the API to be fully supported in a closed and monetizable system for web apps, such as Google Play, developers would be able to safely use it in a walled garden until it reaches maturity and fuller support.
The smart slate of this post by Nicolas Bevacqua is how many different ways – YSlow, Webpagetest, Google PageSpeed – he tackles the same common problem: how do we automate our web performance measurements? Nicolas provides Gulp and Grunt plugins along with command line tools. The point here is simplification. Just start automating baseline performance in any way possible, as soon as possible. You’ll see a noticeable benefit for your web projects going forward.
Front end developer Mina Markham wrote a very nifty starter kit for new Sass projects. On some of my latest work I’ve been especially influenced by Mina’s use of a utilities folder – it’s an effective way to include self-generated functions, mixins, and other external sass libraries all in one shot.
Designer/developer/speaker Harry Roberts of CSS Wizardry isn’t generally a big extend fan:
Let me start by saying that I would generally advise never to use @extend at all. It is something of a Fool’s Gold: a feature with a lot of promise and twice as many caveats.
Compared to Harry I’m a Sass newbie, but I always found the extend call, much like nesting, mildly discomforting. This post helped me understand exactly.
A node.js based library tool to collect CSS statistics on any web site. It’s also easy to install via npm locally to run against any stylesheet you have. There’s even grunt and gulp integration; I can see this hooking into some sort of regression testing for my work in the long run to get a wider picture of how the code is evolving.
Developer Nicolas Bevacqua:
Meanwhile, we add tons of weight to our pages, levelling the field and making the experience in modern browsers worse as a result of attempting to make the experience in older browsers better. There’s a problem with this fallacy, though. People using older browsers are not expecting the newest features. They’re content with what they have. That’s the whole reason why they’re using an older browser in the first place. Instead of attempting to give those users a better experience (and usually failing miserably), you should enable features only if they’re currently available on the target browser, instead of creating hacks around those limitations.
I’ll let Google developer Andy Osmani’s description speak for itself:
A tweet-sized debugger for visualizing your CSS layouts. Outlines every DOM element on your page a random (valid) CSS hex color.
I’ve dabbled with the SVG image format over the years, but a serious flow has rarely stuck for a lot of my core work projects. Whenever I need a refresher, this guide by CSS Trick’s Chris Coyier is where I often end up. The “one stop” guide is both fairly exhaustive on both how to generate SVGs and how to implement on the web.
Designer Jay Freestone’s argument behind this very simple set of Sass mixins to generate a grid set:
Because you’re using Libsass, which (at the time of writing) rules out the two well established SASS based grid systems, Susy and Neat. Brockmann is designed to be super lightweight and incredibly easy to understand. It’s not a comprehensive system. It’s a set of transparent and reusable mixins that let you built out a pre-conceived grid quickly.