Treehouse: Grow your CSS skills. Land your dream job.

The End of Global CSS 

Mark Dalgleish:

Every selector has the potential to have unintended side effects by targeting unwanted elements or clashing with other selectors. More surprisingly, our selectors may even lose out in the global specificity war, ultimately having little or no effect on the page at all.

Any time we make a change to a CSS file, we need to carefully consider the global environment in which our styles will sit. No other front end technology requires so much discipline just to keep the code at a minimum level of maintainability.

Mark goes on to talk about his preprocessing solution. I can't speak to that, but I do find it interesting how this struggle has permeated front end development for...ever. Just think of these things: frames, iframes, namespacing selectors, careful naming methodologies, web components / shadow DOM, scoped CSS, all: initial;, future concepts - all things designed to combat the difficult "global" nature of CSS.

Please Update Picturefill

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 …

Read Article →

On writing real CSS (again) 

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.

Color Filters Can Turn Your Gray Skies Blue

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,

Read Article →

Decadent and Depraved 

Mat Marquis writing for BuzzFeed Bocoup:

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.

Throttled Thursdays 

Chris Ruppel:

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.

#139: Explaining the Server Side Mustard Cut

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 …

Watch Video →

More Blog Posts →