Open UI
An interesting project that will research and document the language used across different design systems to name similar components.
An interesting project that will research and document the language used across different design systems to name similar components.
This post absolutely nails what’s special about CSS …and why supersmart programmers might have trouble wrapping their head around it:
Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times, and can therefore be understood as concrete instructions as to how a program should execute.
CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default.
Max goes on to encapsulate years of valuable CSS learnings into some short and snappy pieces of advices:
No matter what your level of CSS knowledge, this post has something for you—highly recommended!
Don’t write
fopen
when you can writeopenFile
. WritethrowValidationError
and notthrowVE
. Call that namefunction
and notfct
. That’s German naming convention. Do this and your readers will appreciate it.
Chris makes the very good point that the J in JAMstack isn’t nearly as important as the static hosting part.
I also pointed out to Phil recently that the M (markup) is far more important than the J (JavaScript), which is there to enhance the M. So I suggested that the acronym be updated accordingly:
MAJstack!
This is my maj.
Some good advice from Hidde, based on his recent talk Six ways to make your site more accessible.
A few common gotchas when using BEM, and how to deal with them.
I think we often focus on designing or building an element, without researching the other elements it should connect to—without understanding the system it lives in.
Ethan emphasises the importance of making a shared language the heart of any design system. I heartily agree!
This isn’t new thinking, mind: folks like Alla Kholmatova and Charlotte Jackson have been talking about this for ages. (And in doing so, they’ve massively influenced how I think about modular, pattern-driven design.)
AMP is a symptom that someone, somewhere, thinks the web is failing so badly (so slow, so unresponsive) for a portion of the world that they want to take all the content and package it back up in a sterile, un-webby, branded box. That makes me so sad. PWAs, to me, are a potential treatment.
Breaking down programming tasks into smaller chunks …and naming things.
I’ll take a piece of paper and write the function names I’m going to implement. Or I’ll do it directly in my code editor, with real functions or comments.
It allows you to focus on one problem at a time. When you’re writing those function names, you are thinking about what the code should be doing. When you’re implementing the functions, you are thinking about how the code should do it.
A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
The video of Charlotte’s excellent pattern library talk that she presented yesterday in Berlin.
Here’s an epic brain dump by Vitaly on the challenges of putting together a pattern library and then maintaining it.
Sacrificing consistency for usability is fine. A slightly open-ended, inconsistent but heavily used pattern library is better than a perfectly consistent pattern library that is never used.
The Museum of Wi-Fi exists to preserve these vestiges of our neighbourhood battlefields.
Some are brilliantly smart, some are just purely gross. They all belong in the museum.
Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.
There is one truism that has been constant throughout my career on the web, and it’s this: naming things is hard.
Trent talks about the strategies out there for naming things. He makes specific mention of Atomic Design, which as Brad is always at pains to point out, is just one way of naming things: atoms, molecules, organisms, etc.
In some situations, having that pre-made vocabulary is perfect. In other situations, I’ve seen it cause all sorts of problems. It all depends on the project and the people.
Personally, I like the vocabulary to emerge from the domain knowledge of the people on the project. Building a newspaper website? Use journalism-related terms. Making a website about bicycles? Use bike-related terms.
Most importantly, make the naming process a collaborative exercise, as outlined by Alla and Charlotte.
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.
A really terrific article from Dan on building pattern libraries. In summary:
There are some really good insights here into getting just the right level of abstraction for a component—not too tightly tied to a specific visual display, but also not too tightly tied to a specific kind of content type:
When thinking about patterns, content strategists are primarily thinking about Content patterns, designers are primarily thinking about Display patterns, and front-end developers are responsible for bringing the two together.
(And it’s great to see Charlotte’s excellent article get a shout-out in the “Related reading” section at the end,)