I heard from quite a few people who were excited about the Web Component Engineering course but missed the Thanksgiving sale window. So, as we wrap up the year and head into a new one, I’m running one more sale as a bit of year-end / new-year “good tidings.”

From now through the first week of the new year, you can get 25% off my Web Component Engineering course when you use the discount code GOODTIDINGS25 at checkout.

About the Course

Web Component Engineering is a self-paced, in-depth course on modern UI engineering through the lens of Web Components and core Web Standards. It’s designed to help you move beyond framework-only knowledge and really understand the Web Platform you’re building on.

You’ll get a deep dive into topics like:

• Using and authoring Web Components in real applications
• Working directly with DOM APIs instead of only through frameworks and abstractions
• Modern CSS for robust, scalable UI systems (including Shadow DOM styling, container queries, and more)
• Accessibility as a first-class concern in component design
• Form-associated custom elements and integrating components with real forms
• Design systems, tokens, and component libraries built on Web Components
• Application architecture, routing, and app shells with Web Components
• Tools and libraries like Storybook, Playwright, Lit, FAST, and others you’ll use in production

The course is trusted by engineers at top companies and is designed to be the “missing manual” for serious UI engineers who want to master the modern Web Platform.

What You Get

When you enroll, you get access to:

• 13 modules with over 170 lessons, fully self-paced
• A custom interactive learning app that lets you follow along, run demos, and experiment in the browser with no setup
• Runnable examples, downloadable notes, and reference materials
• A Certificate of Completion you can share with your team or manager

Whether you’re building a design system, maintaining a complex front-end, or just want to understand what’s really possible with modern Web Standards, this is designed to meet you where you are and push you to the next level.

Sale Details

• Discount: 25% off
• Code: GOODTIDINGS25
• Valid through: The end of the first week of the new year
• Course: https://bluespire.com/course/web-component-engineering/

If you missed the Thanksgiving window, or you’ve been on the fence, this is another chance to invest in your skills and deepen your understanding of the Web Platform.

Thanks for being part of the Web community, and here’s to a great year of building better UIs with Web Standards.

I’m wrapping up the year with a little thank-you to everyone who cares about the Web Platform and modern UI engineering.

From now through November 30, you can get 25% off my Web Component Engineering course when you use the discount code GRATITUDE25 at checkout.

👉 Visit the course page.

About the Course

The Web Component Engineering course is a self-paced, in-depth course that teaches modern UI engineering through the lens of Web Components and core Web Standards. It’s designed to help you move beyond “framework-only” knowledge and really understand the platform you’re building on.

What It Covers

• Using and authoring Web Components
• DOM APIs and working directly with the DOM
• Modern CSS for real-world UI systems
• Accessibility baked into component design
• Form-associated custom elements and handling real forms
• Design systems, tokens, and component libraries
• Application architecture with Web Components
• Modern tools and libraries (Storybook, Playwright, Lit, FAST, and more)

What You Get

• 13 modules with over 170 videos, fully self-paced
• An interactive in-browser learning app (no local setup required)
• Runnable demos, slides, and downloadable notes
• A certificate of completion you can share with your team or manager

Whether you’re building a design system, maintaining a complex front-end application, or just want to understand what’s really possible with modern Web Standards, this course is designed to meet you where you are and then push you to the next level.

Thanksgiving Sale Details

• Discount: 25% off
• Code: GRATITUDE25
• Valid through: November 30
• Course page: https://bluespire.com/course/web-component-engineering/

If you’ve been waiting for the right moment to dive into Web Components and modern UI engineering, now’s the time to enroll.

Happy Thanksgiving, and thanks for being part of the Web community. 🙏

Framework monoculture is a psychology problem as much as a tech problem. When one approach becomes “how things are done,” we unconsciously defend it even when standards would give us a healthier, more interoperable ecosystem. Psychologists call this reflex System Justification. Naming it helps us steer toward a standards-first future without turning the discussion into a framework war.

I’ve been sitting with this idea for a while, especially in React-centric conversations where familiarity is often treated as proof. Over the past year, a run of blog posts, conference talks, YouTube videos, and a few interactions with standards-oriented groups nudged me to finally write this down. This isn’t a takedown of any project or community; it’s a look at a human reflex many of us share when our tools become our identity.

My aim here is simple: explain the psychology (briefly), show how it maps to front-end habits, name the quiet costs of monoculture, and offer a pragmatic path toward a standards-first posture that still meets teams where they are.

System Justification

In the 1990s, social psychologists (notably John Jost and Mahzarin Banaji) described System Justification Theory (SJT) as the idea that people are motivated to see existing arrangements as legitimate, fair, and desirable even when those arrangements have obvious downsides or are downright harmful. In other words, it’s a matter of familiarity. Individuals and groups defend the status quo because it reduces uncertainty, protects identity, and keeps members aligned with their groups.

SJT highlights three motives that drive this defense:

• Epistemic: The comfort of being right.
  Clear rules and familiar patterns feel safer than ambiguity.
• Existential: The comfort of safety.
  It’s less frightening to believe the world you’ve invested in is basically true, good, and beautiful.
• Relational: The comfort of acceptance.
  Agreeing with your community keeps you inside the circle.

If you scan history, you’ll spot the same pattern over and over again:

• Early resistance to handwashing in medicine (the “Semmelweis reflex”).
• Decades of public minimization around tobacco harms.
• Long, loud debates over seatbelts and other safety standards.
• “Separate but equal” as a rationale for inequality masked as order.
• And many more (see appendix)…

None of these debates were purely about evidence; they were about identity, habit, and social standing.

Now translate that to the web. When a single toolset becomes the default, we don’t just prefer it, we build narratives that justify it. And that’s when a tool quietly becomes a gate or even a destructive force.

Subtle Reflex

System justification doesn’t announce itself. It shows up as common-sense statements, subtle status signals, and “everyone knows” assumptions:

• “This is how real apps are built.”
  The present method masquerades as natural law. Alternatives become “experimental,” “academic,” “toy,” or “fringe” even when they align with widely adopted standards.
• “Standards are idealistic; we ship.”
  Shipping is good. But this framing sneaks in a false tradeoff: standards are painted as purity projects rather than the bedrock that lets different teams, tools, and runtimes collaborate without friction.
• “Our audience is modern, so the costs don’t matter.”
  Hidden costs (bundle weight, device inequity, hydration overhead, portability constraints) get discounted as someone else’s problem. Often that tends to be users with older devices, spotty networks, or that require assistive technology.
• “Everyone on the team knows this stack.”
  Familiarity becomes proof of superiority. The fact that a community is large and helpful (a real benefit!) mutates into the claim that alternatives are unworthy.
• “If it were better, we’d already be doing it.”
  This is injunctification: confusing “what is” with “what should be.” At this point, the comfort of the status quo has become its own argument.

Behind these lines are those three motives I mentioned before: the desire to be right, safe, and accepted. Notice how much of the rhetoric protects identity (“we’re experts in X”) and group cohesion (“this is who we are”) rather than debating technical merit or user impact.

Quiet Costs

When one approach becomes the unexamined default, you don’t just get consistency, you also accumulate opportunity costs that are easy to miss in the moment:

• Slower standards adoption.
  If your core primitives exist only inside a single framework abstraction, other surfaces can’t reuse them without translation. That discourages cross-project collaboration and fragments the commonality that standards provide.
• Less innovation.
  Monoculture makes it harder to try architecture patterns that assume standards first (progressive enhancement, islands, simpler render paths). The conversation shifts from “what does the platform already give us?” to “how do we shoehorn the platform into our preselected model?”
• Reduced portability and value.
  Work tightly bound to one frontend framework is harder to move between products, partners, and future platforms. Today’s convenience turns into tomorrow’s migration tax.
• Fragility in supply chains.
  When large chunks of your UI or data flow depend on a specific ecosystem, you inherit its release cadence, deprecations, and politics. If that ecosystem’s priorities diverge from yours, you feel it.
• Talent pipeline brittleness.
  Hiring “only X framework” narrows who can contribute. Onboarding becomes about memorizing a house style instead of leveraging the web and public contracts. That’s great until you need people who didn’t grow up inside the same assumptions.
• User-shifted costs.
  Developer convenience is meaningful, but when it consistently beats standards-based reuse and progressive delivery, users pay in bandwidth, energy, accessibility, and responsiveness.

These rarely show up in a single PR, but they accumulate as costly drift.

Standards First

This isn’t a call to abandon frameworks. It’s a call to re-center standards as the foundation and treat frameworks as adapters that improve ergonomics where helpful. Think of it as a “shift left” of front-end.

• Publish primitives as standard-compliant units.
  Think clear public contracts: documented interfaces, events, and styling hooks that any framework can build on.
• Offer adapters for popular stacks.
  Keep the ergonomic sugar where teams want it without making the framework adapter the source of truth.
• Document the contract, not the adapter.
  Make the standard interface the canonical reference. Adapters will come and go but the contract should endure.
