Real‑world examples of understanding custom web components and browser compatibility

Real examples of understanding custom web components and browser compatibility in 2024–2025

When developers talk about examples of understanding custom web components and browser compatibility, they often focus on the happy path: Chrome on a fast laptop. The interesting stories start when you move beyond that comfort zone.

Let’s walk through several real examples that show how custom elements behave differently across browsers, and what you can do about it.

Example of a basic custom element that fails silently in older browsers

Imagine a very simple custom element:

class MyGreeting extends HTMLElement {
  connectedCallback() {
    this.textContent = `Hello, ${this.getAttribute('name') || 'world'}!`;
  }
}

customElements.define('my-greeting', MyGreeting);

And the HTML:

<my-greeting name="Jamie"></my-greeting>

In modern Chromium‑based browsers, Firefox, and Safari (current releases), this works as expected. But here’s a classic example of how browser compatibility bites you:

• In Internet Explorer 11, customElements does not exist. The script throws, and <my-greeting> is just an inert unknown tag.
• In very old versions of Edge (pre‑Chromium), you needed polyfills for custom elements v1.

If your app is enterprise‑facing and still has IE11 users on locked‑down desktops, this becomes one of the best examples of why you must ship a fallback. That fallback might be:

• Server‑rendered HTML that does not rely on custom elements at all.
• A build that includes the official webcomponents polyfills.

This is a simple case, but it’s one of the clearest examples of understanding custom web components and browser compatibility: don’t assume customElements is present unless you’ve measured your user base and set a hard browser support line.

Shadow DOM styling: best examples of “looks fine in Chrome, broken in Safari”

Shadow DOM gives you style encapsulation, which is great—until it isn’t.

Consider a <user-card> component with a shadow root:

class UserCard extends HTMLElement {
  constructor() {
    super();
    const root = this.attachShadow({ mode: 'open' });
    root.innerHTML = `
      <style>
        :host {
          display: block;
          border-radius: 8px;
          padding: 1rem;
          background: var(--card-bg, #fff);
        }
      </style>
      <slot></slot>
    `;
  }
}

customElements.define('user-card', UserCard);

In Chrome and Edge, you can style this from the outside using CSS custom properties:

user-card {

  --card-bg: #f5f5f5;
}

Now look at one of the more frustrating real examples of browser differences:

• Safari historically lagged on some advanced Shadow DOM features and still has quirks with things like :focus-visible and form controls inside shadow roots.
• Older Firefox versions had bugs around ::part and ::theme (the latter was removed from the spec).

You may see a design review where the component looks perfect in Chrome but:

• Focus outlines don’t appear in Safari.
• High‑contrast modes in Windows don’t correctly pierce the shadow tree.

That’s not just a design nitpick. From an accessibility perspective, this is a failure. The W3C’s Web Accessibility Initiative has guidance on focus indication, and components that hide focus states in certain browsers put you at risk.

This is an example of understanding custom web components and browser compatibility at the intersection of UX and a11y: you must test focus, keyboard navigation, and color contrast for shadow DOM content in multiple browsers, not just layout.

Form‑associated custom elements: modern power, uneven support

Form‑associated custom elements are one of the best examples of how fast the platform is evolving. They let you build custom controls that participate in <form> submissions:

class EmailInput extends HTMLElement {
  static formAssociated = true;

  constructor() {
    super();
    this._internals = this.attachInternals();
  }

  set value(v) {
    this._value = v;
    this._internals.setFormValue(v);
  }
}

customElements.define('email-input', EmailInput);

In current Chromium browsers, this works nicely. But as of 2024–2025:

• Firefox does not yet fully support ElementInternals and formAssociated in stable.
• Safari support is partial and can lag behind Chrome.

So you have a powerful new feature that works in some browsers and silently does nothing in others. That’s a prime example of understanding custom web components and browser compatibility where you need:

