From the blog

✻ We kick things off this week with a look at what Chris thinks about when he visits a site for the first time:

What kind of stuff do you look at when digging into another site for the first time as designer/developer? What goes through your brain?

Layout, performance, typography, branding, and photography are just some of the things that Chris makes notes of.

✻ Next up, Chris has a sneaky tip for getting the original image from a data URL and it’s pretty simple: copy the data URL code, paste it into an img tag, watch it render on the screen and then drag and drop that image. 

The comments had more suggestions, like the fact that right-click save-as is more widely supported, and pasting the data URL right into the URL bar is even faster.

✻ Dylan Winn-Brown has written a great guest post about how to make zoomable background images, just like this:

✻ Let’s say you want to make a shareable URL, where the user clicks on an element with a link in it and the browser automatically selects all the text so that they can copy and paste that URL wherever they like. That’s what the user-select property is for, and Chris takes a dive into the who/what/why of force selecting text.

A good amount of people call "Bad UX!" and they are probably right. This CSS property totally enforces that all the text must be selected, while with JavaScript, you can force the text selection at first, then relax the behavior and let parts be selected if the user wants.

✻ Image Upload and Manipulation with React, is a post by Damon Bauer where he walks us through the process of designing and building a relatively common design pattern: an image upload component.

✻ Emerson This writes in to explain how to integrate with the Instragram API. There’s a lot to cover here, from understanding the restrictions that came into effect in June to using the API and exploring examples of what you can actually accomplish.

Those June API changes were a surprising kind of D-Day for a lot of sites. Some will be able to adjust, some will have to reevaluate what they are able to do now.

✻ We also made a new entry in the Almanac, this time for the writing-mode property which allows designers to align text vertically, like this:

It’s designed for languages that are naturally read in this format, such as Japanese, Chinese and Korean texts. However, English-speaking folks like us can use this trick to style text without transforms or absolute positioning.


What we’ve been reading, listening and watching

Remy Sharp writes some smart things about the difference between var, let and const in relation to JavaScript and when you might want to use them.

* * *

Organising code in React can be a complicated business, so thankfully Brent Jackson has written some of this thoughts regarding patterns for style composition.

* * *

webpack-dashboard is a neat project that makes the webpack code output in your console much more legible:

* * *

Jake Archibald describes the performance benefits of rel=noopener.

* * *

Here’s a big ol’ list of stuff that Rich Harris wishes he had known before he started working with service workers.

* * *

Paul Ford, the co-founder of web design agency Postlight, outlined his thoughts on Google’s AMP project:

It’s easy to imagine that there are two Googles: The good one, in five-toed-shoes and a T-shirt, riding a bicycle, that believes in an open web and is super-nerdy and builds great stuff, and the bad one, in a suit and wingtips, that jets from office to office and shuts down Google Reader and controls a huge amount of the world’s technology infrastructure in the interest of its advertising business. But there is, of course, only one Google, in competition with Facebook, Amazon, Apple, Verizon, and everyone else—and AMP is something they spearhead and control.

Tip of the week

Last week we mentioned a neat keyboard shortcut for Chrome’s DevTools, but one of the least talked about features must be the device toolbar. This is a neat tool that lets you test responsive designs and breakpoints right in the browser without having to change the size of the viewport:

This is accessible by having DevTools open and typing:

cmd + shift + m
 
What have you learnt this week?

Chris Coyier: I'm pretty sure we're supposed to say "ES2015" and not "ES6". Or. hm. Are we? There is a whole conversation about it here from a few years ago, but it doesn't seem to have a strong ending. I think the confusion is rooted in the fact that the spec is called "ECMAScript® 2015 Language Specification" but it's also the "6th Edition". So both abbreviations make sense. Both abbreviations are certainly "out there". 

My best understanding in poking around and reading about this is that the goal is to get to a point where there is a yearly release schedule for new versions of JavaScript. Then it would make good sense to name the releases after the current year. But that hasn't been proven out yet. A second year of it hasn't even happened yet. It seems safer to stick with the version numbers like ES6 and ES7 and such if the yearly releases fail. 

Looks like Babel largely refers to it as "es2015". Ben McCormick made a call for his blog:

Going forward in this blog, I'll be referring to the recent ECMAScript version as ES6 (since that is how it is best known by most developers), next years spec as ES2016 (since that will be what it is called the whole way through its standardization process, unlike ES6/ES2015) 

We have a post on learning the new features on CSS-Tricks by Ryan Christiani. He originally submitted the article using ES6 and I changed it to ES2015 thinking that was more right, but I'm less and less sure. There's another similar article by Deepak Grover that goes with ES6. 

Whatever. I don't have that strong of opinions on it so I'll just keep skirting the issue until it shakes out more. I hope it gets more clear.


Until next time!
Team CSS-Tricks

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list