• Measure portability.
  Track reuse across projects/frameworks, the thinness of adapters (no duplicated logic), and the performance and accessibility characteristics of the standard layer.

The goal isn’t to win a framework debate. It’s to make your work lean, portable, and future friendly.

Objections…Answered

Here are a few common objections I’ve heard over the years, each accompanied by a brief reply.

• “Developer experience will get worse.”
  Good DX belongs at the edges. Keep rich types, ergonomics, and editor integrations in your adapters, but anchor correctness, semantics, and accessibility in the standards-level contract. You’re moving convenience, not sacrificing it.
• “Standards move too slowly.”
  Stability is a feature at the primitive layer. You can still innovate rapidly in composition, architecture, and tooling. Just don’t fork the base. When standards evolve, your contract benefits everywhere at once instead of patch-by-patch in each framework.
• “This will slow shipping.”
  The first few primitives take discipline. After that, reuse pays compound interest especially across multiple apps or surfaces. If you measure total delivery (including maintenance and cross-team portability), standards-first usually wins on time.
• “No one is asking for this.”
  Portability is like backups: ignored until it isn’t. Partners, acquisitions, re-platforming, and new surfaces make “runs anywhere” suddenly priceless. You don’t get that value by accident, only by design.
• “Our team doesn’t know how to do it.”
  Start small. Write one simple, well-documented contract and a pair of adapters. Share the recipe. Most of the skill is in writing clear interfaces and testing behavior, skills your team already has.
• “We’ll split the community.”
  Standards-first is a unifier. It invites more communities to participate because the core is neutral. The conversation shifts from “which framework is allowed?” to “how do we make the contract great?”
• “The performance gains aren’t guaranteed.”
  True…and that’s why you measure user-visible outcomes (latency to first interaction, responsiveness, energy use) at the standard layer. If an adapter adds weight, it’s localized and replaceable; the base remains lean.
• “Security and compliance will be harder.”
  The opposite. A single, well-documented contract simplifies auditing, testing, and threat modeling. You assess the primitive once and reuse the assurance everywhere, instead of auditing n copies of the same idea.

Default Defense

Here are some practical ways to guard against a default framework monoculture, whether on your keyboard, in a design review, or during a meeting.

Spot the Tell

Listen for “comfort” language. It’s a red flag that should prompt us to pause and examine. Here are a few common patterns:

• Injunctification
  “That’s just how it’s done.” or “Real apps do X.”
• Appeal to Familiarity
  “Everyone on our team knows this already.”
• Status Through Popularity
  “The ecosystem is huge, so it must be the best.”
• Minimizing User Costs
  “Our users are on modern devices anyway.”
• False Dichotomy
  “Standards are idealistic; we ship.”
• Sunk Cost
  “We’ve already invested too much to change now.”
• Exaggeration
  “If we don’t do it this way, everything else breaks.”
• Security Blanket
  “Compliance will hate anything new.”
• Preemptive Defeat
  “If this were better, we’d already be doing it.”

When you hear one of these, ask: Is this defending identity or describing reality?

Ask Yourself

Use the following as a mental checklist to help yourself steer clear of the default trap:

• Counterfactual
  Would I still believe this if my preferred framework/tool didn’t exist?
• User-first
  Where do users pay for this choice (latency, accessibility, bandwidth, portability)?
• Contract
  Can I articulate the standard-level contract independent of any framework?
• Opportunity
  What future paths does this decision close? What does it keep open?
• Evidence
  Do we have a measured outcome, or just a story that feels safe?
• Reversibility
  If we’re wrong, how hard is this to undo?
• Portability
  Could a team using another framework consume this work without needing to rewrite it?

Reframe It

Try to turn status-quo defenses into standards-first questions without picking a fight.

• From: “This is how we build apps.”
  To: “What’s the smallest standard contract here, and how would frameworks map to it?”
• From: “DX will tank if we move away from X.”
  To: “How do we keep great DX at the edges while grounding behavior in a standard interface?”
• From: “No one’s asking for portability.”
  To: “Which upcoming surfaces/partners would benefit if this were portable by default?”
• From: “Security won’t allow it.”
  To: “Can we write the contract so security can audit it once and bless all adapters?”
• From: “It’s too late to change.”
  To: “What thin seam lets us pilot a standard-level primitive alongside what we have?”
• From: “This pattern is proven; everyone uses it.”
  To: “Popularity does not equal portability. Can we prove the contract stands on its own?”
• From: “Performance is fine on modern phones.”
  To: “Let’s test on slow hardware and unreliable networks. If the framework adapter adds cost, can the standard base stay lean?”

Final Thoughts

This isn’t about shaming individual or team preferences. It’s about noticing when preference hardens into dogma, and gently pivoting the conversation back to standards, contracts, and users.

Frameworks come and go; the web remains. If we can notice the human urge to defend “how we do things” simply because it’s how we do things, we can aim that energy at building a stronger foundation: standards first, adapters as needed, and design always.

If you maintain a design system, library, or toolkit, consider publishing your primitives to a clear, standards-oriented contract and inviting framework and tool adapter authors to the table. That’s not anti-framework; it’s a pro-web approach that widens the path for everyone.

Appendix: Historical SJT Examples

A few examples of SJT in recent history.

Medicine and Science

• Germ theory and asepsis (post-Semmelweis)
  Early pushback defended established routines and senior authority.
  Tell: “We’ve always done it this way; outcomes are fine.”
• Stomach ulcers (H. pylori)
  The “stress/spice” story persisted long after bacterial evidence emerged. Tell: Familiar theory felt truer than revision.
• Bloodletting as standard care
  Centuries of inertial legitimacy despite mounting counterevidence.
  Tell: Tradition = truth.
• Lobotomy in psychiatry
  Entrenched as “last resort” therapy before antipsychotics, long past ethical/clinical doubts.
  Tell: Harm reframed as necessary tradeoff.

Public Health and Safety

• Smoking in public spaces
  “Personal freedom” and “ventilation is enough” narratives resisted smoke-free rules.
  Tell: Costs shifted to bystanders, normalized as choice.
• Leaded gasoline
  Industry reassurances delayed phase-out despite environmental/health data.
  Tell: System seen as safe because it’s ubiquitous.
• Asbestos
  “Proper handling makes it fine” slowed bans.
  Tell: Diffusion of responsibility (“we follow the guidelines”).
• Seatbelts, airbags, helmets
  “Restrictive,” “unsafe in rare cases,” “I’m a careful driver.”
  Tell: Anecdotes outrank data.

Environment and Energy

• CFCs and the ozone hole
  Early minimization framed changes as economically catastrophic.
  Tell: “Not proven” + “too costly” = defend status quo.
• Climate change denialism
  Identity, jobs, and regional economies tie to existing energy systems. Tell: Evidence filtered through group belonging.

Civil Rights and Social Policy

• “Separate but equal”
  Inequality rationalized as order and tradition.
  Tell: Stability over disruption.
• Child labor
  Framed as “builds character” and economic necessity before reforms. Tell: Harms recast as virtues.

Technology and Work

• “Office-only” culture
  Remote work dismissed as unserious or unproductive.
  Tell: Familiar practice = proof; counterexamples waved away.
• Proprietary file formats
  “Ecosystem integration” used to justify lock-in over open standards.
  Tell: Convenience for insiders outweighs portability for everyone.

Today, I’m excited to share the launch of some new opportunities I’m making available to individuals and companies. I’ve put together a unique set of coaching, mentoring, and consulting options covering several recurring needs I’ve seen in the industry over the last few years. In addition to my web standards training, I’m now offering everything from one-on-one career coaching and technical mentoring to corporate OSPO development, and Web Architecture consulting. Read on to learn more about these options, along with where you or your employer can sign up.

I look forward to working with you soon!

Options for Individuals

I have a pretty non-traditional career background. I have no degree in computer science or software engineering, nor have I attended any boot camps or technical schools. I taught myself to program in the 80s but ended up studying music at university. It wasn’t until the early 2000s that I took my first job writing code as a part time member of a small company’s software R&D team.

It’s been 20 years since then. In that time, I’ve had many challenging, growth experiences, including working as a Principal Architect at Microsoft and working as GEICO’s only Technical Fellow, providing technical leadership to the entire engineering organization, a group consisting of over 4,000 engineers, directors, and VPs.

I learned a lot of things the hard way. I’ve made my share of mistakes. But I’ve also discovered non-traditional routes that enabled me to innovate and provide unique, high value to the teams and companies I’ve worked for. It would have been a heck of a lot easier with a coach or a mentor…or just someone I could throw ideas at to get feedback. I had this in the earliest days of my career, something I wouldn’t trade for the world, but missed it later on and found that many others were missing this too.

As a result, I’ve decided to offer a set of services targeted directly at individuals in the tech industry. You may be looking for a job, trying to figure out or advance your career, want to grow technically, or just need a technical “wall” to throw ideas and questions at. Or perhaps you are a manager who wants to find a mentor for a promising individual on your team. Here are a few opportunities you can sign up for today:

