A deep, deep dive into biomicry in digital design.
Nature is our outsourced research and development department. Observing problems solved by nature can help inform how we approach problems in digital design. Nature doesn’t like arbitrary features. It finds a way to shed unnecessary elements in advancing long-term goals over vast systems.
A really deep dive into the lang attribute, and the :lang() pseudo-class (hitherto unknown to me). This is all proving really useful for a little side project I’m working on.
A deep dive into the :focus pseudo-class and why it’s important.
One thing I gained a stronger awareness of (simply from working with checkboxes) is that it’s important to progressively enhance UI components, so that a fancy custom one is able to fall back to the default browser styles and functionality. This way, a user can still access the UI if JavaScript or CSS fail.
Rebuttals to the most oft-asked requests for browsers to change the way they handle CSS.
An excellent level-headed evaluation of styling and scripting form controls, weighing up the benefits and trade-offs. The more tightly you control the appearance, the less you get to benefit from the functionality (and accessibility) that the browser gives you for free …meaning you’ve now to got to work harder to replace it.
HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are they accessible?
A really interesting proposal from Lea that would allow CSS authors to make full use of selectors but without increasing specificity. Great thoughts in the comments too.
Vitaly’s been bitten with date-picker fever. Here’s his deep, deep, deep dive into one interface element.
Here’s a CSS file that will give you a bit more control over styling some form elements. The thinking behind the CSS for each element is explained nice and clearly.
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
This is a really great short explanation by Chris. I think it shows that the really power of JavaScript in the browser isn’t so much the language itself, but the DOM—the glue that ties the JavaScript to the HTML.
It reminds me of the old jQuery philosophy: find something and do stuff to it.
In a post called Side Effects in CSS that he wrote a while back, Philip Walton talks about different kinds of challenges in writing CSS:
There are two types of problems in CSS: cosmetic problems and architectural problems.
The cosmetic problems are solved by making something look the way you want it to. The architectural problems are trickier because they have more long-term effects—maintainability, modularity, encapsulation; all that tricky stuff. Philip goes on to say:
If I had to choose between hiring an amazing designer who could replicate even the most complicated visual challenges easily in code and someone who understood the nuances of predictable and maintainable CSS, I’d choose the latter in a heartbeat.
This resonates with something I noticed a while back while I was doing some code reviews. Most of the time when I’m analysing CSS and trying to figure out how “good” it is—and I know that’s very subjective—I’m concerned with what’s on the outside of the curly braces.
selector {
property: value;
}
The stuff inside the curly braces—the properties and values—that’s where the cosmetic problems get solved. It’s also the stuff that you can look up; I certainly don’t try to store all possible CSS properties and values in my head. It’s also easy to evaluate: Does it make the thing look like you want it to look? Yes? Good. It works.
The stuff outside the curly braces—the selectors—that’s harder to judge. It needs to be evaluated with lots of “what ifs”: What if this selects something you didn’t intend to? What if the markup changes? What if someone else writes some CSS that negates this?
I find it fascinating that most of the innovation in CSS from the browser makers and standards bodies arrives in the form of new properties and values—flexbox, grid, shapes, viewport units, and so on. Meanwhile there’s a whole other world of problems to be solved outside the curly braces. There’s not much that the browser makers or standards bodies can do to help us there. I think that’s why most of the really interesting ideas and thoughts around CSS in recent years have focused on that challenge.
An entertaining presentation from South By Southwest on the UI element of last resort.
It’s funny because it’s true.
Here’s a fun game to help practice those CSS selectors.
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
I somehow missed this when it was first published last Summer: a collection of twelve obscure CSS knowledge grenades.
You learn something new every day. I just learned twelve somethings.
A tool for getting instant visual feedback on your nth-child selectors. Considering that the way I figure out nth-child selectors is to try randomly changing numbers until it works, this should be quite useful for me.
A terrific bit of smart CSS thinking from Heydon Pickering.
You know he’s speaking at Responsive Day Out, right?
I’m quite intrigued by the thinking behind this CSS selector of Heydon’s.
* + * {
margin-top: 1.5em;
}
I should try it out and see how it feels.
This visual approach to demonstrating how CSS selectors work is really handy.