I really like the way that the thinking here is tied back to Bert Bos’s original design principles for CSS.
This is a deep dive into the future of CSS layout—make a cup of tea and settle in for some good nerdiness!
A proposal to retroactively classify additions to CSS in order to put more meat on the bones of the term “modern CSS”.
Rachel responds to Jen’s recent post with the counter-argument; why masonry should be separate from grid.
I’m not entirely convinced. We heard performance issues as a reason why we could never have container queries or :has, but here we are. And the syntax for a separate masonry spec borrows so heavily from grid that it smells of redundancy.
More thoughts on naming web components.
I’ve been deep-diving into HTML web components over the past few weeks. I decided to refactor the JavaScript on The Session to use custom elements wherever it made sense.
I really enjoyed doing this, even though the end result for users is exactly the same as before. This was one of those refactors that was for me, and also for future me. The front-end codebase looks a lot more understandable and therefore maintainable.
Most of the JavaScript on The Session is good ol’ DOM scripting. Listen for events; when an event happens, make some update to some element. It’s the kind of stuff we might have used jQuery for in the past.
Chris invoked Betteridge’s law of headlines recently by asking Will Web Components replace React and Vue? I agree with his assessment. The reactivity you get with full-on frameworks isn’t something that web components offer. But I do think web components can replace jQuery and other approaches to scripting the DOM.
I’ve written about my preferred way to do DOM scripting: element.target.closest. One of the advantages to that approach is that even if the DOM gets updated—perhaps via Ajax—the event listening will still work.
Well, this is exactly the kind of thing that custom elements take care of for you. The connectedCallback method gets fired whenever an instance of the custom element is added to the document, regardless of whether that’s in the initial page load or later in an Ajax update.
So my client-side scripting style has updated over time:
event.target.closest.None of these progressions were particularly ground-breaking or allowed me to do anything I couldn’t do previously. But each progression improved the resilience and maintainability of my code.
Like Chris, I’m using web components to progressively enhance what’s already in the markup. In fact, looking at the code that Chris is sharing, I think we may be writing some very similar web components!
A few patterns have emerged for me…
Naming things is famously hard. Every time you make a new custom element you have to give it a name that includes a hyphen. I settled on the convention of using the first part of the name to echo the element being enhanced.
If I’m adding an enhancement to a button element, I’ll wrap it in a custom element that starts with button-. I’ve now got custom elements like button-geolocate, button-confirm, button-clipboard and so on.
Likewise if the custom element is enhancing a link, it will begin with a-. If it’s enhancing a form, it will begin with form-.
The name of the custom element tells me how it’s expected to be used. If I find myself wrapping a div with button-geolocate I shouldn’t be surprised when it doesn’t work.
You can use any attributes you want on a web component. You made up the name of the custom element and you can make up the names of the attributes too.
I’m a little nervous about this. What if HTML ends up with a new global attribute in the future that clashes with something I’ve invented? It’s unlikely but it still makes me wary.
So I use data- attributes. I’ve already got a hyphen in the name of my custom element, so it makes sense to have hyphens in my attributes too. And by using data- attributes, the browser gives me automatic reflection of the value in the dataset property.
Instead of getting a value with this.getAttribute('maximum') I get to use this.dataset.maximum. Nice and neat.
My favourite web components aren’t all-singing, all-dancing powerhouses. Rather they do one thing, often a very simple thing.
Here are some examples:
aria-collapsable for toggling the display of one element when you click on another.play-button for adding a play button to an audio or video element.ajax-form for sending a form via Ajax instead of a full page refresh.user-avatar for adding a tooltip to an image.table-saw for making tables responsive.All of those are HTML web components in that they extend your existing markup rather than JavaScript web components that are used to replace HTML. All of those are also unambitious by design. They each do one thing and one thing only.
But what if my web component needs to do two things?
I make two web components.
The beauty of custom elements is that they can be used just like regular HTML elements. And the beauty of HTML is that it’s composable.
What if you’ve got some text that you want to be a level-three heading and also a link? You don’t bemoan the lack of an element that does both things. You wrap an a element in an h3 element.
The same goes for custom elements. If I find myself adding multiple behaviours to a single custom element, I stop and ask myself if this should be multiple custom elements instead.
Take some of those button- elements I mentioned earlier. One of them copies text to the clipboard, button-clipboard. Another throws up a confirmation dialog to complete an action, button-confirm. Suppose I want users to confirm when they’re copying something to their clipboard (not a realistic example, I admit). I don’t have to create a new hybrid web component. Instead I wrap the button in the two existing custom elements.
Rather than having a few powerful web components, I like having lots of simple web components. The power comes with how they’re combined. Like Unix pipes. And it has the added benefit of stopping my code getting too complex and hard to understand.
Okay, so I’ve broken all of my behavioural enhancements down into single-responsibility web components. But what if one web component needs to have awareness of something that happens in another web component?
Here’s an example from The Session: the results page when you search for sessions in London.
There’s a map. That’s one web component. There’s a list of locations. That’s another web component. There are links for traversing backwards and forwards through the locations via Ajax. Those links are in web components too.
I want the map to update when the list of locations changes. Where should that logic live? How do I get the list of locations to communicate with the map?
When a list of locations is added to the document, it emits a custom event that bubbles all the way up. In fact, that’s all this component does.
You can call the event anything you want. It could be a newLocations event. That event is dispatched in the connectedCallback of the component.
Meanwhile in the map component, an event listener listens for any newLocations events on the document. When that event handler is triggered, the map updates.
The web component that lists locations has no idea that there’s a map on the same page. It doesn’t need to. It just needs to dispatch its event, no questions asked.
There’s nothing specific to web components here. Event-driven programming is a tried and tested approach. It’s just a little easier to do thanks to the connectedCallback method.
I’m documenting all this here as a snapshot of my current thinking on HTML web components when it comes to:
I may well end up changing my approach again in the future. For now though, these ideas are serving me well.
This is a wonderful in-depth article by Jen, with lots of great demos.
She makes a very strong case for masonry layouts being part of the grid spec (I’m convinced!). If you have strong feelings one way or the other, get involved
A handy resource from Paul:
Find inspiration for naming things – be that HTML classes, CSS properties or JavaScript functions – using these lists of useful words.
Today’s AI promoters are trying to have it both ways: They insist that AI is crossing a profound boundary into untrodden territory with unfathomable risks. But they also define AI so broadly as to include almost any large-scale, statistically-driven computer program.
Under this definition, everything from the Google search engine to the iPhone’s face-recognition unlocking tool to the Facebook newsfeed algorithm is already “AI-driven” — and has been for years.
I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?
That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.
This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.
Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:
/things/things/new/things/searchAnd then an idividual item can be found at:
things/IDThat’s all nice and predictable and the naming of the URLs matches what you’d expect to find:
Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:
When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.
Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.
So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.
Here’s my dilemma: if I update the label, should I also update the URL structure?
Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.
If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.
Is that okay? Am I the only one that would be bothered by that?
I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:
/discography/discography/new/discography/search/discography/IDIt doesn’t seem as tidy as:
/recordings/recordings/new/recordings/search/recordings/IDBut if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.
I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.
City of Women encourages Londoners to take a second glance at places we might once have taken for granted by reimagining the iconic Underground map.
I love everything about this …except that there’s no Rosalind Franklin station.
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.