• Resume Review — As a hiring manager and technical interviewer throughout my career, I’ve looked at a lot of resumes. I often find that folks don’t know how to present their career in this form. So, I’m offering a service designed to help. The Resume Review service involves a thorough review of your resume, followed by a one-one-one meeting where we’ll discuss what you can do to improve the resume itself as well as your marketability for the future. Sign up here.
• Mock Technical and General Interviews — Interviews are a huge source of anxiety for many people. As a musician and public speaker, one of the most important lessons I learned is the importance of practice. It generally results in greater confidence, better performance, and less anxiety. This has led me to offer a Mock Interview service. This is a one-one-one experience that starts with an intense, real-world, 45-minute mock interview and concludes with 15 minutes of feedback. This is a great opportunity to get some practice in, and also learn how you can improve. I’m offering technical interview as well as general/soft-skills options.
• Job Prep Bundles — Since sending out resumes and doing interviews often go hand-in-hand, I’ve got a bundle that provides a discount to those who want to combine the Resume Review with either a Mock Technical or General Interview. Sign up for the technical prep bundle here, or the general bundle here.
• Career Coaching — I’ve had the opportunity to wear a lot of different hats in my career: engineer, architect, manager, PM, consultant, founder, advisor, teacher, etc. I know how difficult it can be figuring out what you want to do, and more so, coming up with a plan that will get you to where you want to be. It’s easy to misjudge opportunities or even oneself along the way. So, I’m offering a Career Coaching opportunity. It’s a subscription that includes two one-on-one meetings per month, dedicated to helping you grow in your career and pursue the best path for you. Subscribe here.
• Technical Mentoring — Early in my career, I had a close friend who I also became coworkers with. While I had been writing code for many years on my own, I had no experience working in the profession, and was a bit aimless in my learning and growth. This person mentored me, resulting in an amazing work relationship that spurred both of us on in what would become one of the greatest periods of technical growth in my career. Having had that experience, I’ve decided to offer a subscription that includes two one-on-one meetings per month, dedicated to helping people pursue their technical growth and learning. You can subscribe here.
• Ask Me Anything — Sometimes you just need a second opinion. You may be the only dev at your company, or you may be a leader who oversees thousands of people, but rarely has the opportunity for deep review. “Ask Me Anything” is exactly what it sounds like. It’s a way to put some time on my calendar to discuss whatever is on your mind for whatever reason. You can schedule time here.

The above options are all available today. Just follow the links to sign-up, pay, and schedule your meetings. I’m looking forward to getting to know you and helping you along your journey. 😃

Options for Teams

There are a lot of challenges that engineering organizations and teams have to face today. They tend to be quite different from the challenges that individuals face. So, I’m offering a few unique options targeted directly at teams and engineering decision-makers, based on common areas of struggle and growth I’ve seen over the last several years. I’ve had particular success helping companies in these areas, so I’m now making these services officially available more broadly:

• Outsourced Technical Interview — Not every company has a large or mature engineering team, making the task of hiring talented individuals all the more challenging. This kind of bootstrapping problem isn’t uncommon. As a result, many companies don’t have the people that can even perform an effective technical interview for the position they are trying to hire for. To help with that, I’m offering a sort of “outsourced” technical interview. If you’ve got a promising candidate, but no one to perform a comprehensive technical interview as part of your hiring process, I can do that part for you. You can schedule the interview here.
• Web Architecture Consulting — The Web continues to evolve, constantly presenting new possibilities for companies to better serve their customers. The rate of change can make it difficult for leaders to find time to understand how new web technologies apply to them, or how they can be leveraged in a practical way to improve their systems. Those that follow my blog or read my posts on social media won’t be surprised that I’m now officially offering consulting specifically geared towards helping companies better leverage the full power of the web to build the best solutions possible for their customers and business. You can book a consulting engagement here.
• Inner/Open-Source Program Guidance — There’s a lot more to open-source than browsing GitHub or installing a package in your project. As companies grow in this area, not only do their needs and challenges expand, but also their potential to do great good, or unfortunately, harm. Building a healthy and responsible open-source program and culture isn’t easy. I’ve helped many companies in these areas over the years, from the basics of understanding how to use open-source, to the challenge of building a successful Open-Source Programs Office (OSPO). Wherever your company is on this journey, there’s probably opportunity for growth and improvement, and I’d be happy to help you explore what’s next. You can go here to book OSPO consulting.
• Engineering Organization and Culture Strategy — A healthy culture and an engineering organization that’s effectively structured are two factors that I’ve seen make or break products and whole business units. I’ve had the privilege of working for some amazing leaders who got this right…as well as in some of the most toxic and broken situations. Over the years, I’ve aggregated the best of my experiences and used them to develop a set of values, principles, and practices, designed to help leaders and organizations mature. If you’re struggling in this area, I’d love to help you work through the challenges before you.
• Fractional Technical Fellow — For those companies who need a senior technical leader for a longer period of time, I’m offering a monthly retainer option. This option would provide a certain number of hours per week, usable for whatever is most pressing. This could be hiring, architecture, open-sourced guidance, cultural strategy, etc. Essentially any of the above, mixed and matched as needed.

Like the options for individuals, you can follow the links above to immediately book time. However, since many businesses don’t handle purchases in that way, please also feel free to reach out via the official email channel: consulting@bluespire.com

More To Come…

I’m hopeful that the options I’m launching today will be a help to both individuals and companies who are looking to continue in their professional, technical, or organizational growth. And please keep a lookout for a couple additional opportunities I’ve got coming soon as well, focusing on ways to support both the Web Standards and Open-Source work my company is involved with.

Cheers!

Recently, I wrote about how to use global styles in Shadow DOM. It turned out to be relatively simple, using just a tiny bit of JavaScript. In this post, I’d like to focus in on a similar but slightly different scenario, specifically with Declarative Shadow DOM (DSD).

The Problem

As a reminder, using DSD, we can generate HTML on the server that sets up client-side encapsulation not just for HTML rendering but also for the styles related to that HTML. Here’s a simple “hello world” example:

<hello-world>
  <template shadowrootmode="open">
    <style>
      :host { display: block; color: red; }
    </style>
    Hello World
  </template>
</hello-world>

In the above HTML, <hello-world>serves as our DSD "host". Inside of the host element, we have a <template> element with the shadowrootmode="open" attribute. This does not define a template. This declaratively creates a shadow root that is attached to the host. Then, inside the shadow root, we have a <style> element with some styles that target the host itself. We also have the text "Hello World".

What if we want to have three instances of our <hello-world> tag? That would look like this:

<hello-world>
  <template shadowrootmode="open">
    <style>
      :host { display: block; color: red; }
    </style>
    Hello World
  </template>
</hello-world>
<hello-world>
  <template shadowrootmode="open">
    <style>
      :host { display: block; color: red; }
    </style>
    Hello World
  </template>
</hello-world>
<hello-world>
  <template shadowrootmode="open">
    <style>
      :host { display: block; color: red; }
    </style>
    Hello World
  </template>
</hello-world>

Now, we can begin to see the problem: duplication. The HTML duplication is something we’re used to. Every server-only HTML solution handles components in this way and has for over two decades. What we’re not used to seeing is the duplicated CSS. Usually, that would be extracted to a stylesheet and then linked. But we can’t do this in DSD without a flash of un-styled content (FOUC). And we don’t want that. While the above duplication is not a big deal, due to its small amount of CSS, we need a solution to this problem for any real-world use of DSD.

So, how can we declaratively encapsulate our HTML and styles while avoiding both style duplication and FOUC?

NOTE: If you are interested in potentially eliminating the duplicate HTML, that’s something I hope will be possible in the future as well, via HTML Modules, Declarative Custom Elements, and other future declarative features.

Interested in learning more about DSD, Web Components, and other related Web Standards? Check out the Web Component Engineering course I created, trusted by giants such as Adobe, Microsoft, Progress, and Reddit. Group rates for teams and PPP pricing available upon request.

The Solution

One solution to this problem is to create a custom element, its sole purpose being to facilitate style sharing across DSD boundaries. The element, let’s call it <shared-style>, will take a style-id and use it to look up styles in a local cache. If the styles are there, it will simply add them to the shadow root and remove itself. If the styles are not there, it will find them by id in the current scope, cache them, and then remove itself.

For this to work, we need a few things:

• The server must be aware of the <shared-style> element when generating HTML (for de-duping).
• Styles must have a unique id associated with them (for de-duping).
• The <shared-style> element must be defined up-front, before any use of DSD (to avoid FOUC).

We aren’t going to show a server implementation in this post, but one can imagine the server doing something like the following:

• When trying to emit styles, look up whether the styles have already been emitted during the current request.

If the styles have not been emitted:

• Generate a unique id for the styles.
• Emit a <style id="unique-id"> element into the DSD for the styles.
• Emit a <shared-style style-id="unique-id"> element into the DSD, referencing the previously emitted styles.
• Track that the response now includes the styles. (A map from style text to id would do the trick.)

If the styles have already been emitted:

