Link tags: components

210

sparkline

HTML with Superpowers - daverupert.com

A great talk from Dave on web components:

I think if you were using Web Components before 2020 you were an early adopter and you probably have some scars to show for it. But in 2021, now that all modern browsers support Web Components, I think they’re worth investigating. They have one superpower that no other JavaScript framework offers called the Shadow DOM which is both powerful but frustrating. But another superpower — the power I’m most excited about — is that you can use them standalone without any frameworks, build tools, or package managers.

The talk makes a callback to my talk Building from a few years back. I like that. It feels like a long thoughtful converstation.

Using the platform

Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:

  • use custom elements (for modular HTML without frameworks)
  • use the in-browser package manager (for JavaScript packages without build tools)
  • match pages with files (to avoid routing and simplify architecture)
  • stick to standards (to avoid obsolescence and framework fatigue)

Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!

Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.

I have a special disdain for beginner JavaScript tutorials that have you run create-react-app as the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.

Collecting my thoughts about notation and user interfaces (Interconnected)

HTML sits on a boundary between the machine, the creator, and the reader.

Tabs in HTML?

I’ve been having some really interesting chats with Brian about tabs, markup, progressive enhancement and accessibility. Here’s a braindump of his current thinking which is well worth perusing.

Introducing Astro: Ship Less JavaScript

In Astro, you compose your website using UI components from your favorite JavaScript web framework (React, Svelte, Vue, etc). Astro renders your entire site to static HTML during the build. The result is a fully static website with all JavaScript removed from the final page.

YES!

When a component needs some JavaScript, Astro only loads that one component (and any dependencies). The rest of your site continues to exist as static, lightweight HTML.

That’s the way to do it! Make the default what’s best for users (unlike most JavaScript frameworks that prioritise developer convenience at the expense of the end user experience).

This is a tagline I can get behind:

Ship Less JavaScript

Faster Integration with Web Components - Cloud Four

It’s good to hear stories like this—makes me feel like the slow-burn of the theoretical benefits of web components is starting to spark and flame up.

Container Queries in Web Components | Max Böck

The point of this post is to show how nicely container queries can play with web components, but I want to also point out how nice the design of the web component is here: instead of just using an empty custom element, Max uses progressive enhancement to elevate the markup within the custom element.

Simple things are complicated: making a show password option - Technology in government

This is a great deep dive into a single component, a password toggle in this case. It shows how assumptions are challenged and different circumstances are considered in order to make it truly resilient.

davatron5000/awesome-standalones

A curated list of awesome framework-agnostic standalone web components.

Home · castastrophe/wc-theming-standards Wiki

I really like the idea of a shared convention for styling web components with custom properties—feels like BEM meets microformats.

Open UI and implicit parent/child relationships in HTML – Eric Bailey

I remember discussing this with Tantek years ago:

There are a few elements who need to be placed inside of another specific element in order to function properly.

If I recall, he was considering writing “HTML: The Good Parts”.

Anyway, I can relate to what Eric is saying here about web components. My take is that web components give developers a power that previous only browser makers had. That’s very liberating, but it should come with a commensurate weight of responsibility. I fear that we will see this power wielded without sufficient responsibility.

A Complete Guide To Accessible Front-End Components — Smashing Magazine

Vitaly has rounded up a whole load of accessibility posts. I think I’ve linked to most of them at some point, but it’s great to have them all gathered together in one place.

Building Dark Mode | Product Blog • Sentry

Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:

Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.

So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.

I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.

For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.

Good, Better, Best: Untangling The Complex World Of Accessible Patterns — Smashing Magazine

I really like the approach that Carie takes here. Instead of pointing to specific patterns to use, she provides a framework for evaluating technology. Solutions come and go but this kind of critical thinking is a long-lasting skill.

How Web Components Are Used at GitHub and Salesforce – The New Stack

I’m very taken with Github’s tab-container element—this is exactly how I think web components should be designed!

Van11y: Accessibility and Vanilla JavaScript - ES2015

Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.

The 2020 Design Systems Survey by Sparkbox

These survey results show that creating and maintaining an impactful design system comes with challenges such as planning a clear strategy, managing changes to the system, and fostering design system adoption across the organization. Yet the long-lasting value of a mature design system—like collaboration and better communication—awaits after the hard work of overcoming these challenges is done.

SydCSS 7th Birthday with Ethan Marcotte - YouTube

A great talk by Ethan called The Design Systems Between Us.

SydCSS 7th Birthday with Ethan Marcotte

The failed promise of Web Components – Lea Verou

A spot-on summary of where we’ve ended up with web components.

Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.

But then…

Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.

Alas, that’s true. Lea wonders how this can be fixed:

I’m not sure if this is a design issue, or a documentation issue.

I worry that is a cultural issue.

Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.

A walkthrough of our design system and how we got here | Kyan

It all started at Patterns Day…

(Note: you’ll probably need to use Reader mode to avoid taxing your eyes reading this—the colour contrast …doesn’t.)