Tagged “resilience”
One web component to rule them all? (on Filament Group, Inc.)
Scott Jehl has taken a refreshingly Progressive Enhancement -centric look at Web Components.
this pattern provides a nice hook for adding progressive enhancements to already-meaningful HTML contained in these custom elements, leaving them resilient in the case of of script loading failures and allowing the page to start rendering before the JS happens to run.
He goes further and creates a factory for creating Web Components which allows adding to a single element many small behavioural script enhancements that may or may not relate to each other.
There are also some great notes on polyfilling and the performance upgrade provided by lifecycle callbacks.
And Scott’s wc-experiments repo contains some interesting demos.
Progressively enhanced JavaScript In Real Life
Over the last couple of days I’ve witnessed a good example of progressive enhancement “In Real Life”. And I think it’s good to log and share these validations of web development best practices when they happen so that their benefits can be seen as real rather than theoretical.
A few days ago I noticed that the search function on my website wasn’t working optimally. As usual, I’d click the navigation link “Search” then some JavaScript would reveal a search input and set keyboard focus to it, prompting me to enter a search term. Normally, the JavaScript would then “look ahead” as I type characters, searching the website for matching content and presenting (directly underneath) a list of search result links to choose from.
The problem was that although the search input was appearing, the search result suggestions were no longer appearing as I typed.
Fortunately, back when I built the feature I had just read Phil Hawksworth’s Adding Search to a Jamstack site which begins by creating a non-JavaScript baseline using a standard form which submits to Google Search (scoped to your website), passing as search query the search term you just typed. This is how I built mine, too.
So, just yesterday at work I was reviewing a PR which prompted me to search for a specific article on my website by using the term “aria-label”. And although the enhanced search wasn’t working, the baseline search functionally was there to deliver me to a Google search result page (site:https://fuzzylogic.me/ aria-label) with the exact article I needed appearing top of the search results. Not a rolls-royce experience, but perfectly serviceable!
Why had the enhanced search solution failed? It was because the .json file which is the data source for the lookahead search had at some point allowed in a weird character and become malformed. And although the site’s JS was otherwise fine, this malformed data file was preventing the enhanced search from working.
JavaScript is brittle and fails for many reasons and in many ways, making it different from the rest of the stack. Added to that there’s the “unavailable until loaded” aspect, or as Jake Archibald put it:
all your users are non-JS while they’re downloading your JS.
The best practices that we as web developers have built up for years are not just theoretical. Go watch a screen reader user browse the web if you want proof that providing descriptive link text rather than “click here”, or employing headings and good document structure, or describing images properly with alt attributes are worthwhile endeavours. Those users depend on those good practices.
Likewise, JavaScript will fail to be available on ocassion, so building a baseline no-JS solution will ensure that when it does, the show still goes on.
Thoughts on inline JavaScript event handlers in the <head>
I’ve been thinking about Scott Jehl’s “simplest way to load external CSS asynchronously” technique. I’m interested in its use of an inline (onload) event handler for running JavaScript-based enhancements in the <head>, in the context of some broader ruminations on how best to progressively enhance UI elements with JavaScript (for example adding toggle show/hide) without causing layout jank.
One really interesting aspect of using inline event handlers to apply enhancements was highlighted by Chris Ferdinandi today: as JavaScript goes, it’s pretty resilient.
Because we’re dealing with an HTML element directly in the document, and because the relevant JS is inline on that element and not dependent on any external files, the only case where the JS won’t run is if someone has JS completely turned off – a sub-1% proportion. The other typical JavaScript resilience pitfalls – such as network connections timing out, CDN failure and JS errors elsewhere blocking your code from running – simply don’t apply here.
See all tags.