• Emit a <shared-style style-id="unique-id"> element into the DSD, referencing the previously emitted styles.

When the browser receives the HTML, it will look something like this:

<hello-world>
  <template shadowrootmode="open">
    <style id="hello-world">
      :host { display: block; color: red; }
    </style>
    <shared-style style-id="hello-world"></shared-style>
    Hello World
  </template>
</hello-world>

<hello-world>
  <template shadowrootmode="open">
    <shared-style style-id="hello-world"></shared-style>
    Hello World
  </template>
</hello-world>

<hello-world>
  <template shadowrootmode="open">
    <shared-style style-id="hello-world"></shared-style>
    Hello World
  </template>
</hello-world>

Notice that the styles only appear in the markup the first time they are needed. Everywhere else references them via their unique id instead.

IMPORTANT: An alternative solution to the above would be to try to side-step the problem altogether. For example, enabling HTTP Compression would solve the issue of increased payload due to duplicate styles. You’ll want to test both approaches with your own application before making a decision about which one or combination to use.

The Implementation

With the high-level solution worked out, let’s look at an implementation for <shared-style>:

const lookup = new Map();

class SharedStyle extends HTMLElement {
  connectedCallback() {
    const id = this.getAttribute("style-id");
    const root = this.getRootNode();
    let styles = lookup.get(id);

    if (styles) {
      root.adoptedStyleSheets.push(styles);
    } else {
      styles = new CSSStyleSheet();
      const element = root.getElementById(id);
      styles.replaceSync(element.innerHTML);
      lookup.set(id, styles);
    }

    this.remove();
  }
}

customElements.define("shared-style", SharedStyle);

The <shared-style> element will have its connectedCallback() invoked by the browser as it streams the HTML into the DSD. At this point, our element will read its style-id attribute and use it to look up the styles in its cache.

If the cache already has an entry for the id:

• The element adds the styles to the adoptedStyleSheets collection of the containing shadow root.
• Then, the <shared-style> removes itself from the DSD.

If the styles are not present in the cache:

• First, the element constructs a CSSStyleSheet instance.
• Second, it locates the <style> element inside the containing DSD using the id.
• Third, the <style> element's contents are used to provide the styles for the CSSStyleSheet.
• Fourth, the style sheet is cached.
• And finally, the <shared-style> element removes itself from the DSD.

There are a couple other details of the implementation worth pointing out:

• We use this.getRootNode() to find the shadow root that the <shared-style> element is inside of. If it’s not inside of a shadow root, this API will return the document, which also has an adoptedStyleSheets collection.
• If it is the first time <shared-style> is seeing a particular style-id, it doesn't need to push the styles into the adoptedStyleSheets of the root because an in-line <style> element is already present, fulfilling the same purpose.

That’s all there is to it. Don’t forget to include the small bit of JS above inline before any use of <shared-style> and you'll be able to share any number of styles across shadow root boundaries, with full support for DSD streaming and no FOUC.

Wrapping Up

Ideally, we’d be able to share styles across DSDs without any JavaScript. In fact, there is a proposal for a fully declarative way of doing this. But in the meantime, we can solve these types of issues ourselves, using our knowledge of how DSD works and filling in the gaps with a very small amount of code.

In August of last year, I mentioned that I wanted to begin pursuing a potential standard for signals in TC39. Today, I’m happy to share that a v0 draft of such a proposal is publicly available, along with a spec-compliant polyfill.

What are signals?

A signal is a data type that enables one-way data flow by modeling cells of state and computations derived from other state/computations. The state and computations form an acyclic graph, where each node has other nodes that derive state from its value (sinks) and/or that contribute state to its value (sources). A node may also be tracked as “clean” or “dirty”.

But what does all that mean? Let’s look at a simple example.

Imagine we have a counter we want to track. We can represent that as state:

const counter = new Signal.State(0);

We can read the current value with get():

console.log(counter.get()); // 0

And we can change current value with set():

counter.set(1);
console.log(counter.get()); // 1

Now, let’s imagine that we want to have another signal that indicates whether our counter holds an even number or not.

const isEven = new Signal.Computed(() => (counter.get() & 1) == 0);

Computations aren’t writable, but we can always read their latest value:

console.log(isEven.get()); // false
counter.set(2);
console.log(isEven.get()); // true

In the above example, isEven has counter as a source and counter has isEven as a sink.

We can add another computation that provides the parity of our counter:

const parity = new Signal.Computed(() => isEven.get() ? "even" : "odd");

Now we have parity with isEven as a source and isEven with parity as a sink (remember that isEven already has counter as a source). As a result, we can change the original counter and the state will flow unidirectionally to parity.

counter.set(3);
console.log(parity.get()); // odd

Everything we’ve done so far seems like it could be done through normal function composition. But if implemented that way, without signals, there would be no source/sink graph behind the scenes. So, why do we want that graph? What is it doing for us?

Recall that I mentioned signals can be “clean” or “dirty”. When we change the value of counter, it becomes dirty. Because we have a graph relationship, we can then mark all the sinks of counter (potentially) dirty as well, and all their sinks, and so on and so forth.

There’s an important detail to understand here. The signal algorithm is not a push model. Making a change to counter does not eagerly push out an update to the value of isEven and then via the graph, an update to parity. It is also not a pure pull model. Reading the value of parity doesn’t always compute the value of parity or isEven. Rather, when counter changes, it pushes only the change in the dirty flag through the graph. Any potential re-computation is delayed until a specific signal’s value is explicitly pulled.

We call this a “push then pull” model. Dirty flags are eagerly updated (pushed) while computations are lazily evaluated (pulled).

There are a number of advantages that arise out of combining an acyclic graph data structure with a “push then pull” algorithm. Here are a few:

• Signal.Computed is automatically memoized. If the source values haven’t changed, then there’s no need to re-compute.
• Unneeded values aren’t re-computed even when sources change. If a computation is dirty but nothing reads its value, then no re-computation occurs.
• False or “over updating” can be avoided. For example, if we change counter from 2 to 4, yes, it is dirty. But when we pull the value of parity its computation will not need to re-run, because isEven, once pulled, will return the same result for 4 as it did for 2.
• We can be notified when signals become dirty and choose how to react.

These characteristics turn out to be very important when efficiently updating user interfaces. To see how, we can introduce a fictional effect function that will invoke some action when one of its sources becomes dirty. For example, we could update a text node in the DOM with the parity:

effect(() => node.textContent = parity.get());
// The effect's callback is run and the node's text is updated with "odd"
// The effect watches the callback's source (parity) for dirty changes.

counter.set(2);
// The counter dirties its sinks, resulting in the effect being
// marked as potentially dirty, so a "pull" is scheduled.
// The scheduler begins to re-evaluate the effect callback by pulling parity.
// parity begins to evaluate by pulling isEven.
// isEven pulls counter, resulting in a changed value for isEven.
// Because isEven has changed, parity must be re-computed.
// Because parity has changed, the effect runs and the text updates to "even"

counter.set(4);
// The counter dirties its sinks, resulting in the effect being
// marked as potentially dirty, so a "pull" is scheduled.
// The scheduler begins to re-evaluate the effect callback by pulling parity.
// parity begins to evaluate by pulling isEven.
// isEven pulls counter, resulting in the same value for isEven as before.
// isEven is marked clean.
// Because isEven is clean, parity is marked clean.
// Because parity is clean, the effect doesn't run and the text is unaffected.

Hopefully this brings some clarity to what a signal is, and an understanding of the significance of the combination of the acyclic source/sink graph with its “push then pull” algorithm.

Who has been working on this?

Late in 2023 I partnered with Daniel Ehrenberg, Ben Lesh, and Dominic Gannaway to try to round up as many signal library authors and maintainers of front-end frameworks as we could. Anyone who expressed an interest was invited to help us begin to explore the feasibility of signals as a standard.

We started with a survey of questions and one-on-one interviews, looking for common themes, ideas, use cases, semantics, etc. We didn’t know whether there was even a common model to be found. To our delight, we discovered that there was quite a bit of agreement from the start.

Over the last 6–7 months, detail after detail was poured over, attempting to move from general agreement to the specifics of data structures, algorithms, and an initial API. You may recognize a number of the libraries and frameworks that have provided design input at various times throughout the process so far: Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

It’s quite a list! And I can honestly say, looking back at my own work in Web Standards over the last ten years, this is one of the most amazing collaborations I’ve had the honor to be a part of. It’s a truly special group of people with exactly the type of collective experience that we need to continue to move the web forward.

IMPORTANT: If we missed your library or framework, there’s still plenty of opportunity to get involved! Nothing is set in stone. We’re still at the beginning of this process. Scroll down to the section titled “How can I get involved in the proposal?” to learn more.

What is in the signals proposal?

The proposal, which can be found on GitHub, includes:

• Background, motivation, design goals, and an FAQ.
• A proposed API for creating both state and computed signals.
• A proposed API for watching signals.
• Various additional proposed utility APIs, such as for introspection.
• A detailed description of the various signal algorithms.
• A spec-compliant polyfill covering all the proposed APIs.

