The following is a guest post by Mat Marquis. Mat has a important PSA for us regarding responsive images.
I don't want to bury the lede: if you're using a version of Picturefill from prior to 2.3.1, please update right away—update your /lib files, file an issue on your project, or run a quick npm update picturefill and let your mind be set at ease. There haven't been any breaking changes in any version of Picturefill 2, so you …
Cole Peters on the current pre-processor landscape and ditching Sass for PostCSS:
... here's what we gain by using PostCSS and cssnext, as compared to typical pre-processors:
extremely fast compilation times (in my example case, ~800% faster)
source code written in CSS, as defined by current and upcoming specs, which means:
no vendor-specific syntax (unless we write our own — be careful!), and thus:
source code that is immediately comprehensible to anyone with a half-decent understanding of CSS, and:
source code that is future-proof, portable, and easier to diagnose and debug
PostCSS and cssnext are certainly interesting projects to keep an eye on. It's pretty easy to devil's advocate on all the major points here though...
How fast does compiliation need to be? I don't even use libsass on most projects and speed never bothers me, and once I switch, that seems like that will be as fast as a build step would ever need to be.
We know that specs change. It happens all the time. Seems weird to base a syntax on a non-final spec. What happens when the spec changes? Do you change the language and let existing code break? How is that future-proof? Or support all past formats? Meaning the language isn't really based on future CSS, it's based on any experimental idea that was considered?
The opt-in add-on system encourages everyone's setup to be a little different. Doesn't that make it actually less portable? And harder to have community around?
Why is it more comprehensible? I'm not sure it's true that just because code might someday be a native part of the language it's automatically more understandable. From what I've heard from people, things like variables are a harder to wrap your head around than a standard Sass variable. Not to mention it's a bit confusing that it's impossible to polyfill the exact native behavior in a preprocessing step.
All interesting things to consider. Personally I like the idea of a preprocessor being more like a polyfill when possible, but I also think abstraction should be embraced not feared.
The following is a guest post by Amelia Bellamy-Royds. I've always enjoyed the "duotone" effect in photos. In Photoshop, you can create them by converting an image into grayscale mode, then into duotone. So the lights are "mapped" to one color, and the darks another. Not only does it look cool, but images with less colors are smaller in file size and thus good for performance. When I saw Amelia playing around with this programatically through SVG on CodePen, …
All this typographic power came with a cost: text-rendering: optimizeLegibility is slow—and by "slow" I mean that it can bog down an entire page, from initial render time to repaints. More than that, though, it's buggy: Android in particular has serious issues trying to render a page that uses optimizeLegibility heavily.
I propose that web developers everywhere start taking at least one day of their week to throttle their internet connections.
I'm guilty of mostly working under the most ideal possible conditions. The best hardware, the latest software, the fastest internet. Because I like it. And it's my job is to be productive. Once I even paid for redundant internet service at my house because I hated it so much when it went down or got slow.
But this isn't the environment that the sites we build are consumed in. By forcing ourselves into "worse" conditions, we may cultivate some empathy and do a better job with what we build.
What I need to fight is the feeling (assumption?) that I'll be less productive on those days.
Nick Walsh's reation to Simuai's article Nesting Components (which covers eight possibilities for the simple task of styling elements within other elements):
the very nature of CSS leaves many problems without an exact solution, and the right one for you won't always work for others. If you write, speak, or otherwise communicate about stylesheets, don't be afraid to offer an open-ended answer.
While I share his desire to nail down the best strategy (and I do have an opinion on the subject), I think it's actually more valuable to discuss how one might approach answering this question rather than what the actual answer may be.
Design is hard enough without scouring hundreds of blogs, countless social media accounts, and thousands of design sites just to keep up with what's changing. That's why the team at Webdesigner Depot created WebdesignerNews, a one-stop site for the very latest industry developments.
WebdesignerNews covers a range of topics, from vanilla web design to code demos, from branding to brand new apps. If it matters to our industry, you'll find it here. Even better, it is curated by humans. The team shortlists stories through social media response and then every single story is reviewed by industry experts. When you read WebdesignerNews, you can be confident that the stories you read are the ones that matter.
The following post is by Jason Witt, a regular around here on topics like WordPress development. This time Jason introduces us to a development prerequisite: the development environment itself. There are lots of ways to level up behind off-the-shelf app solutions, including scripting your own setups.…
I published a written post about this idea of the Server Side Mustard Cut. So if you're into reading and checking out code samples and stuff, that's the place for you. In this video I just walk through all that, explaining myself as we go.
I'll give the same caveat I have everywhere else I've introduced this: this may not be perfect for every site out there. In fact I think normal RWD stuff is generally better, up to …