Dispatches From The Internets

Web Components Are Not the Future — They’re the Present

I really appreciated Cory LaViska’s take on #WebComponents here. Especially this bit:

You know what framework I want to use? I want a framework that aligns with the platform, not one that replaces it. I want a framework that values incremental innovation over user lock-in. I want a framework that says it’s OK to break things if it means making the Web a better place for everyone. Yes, that comes at a cost, but almost every good investment does, and I would argue that cost will be less expensive than learning a new framework and rebuilding buttons for the umpteenth time.

On CrowdStrike, dependencies, and building robust products on the web

I have no opinion on CrowdStrike as a company or service. I’ve never used their products. In fact, prior to the incident last week, I had only a passing familiarity with their name — likely from headlines in the tech press I’d scrolled past at some point in time. I now have a vague understanding of what they do, but that’s only based on what I learned about the cause of the incident. In reflecting on this unfortunate incident, I can’t help but think of the lesson it holds for web designers and developers.

Requirement Rules for Checkboxes

HTML checkboxes debuted as part of HTML 2.0 in 1995. Our ability to mark an individual checkbox as being required became part of the HTML5 spec that published in 2014. A decade later, we can still only make checkboxes required on a case-by-case basis. To overcome this limitation, I had created a jQuery plugin that allowed me to indicate that a user should choose a specific number of items from within a checkbox group. Yesterday I turned that plugin into a web component: form-required-checkboxes.

An even faster Microsoft Edge

Progressive enhancement for the win! This post from the Edge team demonstrates that producing markup directly rather than relying on JavaScript to do it for you is faster — even in the browser UI!

In this project, we built an entirely new markup-first architecture that minimizes the size of our bundles of code, and the amount of JavaScript code that runs during the initialization path of the UI. This new internal UI architecture is more modular, and we now rely on a repository of web components that are tuned for performance on modern web engines.  We also came up with a set of web platform patterns that allow us to ship new browser features that stay within our markup-first architecture and that use optimal web platform capabilities.

Link Rot and Digital Decay on Government, News and Other Webpages

A quarter of all webpages that existed at one point between 2013 and 2023 are no longer accessible, as of October 2023. In most cases, this is because an individual page was deleted or removed on an otherwise functional website.

Linkrot, especially in government and legal scenarios, is a tremendous problem, which is why we need services like the Internet Archive and Perma.cc. If you have the means, please consider supporting these, and similar, projects!

Why I Care Deeply About Web Accessibility And You Should Too

I agree with so much of this piece… especially the expansive view of accessibility that is inclusive of both the disability divide and the digital divide.

Great summary here:

[M]y passion for accessibility stems from experiencing accessibility barriers personally, observing their impact on others, and holding the conviction that technology should tear down divides - not erect new ones. I want to fulfill, and help you fulfill, the web’s promise of equal access and opportunity for everyone, regardless of circumstances. Digital accessibility should not be an accommodation but a fundamental right and prerequisite for technology to truly better humanity.