CSS-Tricks

Articles by
Chris Coyier

Founder, writer, designer, spam-deleter, email personality

Twitter · Forums · chriscoyier.net

CSS Selectors are Conditional Statements

# By Chris Coyier 
.foo {

}

Programmatically, is:

if (element has a class name of "foo") {

}

Descendent selectors are && logic and commas are ||. It just gets more complicated from there, with things like combinators and pseudo selectors. Just look at all the ways styles can cascade.

Jeremy Keith:

If you find you can’t select something in the CSS, that’s a sign that you probably need to add another class name to the HTML. The complexity is confined to the markup in order to keep the CSS more straightforward, modular, and maintainable.

The Software We Pay For

# By Chris Coyier

We did a Web Developer Economics series a few years ago, where we looked at the various costs of being a web developer:

  1. Web Developer Economics: One-Off Software Costs
  2. Web Developer Economics: Hardware Costs
  3. Web Developer Economics: Monthly Service Costs
  4. Web Developer Economics: The Wrapup

I'm sure some of that software and hardware has changed since then, but the spirit is the same. It costs money to have the things you need to do this job.

I just wrote a similar article, but from the perspective of a business paying for the software it needs. That link is to Medium, but it was posted on the CodePen blog originally. Just giving that a shot to see what all the hubbub about Medium is about.

It’s not about the device.

# By Chris Coyier

Ever have that, "Ugighgk, another device to support?!" feeling? Like, perhaps when you heard that wrist devices have browsers? Ethan's latest post is about that.

Personally, the Apple Watch is interesting to me not because it’s a watch. Rather, it’s interesting to me because it’s a smaller-than-normal touchscreen attached to a cellular antenna, and one that’s not necessarily on the most reliable connection. It helps me look past the device, and to think about how someone will interact with my work under those conditions. Once I do that, I can start to design accordingly.

The post is nice reminder to revisit the idea of responsive design in our heads. The seismic shifts in how we consume the web is why web design and development shifted this way. So, enough thinking about specific devices. Instead, let's make our approaches responsive and flexible, then new devices will come along. They will inevitably slot themselves right in without us having to re-design or re-code anything.

Sayonara Edge

# By Chris Coyier

Sounds like Edge is going to spin down EdgeHTML, the engine that powers edge, and go with Chromium. It's not entirely clear as I write whether the browser will still be called Edge or not. Opera did this same thing in 2013. We'll surely be seeing much more information about this directly from Microsoft, and hot takes galore.

Probably three major categories of hot-take:

  1. Hallelujah, I dislike supporting Edge, this will make my job easier and make the web better for users.
  2. Yikes, this is bad for the web. Browser engine diversity is a very good thing for the web. See Rachel Nabors The Ecological Impact of Browser Diversity.
  3. This might be good in that combining forces makes a stronger team. If many teams each build a 50-meter tower, maybe working together they can build a 100-meter tower.

I'm not quite sure what to think yet, except that it's a good reminder that businesses will be businesses.

Too Much Accessibility

# By Chris Coyier

I like to blog little veins of thought as I see them. We recently linked to an article by Facundo Corradini calling out a tweet of ours where we used an <em></em> where we probably should have used an <i></i>.

Bruce Lawson checks if screen readers are the victims of these semantic mistakes...

Whenever I read “some browsers” or “some screenreaders”, I always ask “but which ones?”, as did Ilya Streltsyn, who asked me “what is the current state of the text-level semantics in HTML reality?”

Léonie Watson to the rescue! Over Twitter, Watters wrote

Most are capable of reporting these things on demand, but do not as standard. So you don’t hear the text/font characteristics being announced as you read, but you can query a character/word etc. to discover its characteristics. This is based on the visual presentation of the text though, rather than through any recognition of the elements themselves

Which I suppose is to say that if you're really fretting about screen readers misinterpreting the nuanced usage of your semantic emphasis... you can relax on that one.

(more…)

Blue Beanie Day 2018

# By Chris Coyier

Another year!

I feel the same this year as I have in the past. Web standards, as an overall idea, has entirely taken hold and won the day. That's worth celebrating, as the web would be kind of a joke without them. So now, our job is to uphold them. We need to cry foul when we see a browser go rogue and ship an API outside the standards process. That version of competition is what could lead the web back to a dark place where we're creating browser-specific versions. That becomes painful, we stop doing it, and slowly, the web loses.

DevTools for Designers

# By Chris Coyier

This is such an interesting conversation thread that keeps popping up year after year. The idea is that there could (and perhaps should) be in-browser tooling that helps web designers do their job. This tooling already exists to some degree. Let's check in on perspectives from a wide array of people and companies who have shared thoughts on this topic.

(more…)

Front-End Developers Have to Manage the Loading Experience

# By Chris Coyier

Web performance is a huge complicated topic. There are metrics like total requests, page weight, time to glass, time to interactive, first input delay, etc. There are things to think about like asynchronous requests, render blocking, and priority downloading. We often talk about performance budgets and performance culture.

How that first document comes down from the server is a hot topic. That is where most back-end related performance talk enters the picture. It gives rise to architectures like the JAMstack, where gosh, at least we don't have to worry about index.html being slow.

Images have a performance story all to themselves (formats! responsive images!). Fonts also (FOUT'n'friends!). CSS also (talk about render blocking!). Service workers can be involved at every level. And, of course, JavaScript is perhaps the most talked about villain of performance. All of this is balanced with perhaps the most important general performance concept: perceived performance. Front-end developers already have a ton of stuff we're responsible for regarding performance. 80% is the generally quoted number and that sounds about right to me.

For a moment, let's assume we're going to build a site and we're not going to server-side render it. Instead, we're going to load an empty document and kick off data API calls as quickly as we can, then render the site with that data. Not a terribly rare scenario these days. As you might imagine, >we now have another major concern: handling the loading experience.

(more…)

icon-anchoricon-closeicon-emailicon-linkicon-logo-staricon-menuicon-nav-guideicon-searchicon-staricon-tag