Isn’t it strange we’ve never had a “State of HTML” survey before? CSS gets one. Lots of other web technologies get one. But not poor ol’ HTML. Until now!
Lea Verou headed up the project to design and launch a new survey for HTML, and says it was “likely the most ambitious Devographics survey to date”. The benefits of taking the survey include:
Survey results are used by browsers to prioritize roadmaps…
Learn about new and upcoming features you may have missed
Get a personalized score and see how you compare to other respondents
Learn about the latest trends in the ecosystem and what other developers are focusing on
I took the survey and was surprised (pleasantly so I might add) that I learned about a ton of stuff I wasn’t aware of! I suspect that will be the case for many. Hopefully if a lot of people take the survey, we’ll gain greater insight into what folks don’t already know about HTML and what they’re hoping for in the future of the spec.
Manuel Matuzović once again hits it out of the park with a comprehensive yet concise guide to creating and using accessible web components (and some of the possible pitfalls, particularly when talking about “cross-root” ARIA / shadow DOM). As Manuel explains:
I specialize in HTML and CSS, but I also write JS. Especially in the last year or so, I wrote quite a lot of JavaScript because we decided to port the front end of one of my clients to web components.
When I first learned about web components, I had a lot of questions, especially regarding accessibility. While I found answers to many of them, I didn’t know everything I would’ve wanted to know. I wish I had a catalog of all the essential questions and answers when I started. That’s why I decided to design this post in a Q&A format. I’ll ask a question regarding the accessibility of web components, and then I’ll answer it.
As an industry, we associate reactivity with frameworks, but you can learn a lot by implementing reactivity in pure JavaScript. We can mix and match these patterns to wire behavior to data changes.
Learning core patterns with pure JavaScript will lead to less code and better performance in your web apps, no matter what tool or framework you use.
Amen to that!
There are so many great examples here, from how to work with custom events in and even outside of the DOM, how to use observables and proxies, a basic implementation of signals and effects (they’re so rad), MutationObserver, and a whole lot more. I recommend grabbing your favorite beverage and settling down to read all the way through!
I think we’re fast coming up to the peek and inevitable bust of the “generative AI” hype cycle, but in the meantime, we still must suffer from the hyperbole and the very real harm these tools (and often their champions) can cause.
Not everyone is claiming that their AI tool is particularly innovative. But like most things involving AI right now, we are seeing some pretty wild claims.
This is where we are and it’s where we’ve been before. We’ve been in this same scenario with design tools prior to this current AI craze; tools that claimed designers could build responsive, accessible websites straight from the design or WYSIWYG editor. And maybe we got a little close to that, as long as your website was mostly text, images, and links to other pages that were just text and images. Even in those “close” scenarios, you’d probably still be left with out of order headings and unlabelled navigation elements.
And, your developer would wonder how on earth are they going to keep design-generated code maintained and on par with what they actually end up shipping in production.
So here we are again.
Every few years, this idea that website production, design work, and content development can all just be “automated” for the most part rears its ugly head. What’s particularly grating is when we see these sorts of claims come from vendors who ostensibly are there to help web developers get their job done.
It’s like when Uber kept trumpeting about their program to develop self-driving taxis—when the literal function of Uber is to help HUMANS find work driving people around. Way to go throwing your own workforce under the bus (a self-driving bus, presumably).
Anyway, I really appreciated this read, and the main TL;DR takeaway is: if your “production-grade” generated code isn’t fully accessible…well, it ain’t production-grade. Full stop.
That was the question on everyone’s minds as we gathered under the auspices of Zach Leatherman’s excellent community leadership to discuss the present state of the Jamstack and where we might go from here. Participants were:
I look forward to further zhuzhing in the months ahead (as it seemed very much like everyone would love to keep the conversation going!), and it’s refreshing to see folks with lots of history and Opinions™ in this space converse in a respectful and optimistic fashion.
It really feels like for the longest time, you couldn’t do anything to derive new colors from a base color using vanilla CSS. Sure, you could use a preprocessor. But, gosh, we want our code to run in a browser! And work throughout a design system with user-customizable variable tokens!
Thankfully, the future has finally arrived this year in the form of color-mix(), and to help us get a sense of what’s possible, Cory LaViska has the lowdown:
Let’s build a button that accepts one color and calculates its hover and focus states automatically. For this experiment, we’ll use CSS Custom Properties, color-mix(), and OKLCH to ensure that tints and shades are perceptually uniform.
Zach Leatherman of Eleventy fame recently asked folks on Mastodon to share their favorite inspirational blog posts which had made a huge impact on their careers as web developers. He then compiled many of the top hits into a permanent archive called Educational Sensational Inspirational Foundational.
The historical significance of some of this material cannot be overstated, so it’s definitely worth your while to peruse the archive and catch up on ~25 years of web development. You might find a few familiar titles, or be introduced to entirely new (old? new again?) ideas.
According to State of CSS, this award goes to “the technology with the highest percentage of returning users”, with runners-up being CSS Modules and UnoCSS. Congratulations to Adam Argyle and crew! 🎉 (If you haven’t yet tried out Open Props, I can unequivocally recommend it.)
I have a slew of thoughts about the survey results and will be talking a lot about them here, over at The Spicy Web, and on the Just a Spec Podcast. I see lots of encouraging signs here on numerous fronts, and to offer a quick summary before the deep dives to come:
I tend to cringe whenever I hear of another article “dealing” with shadow DOM, because for whatever reason it continues to feel like some freaky frothy topic in the world of web component architecture. But Manuel Matuzović has been a solid and respected author & speaker for some time in the world of web development—CSS & accessibility in particular—so when he says something, I listen.
Manuel writes:
I summarized my pros and cons of Shadow DOM and style encapsulation. Please note that I’m writing this from the perspective of someone who, first and foremost, cares about accessibility and well-structured, semantic HTML. For me, JavaScript is an optional add-on and not the foundation of my code. That implies that I might not have to solve the same problems as others who primarily work with JS-heavy websites. That might also explain why my list of cons is longer than the list of pros.
I appreciate this, as I too deeply care about semantic HTML as well as progressive enhancement. And I’ll admit, I have shied away from using shadow DOM on projects where I was principally working with server-rendered HTML and frameworks which aren’t even JavaScript-based such as Ruby on Rails. This is fast-changing though with the arrival of Declarative Shadow DOM (DSD), which is easy enough to polyfill in a mere few lines of code in Firefox (the only remaining holdout) that I consider it ready for prime time today.
Manuel also writes:
I understand that most of the cons described in this post are not critical issues, and there are ways to work around them.
Well said. And this is where so many of the conversations I tend to have with folks who are shadow DOM skeptics get tripped up. They’ll present a very real list of cons much like Manuel has written up, and when I say “sure, but there are workarounds for some things and other things might not even be an issue on your particular project”, somehow that’s bad and therefore I’m bad. 😅
Here’s the deal: shadow DOM is part of the web platform. It is! It’s not going anywhere. It’s being used all across the industry for a wide variety of use cases. And it’s only going to get better, not worse, as the spec and the browser implementations improve. So it’s worth it for people to invest their time and resources into utilizing what it’s good at and finding that sweet spot of best practices and workarounds which is what we have to do with every technology. (I’m thinking I might write a tongue-in-cheek “Pros & Cons of Light DOM” article at some point because, believe me, it’s not all peaches ‘n’ cream over there.)
At any rate, I think this is a great article and one I’ll happily reference when debates come up in the future.
You did a fabulous job outlining a lot of the good and the bad of shadow DOM and really offering a “features list” for spec authors/browsers IMHO. Like, can’t we just fix all this stuff? That’d be pretty awesome! For me, the good still outweighs the bad and I’m “shadow DOM by default” at this stage in the game—even architecting frameworks and new best practices around it (and especially DSD).
It’s also worth mentioning that design system components which use shadow DOM can actually offer improved accessibility. For example, the Shoelace component library puts a lot of effort into assigning all the appropriate ARIA roles and attributes (even reflecting live reactivity), and thus sometimes when I replace some custom markup I’ve hacked together with a Shoelace component, a11y on the page gets better.
This whole article by Kevin Pennekamp, Going back to CSS-only after years of SCSS, is a fabulous read, but I’d like to zero in particularly on a really cool idea I haven’t seen explored much elsewhere, and that is what Kevin calls “class utilities”.
Not to be confused with utility classes, class utilities only set CSS custom properties (aka CSS variables) which are then utilized by a specific layout or component-type class. In Kevin’s example, he has a .tiles class which sets up a simple CSS grid layout. Then he has classes which are prefixed with double-dashes to reinforce that they only set a variable, for example --gap-0, --gap-1, etc. These classes look something like this:
.--gap-1{--layout-gap:var(--token-space-1);}
Because .tiles uses the --layout-gap variable to set the grid gap, a class utility like this will influence that gap—essentially just shorthanding class="tiles" style="--layout-gap: var(--token-space-1)" down to class="tiles --gap-1".
Truth be told, I’m still personally in favor of using attributes over classes whenever possible, and I’m also in favor of using semantic token names. Thus this technique could also be accomplished like so:
for use via class="tiles" layout-gap="small" or even <layout-tiles layout-gap="small"> if you want to custom-element it.
But for folks who are used to utility classes already and would appreciate a soft landing onto more modern vanilla CSS ways of doing things, this is a very neat trick.