• A feature‑detection guard:

  const supportsFormAssociated = 'ElementInternals' in window &&
    'setFormValue' in ElementInternals.prototype;
  

• A graceful fallback that mirrors the value into a hidden <input> when the feature is missing.

If you don’t do this, your fancy <email-input> works in Chrome and mysteriously fails to submit values in Firefox. QA will file bugs, and users will quietly abandon forms.

Lazy‑loaded custom elements and hydration issues

Another modern example of trouble: lazy‑loading components in an app that also uses server‑side rendering.

Picture a server‑rendered marketing page with this markup already in the HTML:

<pricing-table data-plan="pro"></pricing-table>

You ship the page quickly, then load the component definition later:

import('./components/pricing-table.js');

In Chrome and Edge, the upgrade path is straightforward:

• The browser parses <pricing-table> as an unknown element.
• Once customElements.define('pricing-table', PricingTable) runs, it upgrades the existing nodes and calls connectedCallback.

So far, so good. But here’s a real example of understanding custom web components and browser compatibility that bites large apps:

• Some older browsers with polyfills have timing issues where the upgrade happens before certain attributes are set.
• If your component reads attributes in the constructor instead of connectedCallback, you can end up with missing data.

This shows up as:

• A pricing table that renders with default values on some devices.
• Flickering content as the component re‑reads attributes after hydration.

The fix is boring but reliable:

• Read DOM attributes and dataset in connectedCallback, not the constructor.
• In SSR scenarios, avoid logic in the constructor that depends on the DOM already being fully wired.

These are the kind of examples of understanding custom web components and browser compatibility that only emerge when you combine new platform features with older polyfills and real‑world performance constraints.

Framework wrappers: Lit, Stencil, and cross‑browser expectations

Most teams are not hand‑rolling everything with HTMLElement. Libraries like Lit and Stencil wrap the low‑level APIs and promise better DX. They also provide some of the best examples of how to smooth over browser differences.

Take Lit:

import { LitElement, html, css } from 'lit';

class TodoItem extends LitElement {
  static styles = css`
    :host {
      display: block;
    }
  `;

  static properties = {
    done: { type: Boolean }
  };

  render() {
    return html`
      <label>
        <input type="checkbox" .checked=${this.done} />
        <slot></slot>
      </label>
    `;
  }
}

customElements.define('todo-item', TodoItem);

Lit handles a lot of browser quirks around templating and reactivity, but it does not magically give you Shadow DOM in IE11. You still need:

• Polyfills if you care about legacy browsers.
• A clear browser support matrix in your documentation.

Stencil takes a similar approach, outputting custom elements that can be consumed by multiple frameworks. Again, real examples include:

• Teams assuming that because a Stencil component works in React and Angular, it is automatically supported in every browser those frameworks support.
• Discovering late in the project that the Shadow DOM mode chosen (shadow vs scoped) has different implications for CSS in older Safari.

These are soft but important examples of understanding custom web components and browser compatibility at the organizational level: your tooling choices set expectations for what “supported” really means.

Accessibility and ARIA: real examples where custom elements hurt users

Accessibility is where custom elements can quietly fail your users. The WAI‑ARIA Authoring Practices provide patterns for widgets like tabs, dialogs, and menus. When you wrap those patterns in custom elements, you must verify behavior in multiple browsers and assistive technologies.

Some real examples of problems teams run into:

• A <my-dialog> component that uses role="dialog" and aria-modal="true", but does not manage focus correctly in Safari with VoiceOver.
• A <fancy-select> that visually looks like a dropdown but is not keyboard‑navigable in Firefox with NVDA.

From a compatibility standpoint, the browser differences are subtle:

• Chrome + NVDA might announce your roles and labels correctly.
• Safari + VoiceOver might require additional ARIA attributes or different focus management.

These are powerful examples of understanding custom web components and browser compatibility because they show that “it works in my browser” is not enough. You need to test:

• Keyboard navigation across browsers.
• Screen reader output on at least one Windows stack and one macOS stack.

The payoff is not just legal compliance; it’s a wider audience for your app.

Performance and long‑tail devices: when custom elements feel slow

Another angle: performance. Custom elements are native APIs, but that doesn’t guarantee fast startup on low‑end devices.

Consider a dashboard that renders hundreds of <data-card> components. In Chrome on a desktop, everything feels instant. But on a low‑power Android phone running an older Chromium build, you might see:

• Long scripting time spent in constructors and connectedCallback.
• Layout thrashing when each component measures itself.

This is yet another example of understanding custom web components and browser compatibility: the same code path can behave very differently on mobile browsers with weaker CPUs and older JS engines.

Mitigations include:

• Avoid heavy work in constructors; defer to connectedCallback and batch DOM reads/writes.
• Use IntersectionObserver to lazily initialize off‑screen components, but test that behavior in Safari, which has had quirks and bugs in certain versions.

The key is to profile on real devices, not just your MacBook.

Testing strategy: turning examples into a compatibility checklist

All these stories are interesting, but they only help if you turn them into a testing habit. When you look at examples of understanding custom web components and browser compatibility, common themes emerge:

• Feature detection over browser sniffing.
• Graceful degradation when a feature is missing.
• Real‑device and assistive‑tech testing.

A practical approach looks like this in day‑to‑day work:

• Every time you adopt a new Web Components feature (like ElementInternals or declarative shadow DOM), you write a tiny example of that feature in isolation and test it in your target browsers.
• You keep a living support matrix in your repo (even a simple Markdown table) that records what you’ve verified.
• You monitor browser release notes and MDN’s Web Components docs for changes that might affect your components.

By turning scattered real examples into a habit, you avoid shipping surprises.

FAQ: examples of common Web Components compatibility questions

Q: Can you give examples of custom web components that are safe to use in all modern browsers?
Yes. Simple presentational components that avoid advanced features are generally safe. For instance, a <page-section> that just wraps content with a shadow root and static styles tends to behave consistently in current Chrome, Edge, Firefox, and Safari. The fewer platform‑edge features you rely on (like form association or declarative shadow DOM), the more consistent your cross‑browser story.

Q: What is an example of a feature I should avoid if I care about older browsers?
Form‑associated custom elements are a clear example. If you rely entirely on ElementInternals and formAssociated without a fallback, your forms will misbehave in browsers that lack support. A safer pattern is to pair the custom element with a hidden native input, so older browsers still submit data correctly.

Q: How do I test real examples of understanding custom web components and browser compatibility efficiently?
Start with automated tests using tools like Web Test Runner or Playwright to verify basic behavior across multiple engines. Then add a manual checklist for edge cases: focus management, keyboard navigation, high‑contrast mode, and slow‑network behavior. The goal is not to test everything on every commit, but to regularly validate representative examples in your priority browsers.

Q: Are polyfills still worth it in 2024–2025?
For many consumer apps, the answer is increasingly no—you can set a modern baseline and drop IE11 entirely. For enterprise or government apps with strict support requirements, polyfills for custom elements and Shadow DOM may still be necessary. Evaluate your analytics and regulatory obligations before deciding. The examples in this article should help you reason about where polyfills meaningfully improve user experience.

Q: Where can I find more technical details about Web Components behavior?
MDN’s Web Components documentation is a reliable reference, and the W3C specifications for HTML and Shadow DOM define the underlying behavior. These sources complement the practical examples of understanding custom web components and browser compatibility discussed here by grounding your work in the actual standards.

The big picture: custom elements are no longer experimental toys. They’re part of the everyday toolkit for front‑end engineers. But the best examples of successful projects all share the same pattern: they treat browser compatibility as a design constraint, not an afterthought. If you build small examples first, test them in the browsers your users actually run, and keep an eye on evolving specs, your custom components will hold up in 2025 and beyond.