The signals proposal does not include an effect API, since such APIs are often deeply integrated with rendering and batch strategies that are highly framework/library dependent. However, the proposal does seek to define a set of primitives and utilities that library authors can use to implement their own effects.

On that note, the proposal is designed in such a way as to recognize that there are two broad categories of signal users:

• Application developers
• Library/framework/infrastructure developers

APIs that are intended to be used by application developers are exposed directly from the Signal namespace. These include Signal.State() and Signal.Computed(). APIs which should rarely if ever be used in application code, and more likely involve subtle handling, typically at the infrastructure layer, are exposed through the Signal.subtle namespace. These include Signal.subtle.Watcher , Signal.subtle.untrack(), and the introspection APIs.

ASIDE: Haven’t seen something like the idea of the subtle namespace in JavaScript before? Checkout Crypto.subtle.

We interrupt this blog post on signals to remind you of the Web Component Engineering course, trusted by giants such as Adobe, Microsoft, Progress, and Reddit. If you want to learn modern UI engineering, get up to speed on dozens of Web Standards, and even see how signals can be integrated with Web Components, this is the course for you. Group rates for teams and PPP pricing available upon request.

Now, back to your regularly scheduled program…

As an app dev, how do I use signals?

Many of today’s popular component and rendering frameworks are already using signals. Over the coming months, we hope that framework maintainers will experiment with re-platforming their systems on top of the signals proposal, providing feedback along the way, and helping us prove out whether it is possible to leverage a potential signals standard.

If this were to work out, many app developers would use signals through their chosen component framework; their patterns wouldn’t change. However, their framework would then be more interoperable (reactive data interoperability), smaller (signals are built in and don’t need to ship as JS), and hopefully faster (native signals as part of the JS runtime).

Library authors would then be able to write code using signals that works natively with any component or rendering library that understands the standard, reducing the fragmentation in the web ecosystem. Application developers would be able to build model/state layers that are decoupled from their current rendering technology, giving them more architectural flexibility and the ability to experiment with and evolve their view layer without re-writing their entire application.

So, let’s say you are a developer that wants to create a library using signals, or who wants to build an application state layer on these primitives. What would that code look like?

Well, we’ve seen a bit of it already, when I explained the basics of signals through the Signal.State() and Signal.Computed() APIs above. These are the two primary APIs that an application developer would use, if not using them indirectly through a framework’s API. They can be used by themselves to represent stand-alone reactive state and computations or in combination with other JavaScript constructs, such as classes. Here’s a Counter class that uses a signal to represent its internal state:

export class Counter {
  #value = new Signal.State(0);

  get value() {
    return this.#value.get();
  }

  increment() {
    this.#value.set(this.#value.get() + 1);
  }

  decrement() {
    if (this.#value.get() > 0) {
      this.#value.set(this.#value.get() - 1);
    }
  }
}

const c = new Counter();
c.increment();
console.log(c.value);

One particularly nice way to use signals is in combination with decorators. We can create a @signal decorator that turns an accessor into a signal as follows:

export function signal(target) {
  const { get } = target;

  return {
    get() {
      return get.call(this).get();
    },

    set(value) {
      get.call(this).set(value);
    },
    
    init(value) {
      return new Signal.State(value);
    },
  };
}

Then we can use it to reduce boilerplate and improve readability of our Counter class like this:

export class Counter {
  @signal accessor #value = 0;

  get value() {
    return this.#value;
  }

  increment() {
    this.#value++;
  }

  decrement() {
    if (this.#value > 0) {
      this.#value--;
    }
  }
}

There are many more ways to use signals, but hopefully these examples provide a good starting point for those who want to experiment at this state.

ASIDE: Some users of particular signal libraries may not approve of my use of the following code above this.#value.set(this.#value.get() + 1). In some signal implementations, this can cause an infinite loop when used within a computed or an effect. This does not cause a problem in the current proposal’s computed, nor does it cause a problem in the example effect demonstrated below. Should it cause a loop though? Or should it throw? What should be the behavior? This is an example of the many types of details that need to be worked through in order to standardize an API like this.

As a library/infra dev, how do I integrate signals?

We hope that maintainers of view and component libraries will experiment with integrating this proposal, as well as those who create state management and data-related libraries. A first integration step would be to update the library’s signals to use Signal.State() and Signal.Computed() internally instead of their current library-specific implementation. Of course this isn’t enough. A common next step would be to update any effect or equivalent infrastructure. As I mentioned above, the proposal doesn’t provide an effect implementation. Our research showed that this was too connected to the details of rendering and batching to standardize at this point. Rather, the Signal.subtle namespace provides the primitives that a framework can use to build its own effects. Let’s take a look at the implementation of a simple effect function that batches updates on the microtask queue.

let needsEnqueue = true;

const w = new Signal.subtle.Watcher(() => {
  if (needsEnqueue) {
    needsEnqueue = false;
    queueMicrotask(processPending);
  }
});

function processPending() {
  needsEnqueue = true;
    
  for (const s of w.getPending()) {
    s.get();
  }

  w.watch();
}

export function effect(callback) {
  let cleanup;
  
  const computed = new Signal.Computed(() => {
    typeof cleanup === "function" && cleanup();
    cleanup = callback();
  });
  
  w.watch(computed);
  computed.get();
  
  return () => {
    w.unwatch(computed);
    typeof cleanup === "function" && cleanup();
  };
}

The effect function begins by creating a Signal.Computed() out of the user-provided callback. It can then use the Signal.subtle.Watcher to watch the computed’s sources. To enable the watcher to “see” the sources, we need to execute the computed at least once, which we do by calling get(). You may also notice that our effect implementation supports a basic mechanism for callbacks to provide cleanup functions as well as a way to stop watching, via the returned function.

Looking at the creation of the Signal.subtle.Watcher, the constructor takes a callback that will be invoked synchronously whenever any of its watched signals becomes dirty. Because a Watcher can watch any number of signals, we schedule processing of all dirty signals on the microtask queue. Some basic guard logic ensures that scheduling only happens once, until the pending signals are handled.

In the processPending() function, we loop over all the signals that the watcher has tracked as pending and re-evaluate them by calling get(). We then ask the watcher to resume watching all its tracked signals again.

That’s the basics. Most frameworks will handle queuing in a way that’s integrated with their rendering or component system, and they’ll likely make other implementation changes in order to support the working model of their system.

Other APIs

Another API that’s likely to be used in infrastructure is the Signal.subtle.untrack() helper. This function takes a callback to execute and ensures that signals read within the callback will not be tracked.

I feel the need to remind readers: the Signal.subtle namespace designates APIs that should be used with care, and mostly by framework or infrastructure authors. Using something like Signal.subtle.untrack() incorrectly or carelessly can mess up your application in ways that are difficult to track down.

With that said, let’s look at a legitimate use of this API.

Many view frameworks have a way to render a list of items. Typically, you pass the framework an array and a “template” or fragment of HTML that it should render for each item in the array. As an application developer, you want any interaction with that array to be tracked by the reactivity system so that your list’s rendered output will stay in sync with your data. But what about the framework itself? It must access the array in order to render it. If the framework’s access of the array were tracked by the dependency system, that would create all sorts of unnecessary connections in the graph, leading to false or over updating…not to mention the likelihood of performance problems and strange bugs. The Signal.subtle.untrack() API provides the library author with a simple way to handle this challenge. As an example, let’s look at a small bit of code from SolidJS that renders arrays, which I’ve slightly modified to use the proposed standard. We won’t look at the whole implementation. I’ve cut most of the code out for simplicity. Hopefully, looking at the high-level outline will help explain the use case.

export function mapArray(list, mapFn, options = {}) {
  let items = [],
      mapped = [],
      len = 0,
    /* ...other variables elided... */;

  // ...elided...

  return () => {
    let newItems = list() || [], // Accessing the array gets tracked
        i,
        j;
    
    // Accessing the length gets tracked
    let newLen = newItems.length;

    // Nothing in the following callback will be tracked. We don't want our
    // framework's rendering work to affect the signal graph!
    return Signal.subtle.untrack(() => {
      let newIndices,
          /* ...other variables elided... */;

      // fast path for empty arrays
      if (newLen === 0) {
        // ... read from the array; not tracked ...
      }
      // fast path for new create
      else if (len === 0) {
        // ... read from the array; not tracked ...
      } else {
        // ... read from the array; not tracked ...
      }

      return mapped;
    });
  };
}

Even though I’ve elided the bulk of Solid’s algorithm, you can see how the main body of work is done within an untracked block of code that accesses the array.

There are additional APIs within the Signal.subtle namespace which you can explore at your leisure. Hopefully, the above examples help to demonstrate the kinds of scenarios this part of the proposal is designed for.

How can I get involved in the proposal?

Just jump in! Everything is on GitHub. You’ll find the proposal in the root of the repo, and the polyfill in the packages folder. You can also chat with us on Discord.

Here are a few ideas for how you can get started contributing:

