There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.
Naming things is hard. Naming things in standards, doubly so.
I really like the idea of a shared convention for styling web components with custom properties—feels like BEM meets microformats.
It went unnamed by Doris Lessing and Cormac McCarthy. William Gibson called it The Jackpot:
On the one hand, naming the crisis allows one to apprehend it, grasp it, fight back against it. On the other hand, no word can fully encompass it, and any term is necessarily a reduction—the essence of “it” or “change” is not any singular instance but rather their constancy.
Memoirs Of A Survivor, The Peripheral, Parable Of The Sower, New York 2140, The Road, Children Of Men, Station Eleven, Severance, The Rapture, Ridley Walker:
Fiction can portray ecologies, timescales, catastrophes, and forms of violence that may be otherwise invisible, or more to the point, unnameable. We will never grasp the pandemic in its entirety, just like we will never see the microbe responsible for it with the naked eye. But we can try to articulate how it has changed us—is changing us.
This is a terrific explanation of the concept of accessible names in HTML, written with verve and style!
Contrary to what you may think, naming an element involves neither a birth certificate nor the HTML
nameattribute. Thenameattribute is never directly exposed to the user, and is used only when submitting forms. Birth certificates have thus far been ignored by spec authors as a potential method for naming controls, but perhaps when web UI becomes sentient and self-propagating, we’ll need to revisit that.
Jen kicked off a fascinating thread here:
It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.
The level is discourse is impressively smart and civil.
Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.
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
fopenwhen you can writeopenFile. WritethrowValidationErrorand notthrowVE. Call that namefunctionand 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.