From the "I barely knew this was a thing and you can already play with it in browsers" files:
Motion paths allow authors to animate any graphical object along an author-specified path.
I suspect Chrome jumped on this because it's something that was only otherwise doable in SMIL, which they are ditching. I believe this is the first time the full path syntax has made it into CSS? (e.g. motion-path: path('M100,250 C 100,50 400,50 400,250');).
Chrome yanked position: sticky;, but Firefox and Safari still have it. Dudley Storey shows how to do the common sidebar pattern where a chunk follows you as you scroll down, but only when there is room for it. He does it in CSS, and the demo polyfills support with stickyfill.
Rachel Andrew reminds us that the power new CSS layout methods gives us could be used to form new anti-patterns:
With this power comes great responsibility. For just as it will be possible for a developer to start out with a beautifully semantic, well structured document and use Grid and Flexbox to meet the design requirements, it will be possible for them to stop caring about the document structure at all. Worse, I believe there will be a strong temptation, especially with Grid, to flatten out document structure in order that all elements become a child of the element with the Grid declared. Making layout simple, but at what cost?
Guil Hernandez introduces how easy sliders (with nice UX) will be with very simple HTML and CSS' brand new scroll-snap-* properties. CSS is moving fairly fast these days, with features like this moving from "never heard of it" to:
... browser support for CSS scroll snap points is limited to IE10+ and Firefox 39+. But it looks like Safari 9 will include support, and you can enable scroll snap points in Chrome Canary.
before you know it. The Chrome support means it will trickle to Opera and Android, and the Safari support means it will trickle to iOS, so pretty solid support across the board soon.
These are both things that you do to assets on your website (things like .css files and .js files). They are both things that reduce the size of the file, making it more efficient in crossing the network between servers and browsers. As in, good for performance. The network is the speed bottleneck of the web and reducing file size helps.
But these two things are distinctly different. If you didn't already know that, it's worth understanding.…
There is some sentiment out there that front end development isn't real development. It's a swaggering, trollish sentiment. Still, it's fun to puff our chests back sometimes. Let's try to put a point on why front end development is every bit as difficult and worthy of the title as any other subset.…
You know about responsive images. It's about the image syntax in HTML. If you give it the right information in the right syntax, you can get the browser to download just exactly the right image it needs, without giving it too much or too little image data. It's fantastic for performance.
You know that to get the most out of responsive images you should polyfill it with Picturefill. You download it, you include it on your page.