• Try out signals within your framework or application.
• Improve the documentation/learning materials for signals.
• Document use cases (whether it’s something the API supports well or not).
• Write more tests, e.g., by porting them from other signal implementations.
• Port other signal implementations to this API.
• Write benchmarks for signals, both synthetic and real-world application ones.
• File issues on polyfill bugs, your design thoughts, etc.
• Try developing reactive data structures/state management abstractions on top of signals.
• Implement signals natively in a JS engine (behind a flag/in a PR, not shipped!)

There are also a variety of issues that have already been created to track ongoing areas of debate, potential modifications to algorithms, additional APIs, use cases, polyfill bugs, etc. Please take a look at those and see which ones you can provide insights on. If you are a framework or library author, we really want you to help us understand any scenarios or use cases that you think would pose a challenge for the current proposal.

What’s next?

We’re still at the beginning of this effort. In the next few weeks Daniel Ehrenberg (Bloomberg) and Jatin Ramanathan (Google/Wiz) will bring the proposal before TC39, seeking Stage 1. Stage 1 means that that proposal is under consideration. Right now, we’re not even there yet. You can think of signals as being at Stage 0. The earliest of the early. After presenting at TC39, we’ll continue to evolve the proposal based on feedback from that meeting, and in line with what we hear from folks who get involved through GitHub.

Our approach is to take things slow and to prove ideas out through prototyping. We want to make sure that we don’t standardize something that no one can use. We’ll need your help to achieve this. With your contributions as described above, we believe we’ll be able to refine this proposal and make it suitable for all.

I believe a signal standard has tremendous potential for JavaScript and for the Web. It’s been exciting to work with such a great set of folks from the industry who are deeply invested in reactive systems. Here’s to more future collaboration and a better web for all. 🎊

One of the most common misunderstandings folks seem to have about Web Components is that they can’t take advantage of global CSS. This is simply not true. With only a few lines of JavaScript you can enable any Web Component to respond to your global CSS. In this article, I’ll show you how to build this into your own components, as well as how to take pre-existing FAST and Lit components and modify them to also respond to global styles. We’ll even see how to accomplish this with Declarative Shadow DOM (DSD).

Shadow DOM, by design, provides encapsulation of styles. This means that only the styles that you explicitly add to your shadow root will affect its presentation. Likewise, only the styles that you explicitly leak out will affect external DOM. One only needs to leverage a couple of standard HTML features to import global styles into a shadow root. Let’s see how this works…

Using Global Styles in a VanillaJS Web Component

Let’s begin by looking at some HTML containing global styles and two web components, each of which contains the same h1 and h2 structure as the body.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Global Styles in Shadow DOM</title>
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-T3c6CoIi6uLrA9TneNEoa7RxnatzjcDSCmG1MXxSR1GAsXEV/Dwwykc2MPK8M2HN" crossorigin="anonymous">
    <style>
      h2 {
        color: red;
      }
    </style>  
  </head>
  <body>
    <h1>Light DOM H1 with Bootstrap Styles</h1>
    <h2>Light DOM H2 with Bootstrap and Global Custom Styles</h2>
    <hr>
    
    <not-using-global-styles></not-using-global-styles>
    <hr>
    
    <using-global-styles></using-global-styles>
    <hr>
  </body>
</html>

In the above HTML, I have a standard CSS link to Bootstrap. I also have some custom styles provided via a style element. Here’s how the page renders.

The h1 and h2 that are directly in the body pick up both Bootstrap and the custom styles. The h1 and h2 that are in the not-using-global-styles custom element do not pick up the global CSS. Both of these cases are as expected. But the h1 and h2 that are in the using-global-styles do pick up both Bootstrap and the custom styles.

How is this accomplished?

If we compare the implementation of not-using-global-styles to that of using-global-styles, we’ll see one important difference.

not-using-global-styles.js

export class NotUsingGlobalStyles extends HTMLElement {
  constructor() {
    super();

    this.attachShadow({ mode: "open" }).innerHTML = `
      <h1>Shadow DOM H1 without Bootstrap Styles</h1>
      <h2>Shadow DOM H2 without Bootstrap or Global Custom Styles</h2>
    `;
  }
}

customElements.define("not-using-global-styles", NotUsingGlobalStyles);

using-global-styles.js

import { addGlobalStylesToShadowRoot } from "./global-styles.js";

export class UsingGlobalStyles extends HTMLElement {
  constructor() {
    super();

    this.attachShadow({ mode: "open" }).innerHTML = `
      <h1>Shadow DOM H1 with Bootstrap Styles</h1>
      <h2>Shadow DOM H2 with Bootstrap and Global Custom Styles</h2>
    `;

    addGlobalStylesToShadowRoot(this.shadowRoot); // look here!
  }
}

customElements.define("using-global-styles", UsingGlobalStyles);

The magic is in a single helper function that I’ve written: addGlobalStylesToShadowRoot. All you need to do to inherit global CSS in your Shadow DOM is import that function and call it with your shadow root. Here’s how it’s implemented:

global-styles.js

let globalSheets = null;

export function getGlobalStyleSheets() {
  if (globalSheets === null) {
    globalSheets = Array.from(document.styleSheets)
      .map(x => {
        const sheet = new CSSStyleSheet();
        const css = Array.from(x.cssRules).map(rule => rule.cssText).join(' ');
        sheet.replaceSync(css);
        return sheet;
      });
  }

  return globalSheets;
}

export function addGlobalStylesToShadowRoot(shadowRoot) {
  shadowRoot.adoptedStyleSheets.push(
    ...getGlobalStyleSheets()
  );
}

By leveraging CSSStyleSheet and the shadow root’s adoptedStyleSheets array, we can add any style sheet we want to our Shadow DOM, global or otherwise. In the code above, I’ve written a function called getGlobalStyleSheets() that looks at the document.styleSheets collection and creates CSSStyleSheet instances using standard APIs. The function lazily constructs the sheets and then caches them, so that the work is only done when needed and all sheet instances can be shared across all Shadow DOMs that need them.

NOTE: The style sheets we get from document.styleSheets are not “Constructible Style Sheet” instances, so we can’t directly use them with adoptedStyleSheets. No problem. We just create our own constructible style sheets from the css text of the document sheets.

Really, that’s all there is to it. Just a few lines of JavaScript using standard APIs will make global styles available in any Web Component where you need them.

Want to know more about CSSStyleSheet, adoptedStyleSheets, Declarative Shadow DOM, and other Shadow DOM and styling topics discussed in this blog? Check out my Web Component Engineering course. Group rates for teams and PPP pricing available upon request.

Adding Global Styles to 3rd Party Web Components

The code above seems fine if you are the author of the Web Component. But what if you need to use global styles with a component created by someone else who used a Web Component Library like FAST or Lit? You could use the addGlobalStylesToShadowRoot() helper function on each instance’s shadow root (assuming it’s open). That’s not very practical though. Is there a way that you could control this for all instances of a component type?

Yes. Let’s take a look at each library to see how.

Adding Global Styles to an Existing FAST Element

Let’s start by looking at some very basic code for a FASTElement that doesn’t use global styles. Imagine this was written by another team, or that it was part of an open-source component library you are using.

import { FASTElement, FASTElementDefinition, html } from "@microsoft/fast-element";

export const template = html`
  <h1>Existing FAST Element Shadow DOM H1</h1>
  <h2>Existing FAST Element Shadow DOM H2</h2>
`;

export class ExistingFASTElement extends FASTElement {

}

export const definition = new FASTElementDefinition(ExistingFASTElement, {
  name: "existing-fast-element",
  template
});

In FAST, all Web Components have a FASTElementDefinition that provides metadata about the component, used when constructing instances. 3rd-party component libraries built on FAST usually provide these definitions, decoupled from component registration. As a result, we can easily add global styles to all instances of a Web Component type using a small amount of code that modifies the definition itself. Here’s how we do it:

import { ElementStyles } from "@microsoft/fast-element";
import { definition } from "./existing-fast-element.js";
import { getGlobalStyleSheets } from "./global-styles.js";

// FAST
definition.styles = ElementStyles.create(
  getGlobalStyleSheets(), 
  definition.styles
);

definition.define();

FAST provides an ElementStyles helper for working with style sheets. We can simply pass our global styles, provided by getGlobalStyleSheets(), along with any existing styles defined by the component. This will then return a new set of styles associated with the definition that will be used by all instances of the component.

NOTE: Be mindful of the ordering of the style sheets. In the above example, we have ordered the sheets so that the global styles come before the component’s built-in styles. If that’s not desired, you can always swap the order.

Adding Global Styles to an Existing Lit Element

Similarly, we can look at some very basic code for a LitElement that doesn’t use global styles.

import { LitElement, html } from "lit";

export class ExistingLitElement extends LitElement {
  render() {
    return html`
      <h1>Existing Lit Element Shadow DOM H1</h1>
      <h2>Existing Lit Element Shadow DOM H2</h2>
    `;
  }
}

