Similar to how an HTML Web Component in popular parlance is a custom element which wraps standard HTML and applies interactivity to those child elements when rendered on a page, an Action Web Component performs a one-time operation when it’s rendered on the page and then (not always but typically) removes itself from the DOM upon completion. These actions don’t themselves have any visual appearance—they aren’t content, but commands.
Action Web Components offers an intriguing paradigm which is compatible with a near-infinite number of client/server topologies. It’s totally framework-independent, and save for a wee bit of client-side JavaScript, it’s totally language-independent as well.
It features a demo repo built on top of Astro and Alpine.js (and Pico CSS)…but as the examples show, you can use literally any backend or frontend technology. The techinique itself is strictly vanilla, and for folks already familar with libraries like Hotwired Turbo, you will feel right at home.
It’s been a while since I posted here about the Just a Spec podcast I’ve been producing along with my friend Ayush Newatia, so ICYMI, we’ve talked about a number of notable topics recently:
Pendulum Swings & 2023’s State of JS – Yes, the results are in, and we talk about them…but more broadly, our feelings about the state of web frameworks in our industry and the much-ballyhooed pendulum swing back to server-side rendering and HTML-first techniques (though the rate of change is perhaps not what we might wish for).
The Browser Wars & an Uneasy Peace – Remember Netscape Navigator? Remember Mosaic?? In this episode, we look back at the history of the web browser—touching on such memorable moments as the <blink> & <marquee> tags, DHTML with the launch of JavaScript, and the arrival of responsive design for mobile as well as desktop—while attempting to learn from history so that we’re not doomed to repeat it.
And Lo, There Was ARPANET (Baby Internet!) – How did the Internet first begin? Why was it developed at the Advanced Research Projects Agency? Where was it initially launched at the end of the 1960s? Is it pronounced r-OO-ter or r-OW-ter?? These and other hard-hitting questions are answered as we take a deep dive into the birth of humanity’s global computer network…with a dash of 90s nostalgia thrown in for good measure.
The idea that CSS should support conditionals within style rules has been around since time immemorial.
Well, it’s looking much more likely that we’ll soon see the day when we can if() the night away (I think I’m mixing my metaphors here), now that the CSS Working Group (CSSWG) has come to a consensus around adding if() to an upcoming CSS specification.
We’re likely to see things change as the CSSWG works on the feature. But as it currently stands, the idea seems to revolve around specifying a condition, and setting one of two declared styles — one as the “default” style, and one as the “updated” style when a match occurs.
And here’s a code example from Geoff of how that might look:
.element{background-color:/* If the style declares the following custom property: */if(style(--variant:success),var(--color-green-50),/* Matched condition */var(--color-blue-50);/* Default style */);}
If, like me, you gaze upon this and wonder to yourself: “Self, why does this seem to do the same thing as Conditional Style Queries?” …well, that’s because the concept is fairly similar! The difference is that a style query sits outside of selectors and rules. The above would have to be written like this:
.element{background-color:var(--color-blue-50);/* Default style */@containerstyle(--variant:success){background-color:var(--color-green-50);/* Updated style within query */}}
whereas if() can be written directly within a property value.
I can’t help but wonder though if there’s more that we might get out of conditionals than this example, because I think the syntax of style queries is just fine and perhaps even better if you have a large ruleset and want to keep variations on a theme grouped together.
Still, the idea of a keyword as powerful as if() landing in CSS is compelling. This will be a fun feature to track as they work out all the details of the spec.
Progressive enhancement is a design and development principle where we build in layers which automatically turn themselves on based on the browser’s capabilities. Enhancement layers are treated as off by default, resulting in a solid baseline experience that is designed to work for everyone.
We do this with a declarative approach which is already baked in to how the browser deals with HTML and CSS. For JavaScript — which is imperative — we only use it as an experience enhancer, rather than a requirement, which means only loading when the core elements of the page — HTML and CSS — are already providing a great user experience.
Andy goes on to stress the fact that this isn’t “just an anti-JavaScript thing, it’s a mental model rooted in iteration” and that’s exactly the approach I often recommend as well.
Web development isn’t HTML and CSS and JavaScript. It’s HTML, then CSS, then JavaScript. Get your semantics and your content right first. Then get your presentation right. Then get your client/server interactions right. Then integrate JavaScript behavior when and where it makes sense.
I’ll admit, I’m more tolerant of a “middling” baseline than some. I don’t think it’s a problem if the no-JS version of a form is much simpler than the JS version for example. The real issue is when no-JS means your entire experience simply breaks and the user is stuck. You never want your user to encounter a dead-end or a blank screen. That goes again the grain of the web, as they say.
HTML, then CSS, then JavaScript—that’s not just a recipe for UX success, it’s a methodology for building high-quality web applications with a robust architecture which will stand the test of time.
Alas, it doesn’t seem like much has happened on this front to spec out a solution since Adam’s original proposal in 2019. And there are likely a lot of technical hurdles to overcome before this could be a thing in browser engines.
But motion blur can do so much to improve the visual appearance of animations, especially on devices which don’t have a superfast refresh rate.
For example, this CSS animation demo looks incredibly impressive on my iPad Pro and its 120Hz refresh rate. Most of the movements and rotations of various shapes seem smooth, with even a bit of “natural” motion blur to my eyes.
However, viewing the same demo on my Mac (still in Safari!) and my LG display, the movements are much more choppy/jittery-looking and are almost distracting because of the lack of smoothness.
I suppose one answer could just be we should all have 120Hz displays and render animations that rapidly—no need for artificial motion blur! But I don’t think that’s likely to be a given any time soon.
At any rate, there are no doubt many other CSS specs more pressing which need attention rather than this one enhancement…nevertheless, I sure would appreciate it if I had it!
It’s only been since April of this year that we finally have full Popover API support in modern browsers.
There was once upon a time that we were going to get a brand-new <popover> element in HTML for this. Chromium was working on development as recently as September 2021 but reached a point where it was dropped in favor of a popover attribute instead. That seems to make the most sense given that any element can be a popover — we merely need to attach it to the attribute to enable it.
Lots of CodePen examples abound, as well as some nifty styling solutions.
The popover mechanism which eventually landed in browsers is way cool, and I’m itching to get a feature going where reaching for popover is the obvious call. Thankfully I’ll now have Geoff’s article as a primer to steer me in the right direction.
It seems weird to start a headline lowercased, but that’s how htmx likes to roll!
So version 2 is here, and by and large it seems largely focused around modernizing internals rather than offering specific new features, but nevertheless there are a few improvements. The two which stand out to me are better support for various bundling strategies if you use the NPM package (ESM is the most attractive of course), and a way to opt-into htmx’s functionality with shadow DOM in web components. It’s gratifying to see libraries like this take shadow DOM seriously.
As an aside, the State of JavaScript 2023 survey results just came out (I’m sure I’ll be sharing my general perspective on that in an upcoming episode of the Just a Spec Podcast), and I was intrigued to see htmx show up in the front-end frameworks section. Usage numbers aren’t high, but both interest and retention are. Clearly htmx is growing in popularity, as it has received a fair amount of buzz as of late.
Hopefully the philosophy and approach of htmx will foster increased attention on HTML-first development techniques, regardless of whether projects end up using htmx specifically.
It’s been a while since I posted here about the Just a Spec podcast I’ve been producing along with my friend Ayush Newatia, so ICYMI, we’ve talked about a number of notable topics recently:
Interop 2024 and the State of the Industry – in this episode we run through a very entertaining list of all the goodies being worked on by browser vendors as part of Interop 2024, as well as muse on the idea that perhaps the complexity of the web platform is just too damn high?
The Plumbing That Makes the Web Move – a meaty conversation all about the various levels of specifications and conventions which make the World-Wide Web go: from TCP/IP to HTTP to WebSockets and beyond.
This State of Affairs – where data lives, how to retrieve data, how to change data, how to track updates to data and provide feedback accordingly to the user…in other words, state.
Later this week we’ll be releasing our next episode covering the State of HTML 2023 survey results which are finally here, so if you don’t want to miss it, be sure to subscribe to the podcast.
The arrival of HTML5 and CSS3 way back in the day was a tremendous milestone in the history of the web. The importance of these updated specs cannot be overstated, as they were a true “reset” in the process of how the web evolves and how standards bodies work.
But here we are in 2024, and we’re still using…HTML5 and CSS3? Hmm. 🤔
We’ll save the HTML story for another day, but regarding CSS, clearly the spec has evolved by leaps and bounds in recent years and there’s an incredible amount of power available now that wasn’t available in the initial set of CSS3 features. So the CSS Next Community Grouphas decided to do something about that:
As CSS continues to evolve with new features and specifications, the blanket term “CSS3” has become insufficient and misleading. This RFC proposes the categorization of CSS properties into distinct groups, namely CSS3, CSS4, and CSS5, to better organize and facilitate understanding of the evolving CSS landscape. This categorization aims to improve adoption and ease of teaching, while not having a direct impact towards the CSS Working Group (CSSWG) operations or the Baseline initiative.
In other words, CSS4 & CSS5 are coming! But those are simply branding labels for sets of features which have emerged since the early days of CSS3. Presumably, this can only mean one thing: CSS6 is the future! What might we eventually see in CSS6? Let the wild speculation begin!
But in the meantime, if you have thoughts about how CSS4 / CSS5 should be categorized, check out this RFC by the CSS Next Community Group and offer your feedback.
It’s easy to get confused about how to work with element properties in JavaScript vs. how to work with element attributes in HTML. Jake Archibald to the rescue:
Most of the time, these distinctions don’t matter. I think it’s good that developers can have a long and happy career without caring about the differences between properties and attributes. But, if you need to dig down into the DOM at a lower level, it helps to know. Even if you feel you know the difference, maybe I’ll touch on a couple of details you hadn’t considered.
In this article, Jake talks about value types, serialization, reflection, case sensitivity, and a host of other interesting details. Some of this may be old hat if you’re used to working with vanilla JS, but for folks who are mainly used to operating under abstracted frontend frameworks, it may prove most enlightening. (And if you need to write/employ web components, this knowledge is a must!)