Lit looks for styles in a static styles field on the class. So, all we need to do is alter that to add the global styles. Here’s what that looks like:

import { ExistingLitElement } from "./existing-lit-element.js";
import { getGlobalStyleSheets } from "./global-styles.js";

// Lit
ExistingLitElement.styles = [
  ...getGlobalStyleSheets(),
  ...(Array.isArray(ExistingLitElement.styles)
      ? ExistingLitElement.styles 
        : ExistingLitElement.styles ? [ExistingLitElement.styles] : [])
];

customElements.define("existing-lit-element", ExistingLitElement);

This looks slightly more complicated, mainly because we need to do a bit more work to ensure that we’re handling any existing styles on the 3rd-party element. So, just a bit of conditional logic checking for undefined, single, and array possibilities is needed. But the concept is the same as with FAST. We just get the global styles and merge them with any existing styles, then assign that back to the styles static field. Done.

Adding Global Styles to Declarative Shadow DOM (DSD)

What if we want to enable global styles to work in a Declarative Shadow DOM (DSD)? How would we accomplish that?

Well, we’re going to use the same helper, but we’re going to wrap it in a very simple custom element that will add the global styles while the DSD is being streamed into the DOM. Here’s the small element that does the work:

adopt-global-styles.js

import { addGlobalStylesToShadowRoot } from "./global-styles.js";

export class AdoptGlobalStyles extends HTMLElement {
  connectedCallback() {
    addGlobalStylesToShadowRoot(this.getRootNode());
    this.remove();
  }
}

customElements.define("adopt-global-styles", AdoptGlobalStyles);

And here’s how we use it in DSD:

<dsd-element>
  <template shadowrootmode="open">
    <adopt-global-styles></adopt-global-styles>
    <h1>DSD H1 with Bootstrap Styles</h1>
    <h2>DSD H2 with Bootstrap and Global Custom Styles</h2>
  </template>
</dsd-element>

The adopt-global-styles element uses getRootNode() to obtain the shadow root that it is inside of. In this case, the shadow root created by DSD. It then adds the global styles to that root and removes itself once the work is done.

Standards, Experiments, and Helper Libraries

While it’s possible to use global styles in your Shadow DOM, many would like a built-in standard enabling this, so no JavaScript is required. To that end, various conversations have been happening, attempting to hash out what the key scenarios are and what the API might look like. These conversations are happening under the banner of “open stylable shadow roots”. If you are interested in this, I highly recommend that you give Brian Kardell’s blog post a read and check out his half-light library.

Brian is eagerly seeking feedback on scenarios and APIs to help shape a future HTML/CSS standard. Please give half-light a try in your own Web Components and help us out in shaping the future of the Web.

Wrapping Up

I hope this article helps dispel the myth that you can’t use global styles with Shadow DOM. A very small amount of JavaScript that interacts with document.styleSheets and adoptedStyleSheets will often do the trick. One simple helper function can enable scenarios in VanillaJS, FAST, Lit, and DSD. For more advanced, nuanced, and automatic techniques, a small 100 LOC library like half-light can be used, a steppingstone to a potential new HTML/CSS standard.

If you enjoyed this look into Web Standards, please let me encourage you to consider purchasing my Web Component Engineering course for yourself or your team. I’d also love it if you would subscribe to this blog, subscribe to my YouTube channel, or follow me on twitter. Your support greatly helps me continue writing and bringing this kind of content to the broader community. Thank you!

Last week, members of the W3C Web Components Community Group, including browser vendors, library authors, and community members, met face-to-face to discuss new Web Component standards and platform improvements. In this post, I’ll go over the wide variety of topics that were covered.

Day 1

Declarative Shadow DOM (DSD)

Day 1 of the event started out with some great news. Firefox is on track to ship DSD in version 123 or 124. Based on the Firefox release calendar, that means we’ll see full cross-browser support for this paradigm-changing feature in February or March of this year.

UPDATE: Firefox has greenlit DSD for version 123, going out February 20!

If you aren’t familiar with DSD, it’s a new standard that enables creating Shadow DOM in HTML without writing any JavaScript. Declarative Shadow DOM enables a bunch of interesting scenarios:

• Pseudo custom components with fully encapsulated styles and slot-based composition, without JavaScript.
• Out of order, deferred content streaming with no need for JavaScript.
• Improved declarative separation of HTML intended for semantic vs. presentation purposes.
• A standard output for server-rendered Web Components.
• An improved migration path from global CSS techniques to more performant, modular CSS.
• An improved migration path to more modern, component-oriented HTML architectures.
• New progressive enhancement approaches.

If you are interested in learning more about Shadow DOM, including the new declarative capabilities, I’ve got an entire module in my Web Component Engineering course dedicated to the topic.

You can learn more here.

CSS Slot Content Detection

When building Web Components or using Shadow DOM, there’s often a desire to alter styles based on whether something is slotted into a particular location. For example, imagine a button component that needs to alter its internal spacing based on whether or not an image was slotted into the button. Today, this is accomplished by adding an event listener to the slotchange event and altering the styles based on the assignedNodes().

Because this scenario is so common, the Web Components CG has been working with the CSS WG and browser vendors to extend CSS with a new fully declarative mechanism that enables styling based on slotted state.

There are various approaches that could be taken to solve this problem in CSS, such as using a combinator or a pseudo-selector. While a combinator would be more powerful, it may also cause significant complexity and even performance problems. In light of this, the group seemed to favor the simpler approach of pursuing a pseudo-selector that is very targeted in scope, which could be shipped faster and with less risk.

The group is following up in W3C on next steps to get an official spec in place following these discussions. If you want to learn more about today’s techniques for this scenario, the Form Integration module of my Web Component Engineering course covers this in detail.

Scoped Element Registries

Today, all custom elements are defined globally in HTML. While this works fine for many sites and small to medium applications, it becomes a challenge in larger modular apps, mini-apps, micro-frontends, and other more complex scenarios. To address this need, the ability to create scoped registries of components and associate them with Shadow DOM has been proposed.

Fortunately, towards the end of last year, the scoped registry feature was successfully prototyped in Chromium. This enabled a few open questions and important details to be worked out. The CG agreed that the next steps are to update the spec based on lessons learned from the prototype and build out further prototypes in other browsers. We’re actively working on getting together the people to make this happen, with volunteers already stepping forward to implement cross browser.

If you are interested in learning more about custom element registries, as well as best practices for exporting, registering, and distributing Web Components, I’ve got quite a bit of content available here, where I walk through creating a Web Component-based design system.

ARIA Mixin

I’m very happy to report that with the release of Firefox 119 in October 2023, every major browser has now shipped support for ARIA Mixin string reflection via ElementInternals. This means that string-based ARIA attributes can be set through ElementInternals without needing to create attributes manually on the element’s host, enabling cleaner HTML and the ability for the component consumer to override default ARIA settings with their own.

ASIDE: For more information on using ARIA Mixin, as well as how to write your own polyfill for older browsers, see my course. 😆

Cross Shadow Root ARIA

One of the things that’s not possible out-of-the-box with custom elements is connecting ID references across shadow roots. For example, if you are building a custom input control and you want a label outside of the element to be able to target an input inside of the element’s shadow DOM. Over the years, there have been a number of proposals for how to improve this, but this year I saw what I think is the most promising proposal so far, one that balances ease of use with power. The new proposal is called Reference Delegate for Cross-root ARIA.

Using the proposed feature, a shadow root could specify an element that all ID refs should be delegated to. So, when a label’s for attribute references the host element, it will delegate through to the shadow root’s declared reference delegate. Here’s some code that shows the most basic scenario, using the imperative API:

<script>
customElements.define("fancy-input", 
  class FancyInput extends HTMLElement {
    constructor() {
      super();
      this.attachShadow({ mode: "open" });
      this.shadowRoot.innerHTML = `<input id="real-input" />`;
      this.shadowRoot.referenceDelegate = "real-input"; // magic!
    }
  }
);
</script>

<!--This label will target the internal real-input of fancy-input -->
<label for="fancy-input">Fancy input</label>
<fancy-input id="fancy-input"></fancy-input>

There’s also a no JS, declarative version of this for use with DSD:

<label for="fancy-input">Fancy input</label>
<fancy-input id="fancy-input">
  <template shadowrootmode="open"
            shadowrootreferencedelegate="real-input">
    <input id="real-input" />
  </template>
</fancy-input>

One of the nicest details of the feature design is that it works with any attribute that refers to another element by ID string. Here’s the list as outlined in the RFC:

• aria-activedescendant
• aria-controls
• aria-describedby
• aria-details
• aria-errormessage
• aria-flowto
• aria-labelledby
• aria-owns
• for
• form
• list
• popovertarget
• invoketarget
• interesttarget
• headers
• itemref

The attendees seemed to be pretty pleased with this proposal, particularly since it makes the most common scenario very simple and works both imperatively and declaratively in an intuitive way. There was much more discussion around complex scenarios, which the RFC proposes to solve via the referenceDelegateMap. This allows mapping different ID refs to different elements. Here’s an example of using the declarative API for that:

<input role="combobox"
       aria-controls="fancy-listbox"
       aria-activedescendant="fancy-listbox" />
<fancy-listbox id="fancy-listbox">
  <template shadowrootmode="open"
            shadowrootreferencedelegatemap="aria-controls: real-listbox,
                                            aria-activedescendant: option-1">
    <div id="real-listbox" role="listbox">
      <div id="option-1" role="option">Option 1</div>
      <div id="option-2" role="option">Option 2</div>
    </div>
  </template>
</fancy-listbox>

NOTE: The map can be updated dynamically. So, the mapping from aria-activedescendant to option-1 can be changed based on user interaction.

While this is a bit more complicated than the simple referenceDelegate it still seemed to me to be a pretty intuitive way to handle the situation. I’ll be keeping an eye on this proposal, hoping it comes to browsers soon.

Day 2

Open Stylable

The term “open stylable” loosely refers to a collection of use cases related to enabling global CSS to take effect inside of the Shadow DOM of specific Web Components. This is most often requested by folks who want to use Web Components, but are required to integrate with a global stylesheet, which they often have no control over. But that is not the only scenario.

Broadly speaking, there are ways to handle this today, using a very small amount of JS in combination with Adopted StyleSheets. But there isn’t a standardized or fully declarative mechanism that works without JS.

There was a lot of discussion within the group on this topic. The biggest challenge seemed to be lack of clarity surrounding use cases. Over the years, this issue has been raised several times, but often without clear real-world use cases, or with wildly different needs. There have often been differences in scenarios, which then lead to subtlety different proposals for how to address the issue, which prevented any sort of consensus in the CG or community…and of course that resulted in no standard being established.

To try to move this in a more productive direction, the CG has asked for the submission of classic user stories, detached from any specific technical solution. In other words, rather than making a specific feature request, the group needs to understand what folks are trying to accomplish. It may be that the solution actually involves adding more than one feature in the end, but it’s hard to see that without the real stories to drive the overall platform design.

Container Style Queries

CSS Container Size Queries have been implemented in all the major browsers today. But only Chromium has shipped CSS Container Style Queries for custom properties. During the CG, time was taken to make sure that each of the browsers was on board with custom property-based container style queries. There was strong consensus. So, with the spec written, one shipped implementation, and cross browser consensus, we’re now just waiting for the additional Firefox and WebKit implementations to be completed and shipped.

ASIDE: If you want to learn more about CSS Container Size and Style queries, particularly in the context of Web Components, check out my Web Component Engineering course. Dang, there’s a lot of Web Standards goodness packed into that course…

CSS Module Scripts, Imports, and the @sheet Proposal

The basic CSS Module Scripts feature has been standardized and is moving forward. If you aren’t familiar with that, here’s an example from my Web Component engineering course:

import styles from "./ui-card.css" with { type: "css" };

const template = `
  <slot></slot>
`;

export class UICard extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: "open" }).innerHTML = template;
    this.shadowRoot.adoptedStyleSheets.push(styles);
  }
}

customElements.define("ui-card", UICard);

Notice how a CSS file can be directly imported using the import attribute “css” type. When that happens, the default export is a CSSStyleSheet instance which can be passed directly to a shadow root’s adoptedStyleSheets array.

The Web Components CG is working with the W3C CSS WG to expand CSS imports to enable specifying multiple sheets inside of a single file. This would allow bundling component CSS into a single CSS file while keeping each sheet isolated to the Shadow DOM that it is imported into. To enable this, a @sheet syntax is being proposed. Here’s what that would look like in CSS and how it could be used in a Web Component.

/* components.css */

@sheet uiCard {
  :host {
    box-shadow: 0 0 .5rem rgba(0,0,0,0.15);
    border: .075rem solid #d8d8d8;
    border-radius: .375rem;
  }
}

@sheet uiButton {
  :host {
    ...
  }
}

import { uiCard as styles } from "./components.css" with { type: "css" };

const template = `
  <slot></slot>
`;

export class UICard extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: "open" }).innerHTML = template;
    this.shadowRoot.adoptedStyleSheets.push(styles);
  }
}

customElements.define("ui-card", UICard);

Once this feature is available, Web Component libraries that use this technique to distribute their CSS will not only gain the benefit of improved performance but will also make it much easier for component consumers to customize their styles. Consumers would simply provide their own CSS file to replace the originally distributed file.

NOTE: There is a separate proposal for declaratively importing CSS into a DSD. My hope is that however that feature works out in the end, it will also integrate with the new @sheet capability. With that in place, the entire example above could be done without any JavaScript.

HTML Modules and Declarative Custom Elements

With JS Import Attributes enabling the import of JSON and CSS, the group wanted to re-open earlier discussions about the possibility of HTML modules. Ultimately, there was consensus that something like this was needed, but that this might not be the right time yet.

In fact, as discussion proceeded, the group wondered whether it might be better to first explore fully declarative custom elements. There has been huge, long-time interest in this. Perhaps a minimal declarative format could be developed more quickly, and then expanded over time. The group resolved to explore this further, with a note that if a fully declarative format could be standardized, browsers could make further optimizations, particularly around caching binary representations of components and reusing them across page loads. Firefox has some previous experience doing just this with XBL and was very interested.

Wrapping Up

All-in-all, it was a great winter meetup. It was particularly nice to see features like ARIA Mixin shipped cross browser and get confirmation from Firefox that DSD was coming very soon. Discussions around in-progress proposals and standards were productive with a solid set of action items to help move forward. It looks like 2024 is going to be another great year for Web Components!

A huge THANK YOU goes out to everyone who purchased the Web Component Engineering course over the last month! It was an ambitious project for me to put together, but you made it all worthwhile!

Feedback on the course has been great so far and in the time since launch, students have collectively completed over 1,500 lessons. Awesome! Go Web Components and Web Standards!

Updates

I am continuing to improve the content, its format, and the experience with lots of new capabilities and additional learning opportunities coming over the next few months. The goal is that the content not only serves as a set of initial lessons to learn and practice, but also as the best on-going and up-to-date Web Component standards reference available.

Sale

With the hope that many more people can benefit from this resource, I’ve put together a new sale during Thanksgiving. If you weren’t able to take advantage of the pre-sale, I’m happy to offer a Thanksgiving discount, from today through the end of Monday, November 27th.

For the next week only, get 10% off the Web Component Engineering course by using code GRATITUDE at checkout.

Happy Thanksgiving!

Today, I’m excited to announce that after months of work, my Web Component Engineering course is now live! 🎊

Back in April, I first sat down to figure out what I wanted to do with my business, and how I could advance Web Standards and help lift up engineers who desire to grow in modern UI Engineering with these standards. When I looked across the industry, there seemed to be a profound absence of solid training and quality content focused on Web Standards. That’s when I ramped up writing content on this blog and decided to create the Web Component Engineering course. My hope is that these two resources (and more I’ve got planned for next year) will begin to fill in the gaps while sharing some of the unique things I’ve had the opportunity to learn over the years.

It has taken months of writing documentation, creating code examples, building a design system, building a couple of applications, filming videos, editing, and more, but the course is now finally live! I learned so much through this process, and I’m excited to finally get this content into your hands.

Please let me extend a special thank you to all the early birds who purchased the course during the pre-sale period. It has been very encouraging to me to see the wonderful response, which greatly helped energize me in getting everything over the finish line.

Special thanks also go out to Cory LaViska of Shoelace, who gave me some great business advice at a critical juncture, as well as my old friend and one of the most talented UI/UX designers I know, Scott Criswell, who brought a unique designer’s perspective and was a constant source of feedback throughout my creative process. Finally, thank you to all my reviewers and testers over the last month or two.

Discounts

I’ve decided to extend the pre-sale discount through the end of today. So, if you are just finding out about this now, you can still use the code EARLYBIRD to purchase the course and save $100. This is the last time that a discount of this size will be offered on this course, so don’t miss out.

The Learning App

One of the unique things about this course is the custom learning app that I built for the content. It has evolved quite a bit over the last couple of months and will continue to gain new features in the future, so that the content can grow in value even after students complete the course.

The fun thing about this app is that it’s all built with Web Components, using no libraries or frameworks. It’s built with the same code that we develop in the course itself and uses a number of the same components that we build. I really wanted to dog-food the course material as much as possible and provide the best experience for students. This seemed like a fun way to do that.

Group Rates

As a reminder, if you are an engineering leader looking for content to help train your team, or if you are an individual engineer who thinks that you can find several other people at your company interested in this content, I offer a variety of group licensing options. So, please reach out to sales at bluespire dot com for more information on that.

Purchasing Power Parity (PPP)

Now that we are launched, we will be able to begin offering PPP pricing for select countries starting next week. Please see our PPP page for more information and instructions on how to pursue this option.

Wrapping Up

It’s been a wild ride for me over the last several months, but the release day is finally here. I sincerely hope that everyone enjoys this course and that it’s the first of many opportunities I can share with you.

Happy learning!