DEV Community: Danny Engelman

Web Components did not fail!

Danny Engelman — Thu, 08 Oct 2026 09:52:55 +0000

My comment to yesterdays Dev.to post: Web components failed. We can fix them became a full post:

TL;DR:

Web Components never failed.
Browser vendors have used Web Component-based architecture for decades.
Yet developers keep building apps, inventing frameworks, and adding dependencies instead of embracing the platform.

Build apps with frameworks. Build components with Web Components.

The technology isn't the problem. Our mindset is.

From the comments:

The line about every <video> being proof really stuck with me.
I swapped a framework-tied date picker for a Web Component a while back.
And it's the only piece that survived two framework migrations untouched.

Web Components Never Failed

Web Component history

The Web Component story didn't start with today's Custom Elements.

Almost 28 years ago, in 1998, Microsoft proposed HTML Components (HTC):

https://www.w3.org/TR/NOTE-HTMLComponents

In 2006, Mozilla took its own stab at componentizing the Web with XBL, first developed for Mozilla and later proposed as a specification:

https://www-archive.mozilla.org/projects/xbl/

Different technologies, different APIs — but the same underlying desire:

Make pieces of the Web reusable, encapsulated, and programmable.

Your Web Browser serves you Web Components...
on every Web page!

Browser vendors have been using Web Component machinery for many moons longer than we mortal developers have had today's standardized Web Components APIs.

To Us, Modern Web Components became broadly available roughly around:

Chrome 2016 · Safari 2017 · Firefox 2018 · Edge 2020

But browsers themselves have always had that same problem to solve:

The WHATWG specifies what an HTML element should do.
Browser vendors still have to decide how to build it.

Take a complex native element such as:

<input>

<textarea>

<video>

From the developer's perspective, that's one element.

Underneath, there may be an entire internal UI: buttons, sliders, labels, tracks, controls and state.

That should sound familiar.

It is the same Web Component technology us mortal developers use!

With the appropriate DevTools settings, browsers can expose these internal shadowDOM trees for inspection.

`<video>` with sahdowDOM in Chromium

`<video>` with shadowDOM in Firefox

They're not your DOM to manipulate.

They're implementation details.

And that's precisely the point.

Web Components did NOT fail

So saying:

"Web Components failed."

has always sounded a little strange to me.

We interact with componentized browser <input> UI every single day.

The browser platform itself demonstrates why encapsulated components are useful.

The question isn't whether components work.

The interesting question is:

Why don't we build more of our own software that way?

Mortal developers and Web Components

I think part of the problem is that we keep thinking in Apps.

Frameworks encourage that.

They scaffold applications.

They give us routing, state management, rendering systems, build pipelines, dependency graphs and application architecture.

And that's perfectly fine when you're building an application.

But:

Frameworks scaffold Apps.

and

Components are components.

A component doesn't necessarily need to know anything about your application.

A <date-picker> doesn't care whether the surrounding application uses React, Vue, PHP, Django or plain HTML. Or the car is painted red.

A <relative-time> shouldn't need to know either.

Neither should:

<car-tire>
<steering-wheel>
<playing-card rank="Queen" suit="Hearts"></playing-card>
<mark-down src="playing-card-component-usage.md"></mark-down>

They should just work!

We are still building Apps like it's 1899

There's another problem.

Many developers learned one particular way of building software and then taught those patterns to coworkers, and — directly or indirectly — to AI.

So AI happily reproduces them — and teaches the next generation that this is simply how software is built.

Ask AI to build something and you'll often get an entire application architecture when what you actually needed was:

<something-useful>

The tool isn't necessarily wrong.

We're asking it to build the wrong thing.

That's a mindset change.

Change your perspective from:

Everything is an App

to:

Apps with frameworks. Components with Web Components.

There are Henry Fords out there already working differently.

And I suspect some of them aren't shouting about it.

Why would they?

Once you've trained your tools — and your AI — to produce small, independent components instead of miniature applications, it can become a competitive advantage.

"I can do Web Components better!"

In 2022 there were already around 60 Frameworks, Libraries and BaseClasses listed in:

I-can-do-Web-Components-better (aka All the ways to make a Web Component)

Sixty!

And here's where I think we repeatedly take the wrong turn.

You discover Web Components
You develop a few helper functions
Then: Oh, it needs this feature...
Then another feature
And another
Soon you've created conventions
Then abstractions
Then dependencies
Then documentation

Congratulations!

You're building a framework (or a Design System)
And your ego just publsihed it to NPM

Instead, write the abstractions you need for your components.

They don't have to become somebody else's architecture.
They don't even have to be shared abstractions in your components.
Duplicate your code! Something every "guru" developer told you not to do. A well trained AI is great at managing those.

What about (Google) Lit?

Yes, I consider Lit a framework.

It provides its own abstractions for rendering, reactivity and component state.

That's useful if that's how you want to work.

But it's not the only way to build Web Components.

You don't have to write Lit's HTML template blobs.

The DOM already has an API.

document.createElement("button")

isn't primitive.

It's powerful.

You have the entire browser platform underneath you.

Use it.

Write a one line helper function (sell it to your PM as a mini-Framework)

const createElement = (tag,props={}) => 
                       Object.assign(document.createElement(tag),props);

And you are really using the platform!

Note: That "guru" developer in your team now tells you to make this a library you can import.

Don't! You are creating a dependency!
Use AI to manage your code! It is an AI skill

customElements.define("the-obligatory-counter", class extends HTMLElement {
    constructor() {
        super() // sets and returns this scope
            .attachShadow({ mode: "open" }) // sets and returns this.shadowRoot
            .append(
                createElement("button", {
                    part: "plus button",
                    textContent: "-",
                    onclick: evt => this.count--
                }),
                this._count = createElement("count-value", {
                    part: "count value",
                    textContent: 0
                }),
                createElement("button", {
                    part: "min button",
                    textContent: "+",
                    onclick: evt => this.count++
                })
            )
    }
    set count(val) {
        this._count.textContent = val;
    }
    get count() {
        return ~~this._count.textContent;
    }
})

Developing Web Components

Develop Web Components like you use .reduce():

No developer ever told you that you must use it exactly like they do.

That's the freedom Web Components give us.

There doesn't have to be one architecture.

There doesn't have to be one framework.

There doesn't have to be one correct abstraction.

Build the component.

Give it a useful API.

Let the browser do the rest.

So:

Web Components never failed.

Maybe we just haven't learned how to use them yet.

Browser vendors already showed us how.

Every <input>, <video> and <textarea> is proof that complex functionality can live behind one simple HTML element.

If Browser vendors can do it. Why can't we?

Web Components without JavaScript?!

Danny Engelman — Tue, 16 Sep 2025 13:34:46 +0000

You can replace all `<div></div>`

with `<tag-name></tag-name>`

(since 2018) ANY tagname with a dash is a valid `HTMLElement`

Let me repeat that for clarity:

👉 ANY 🤯 tagname with a dash is a valid `HTMLElement`

NOT `HTMLUnknownElement` as some claim

That means you can replace EVERY <div> with valid HTML

Then this DIV-soup:

Becomes valid HTML:

🧠 Good to know

✅ Absolutely NO JavaScript required, its only HTML and CSS

✅ This is standard behaviour in all browsers since 2020
(When Microsoft Edge switched to the Chromium Engine)
and already in Chrome, Safari, Firefox many moons before 2020

✅ The W3C HTML Validator accepts all <tag-name> Custom Elements with a dash as HTMLElement.
It does not accept <tagname> (no dash), those are HTMLUnknownElement

✅ The UA - UserAgent StyleSheet (Browsers default stylesheet)
defines CSS [hidden] { display:none }.
But Custom Elements do not inherit the default stylesheet;
so you have to add that behaviour yourself in your stylesheet.

✅ <DIV> is display:block only in the UA StyleSheet
You have to set 𝙙𝙞𝙨𝙥𝙡𝙖𝙮: 𝙗𝙡𝙤𝙘𝙠 / 𝙞𝙣𝙡𝙞𝙣𝙚-𝙗𝙡𝙤𝙘𝙠; on these Custom Elements yourself
(You will forget this 20 times, then you never make the mistake again)

✅ The CSS :𝙙𝙚𝙛𝙞𝙣𝙚𝙙 pseudo selector targets standard HTML tags and JavaScript defined Custom Elements

✅ Thus the CSS :𝙣𝙤𝙩(:𝙙𝙚𝙛𝙞𝙣𝙚𝙙) pseudo selector targets the 𝙪𝙣𝙙𝙚𝙛𝙞𝙣𝙚𝙙 Custom Elements; they are still valid HTMLElement, CSS applies like any element

✅ <you-are-not-bound-to-one-dash>

✅ Declarative ShadowDOM:
<template shadowrootmode="open"> creates undefined Custom Elements with a shadowDOM

✅ The Custom Elements API (MDN) requires JavaScript to convert undefined Custom Elements (but valid HTMLElement!) into defined Custom Elements.

🎉🎉🎉

No more hunting for that closing `</div>` tag

`</tag-name>` is just there!

Are they Web Components?

Technologies NOT used:

<template>
shadowDOM
Custom Elements API (create defined elements with JavaScript)

🛠 Prove ANY tagname with a dash IS a `HTMLElement`

for:

        <div></div>
        <tagname></tagname>
        <tag-name></tag-name>
        <tag-name-foo></tag-name-foo>
        <tag-name-bar></tag-name-bar>

NO MORE DIV-SOUP!

✅ If you believe AI over a random Dev.to post:

Note: every evergreen browser knows what a Custom Element is, just ask yourself:

(after reading: https://web.dev/articles/declarative-shadow-dom)

What happens with <tag-name>, and CSS applied, when you omit the <template>?

<tag-name>
  <template shadowrootmode="open">
  </template>
</tag-name>

Using HTML to its full extend

Danny Engelman — Wed, 06 Aug 2025 09:19:02 +0000

After writing HTML for 31 years

I switched from writing DIV-soup:

<div class="article-header">Hello, sad man</div>

to writing Semanctic HTML:

<article-header>Hello, happy man</article-header>

No JavaScript required!

Only CSS required, to replicate DIV block behaviour

article-header {
  display:block;
}

This works,
because modern browsers treat a <tag-name> (with a dash) as a valid HTMLElement

Also read: https://dev.to/dannyengelman/not-a-div-insidein-sightsite-18lj

Web Components - the untold story

Danny Engelman — Mon, 04 Aug 2025 18:56:18 +0000

In the mid-1990s, long before the era of React and Angular, the seeds of componentized web UI were already being sown:

Microsoft’s “HTML Components” (HTCs) for Internet Explorer 4 (circa 1997) let you define reusable widgets in HTML, CSS, and JScript—living in .htc files and attached via behavior:url(...). It was clunky, Windows-only, and plagued by cross-browser woes, but it proved the allure of packaged, reusable UI.

A few years later, Mozilla experimented with XBL (XML Binding Language) in Firefox 1.0 (2004). XBL let you declare new tags in XML, bind them to scripts and styles, and even override native widget behavior. Again, powerful—but complex, tied to the browser’s internals, and ultimately never standardized.

2011: Alex Russell’s Amsterdam Lightbulb Moment

At a crisp autumn conference in Amsterdam, Googler Alex Russell took the stage with a simple yet radical vision:

“What if we let authors define their own elements—HTML tags—with their own markup, styles, and behavior—natively in the browser?”

He sketched out four core primitives—Custom Elements, Shadow DOM, HTML Imports, and HTML Templates—that together would let web developers build encapsulated, reusable widgets without frameworks.

Fast Forward to: 38m :"Web Components and Model driven Views"
Be aware the presented syntax totally changed when implemented as Web Components V1!

Browser Vendors Eat Their Own Dog Food

Fast-forward a few years, and these primitives were battle-tested inside the browsers themselves:

<select> controls, with their dropdowns, keyboard handling, and focus rings, were refactored atop Shadow DOM to isolate complex internals.
<video> and <audio> players, complete with controls, timelines, and captions, too—each browser shipping its own custom element sealed behind a protective Shadow Root.
Even form controls like <input type="date"> and <progress> leverage these same technologies under the hood.

By using component tech for their standard tags, browser vendors proved the performance, security, and maintainability benefits of encapsulation—and gave developers a live demo of Shadow DOM and Custom Elements in action.

And then the Browser vendors opened up the technology to us mortal developers. But not as you might know it.

EVERY `<tag-name>` Is a Custom Element

Here’s the kicker: any valid HTML tag name containing a dash—for example <user-card>, <app-nav>, or even <weather-widget>—is already a fully-fledged HTMLElement:

It parses, lays out, and styles just like <div> or <span>.
It participates in the CSS cascade and can be targeted with selectors:

  weather-widget { display: block; border: 1px solid #ccc; }

It reserves the namespace so you’ll never conflict with a future standard tag.

That means you can immediately start structuring your markup semantically—replacing generic <div>s with <site-header>, <product-list>, <chat-bubble>, etc.—and style them purely with CSS.

Absolutly NO JavaScript required to get the semantic and style benefits of “components.”

Do remember to set display:block (default on a <div>) yourself!

The Takeaway

From Microsoft HTCs to Mozilla XBL, from Alex Russell’s talk in Amsterdam to the browser-built <select> and <video> controls, the Web Components idea has been decades in the making.

Today, ANY custom tag name is a native HTMLElement. You don’t need JavaScript to reap immediate gains in readability, maintainability, and style encapsulation—just start writing HTML and CSS with meaningful tag names.

The era of “div-soup” is finally over!

Well... has been for nearly a decade now.

And you might not want to pay for a "Web Components" course, that starts with a JavaScript example.

Also read: https://dev.to/dannyengelman/not-a-div-insidein-sightsite-18lj

Example replacing the DIV-soup

This DIV-soup:

Without using any JavaScript!

Becomes valid HTML:

Your first Web Component (without JavaScript)

Danny Engelman — Wed, 23 Jul 2025 09:45:07 +0000

Change your CSS grid definition:

to:

and you are done writing your first Custom Element/Web Component

No more hunting for that closing </div>

YES! any tagname with a (-) dash in the name is a valid HTMLElement

Also see: https://dev.to/dannyengelman/not-a-div-insidein-sightsite-18lj

Not a DIV inside / in sight / in site

Danny Engelman — Fri, 18 Jul 2025 09:00:59 +0000

TL;DR;

You can replace all <div></div> with <tag-name></tag-name>

Later written blogposts:

(Nov 2025) https://matthewjamestaylor.com/div-custom-elements

ANY `<tag-name>` with a dash is a valid `HTMLElement`

Let me repeat that for clarity:

👉 ANY 🤯 `<tag-name>` with a dash is a valid `HTMLElement`

NOT `HTMLUnknownElement` as some claim

That means you can replace EVERY <div> with valid HTML

Then this DIV-soup:

Becomes valid HTML:

🧠 Good to know

✅ Absolutely NO JavaScript required, it is only HTML and CSS

✅ This is standard behaviour in all browsers.
Chrome (2016) Safari (2017) FireFox (2018) Edge (2020)

✅ The W3C HTML Validator accepts all <tag-name> Custom Elements with a dash as HTMLElement.
It does not accept <tagname> (no dash), those are HTMLUnknownElement

✅ Custom Elements do not inherit the standard [hidden] behaviour;
so you have to add that behaviour yourself in your stylesheet.

✅ Same for <DIV> display:block. You have to set 𝙙𝙞𝙨𝙥𝙡𝙖𝙮: 𝙗𝙡𝙤𝙘𝙠 / 𝙞𝙣𝙡𝙞𝙣𝙚-𝙗𝙡𝙤𝙘𝙠; on these Custom Elements yourself
(You will forget this 20 times, then you never make the mistake again)

✅ The CSS :𝙙𝙚𝙛𝙞𝙣𝙚𝙙 pseudo selector targets standard HTML tags and JavaScript defined Custom Elements

✅ <you-are-not-bound-to-one-dash>

✅ Declarative ShadowDOM:
<template shadowrootmode="open"> creates the same undefined Custom Elements with a shadowDOM

✅ The Custom Elements API (MDN) requires JavaScript to convert undefined Custom Elements (but valid HTMLElements!) into defined Custom Elements.

🎉🎉🎉

No more hunting for that closing `</div>` tag

`</tag-name>` is just there!

Repetition is always great

✅ Absolutely NO JavaScript required, its only HTML and CSS

Are they Web Components?

Technologies NOT used:

<template>
shadowDOM
Custom Elements API (create defined elements with JavaScript)

🛠 Prove ANY tagname with a dash IS a `HTMLElement`

for:

        <div></div>
        <tagname></tagname>
        <tag-name></tag-name>
        <tag-name-foo></tag-name-foo>
        <tag-name-bar></tag-name-bar>

NO MORE DIV-SOUP!

✅ If you believe AI over a random Dev.to post:

Note: every evergreen browser knows what a Custom Element is, just ask yourself:

(after reading: https://web.dev/articles/declarative-shadow-dom)

What happens with <tag-name>, and CSS applied, when you omit the <template>?

<tag-name>
  <template shadowrootmode="open">
  </template>
</tag-name>

AI beaten by a Web Component

Danny Engelman — Sat, 14 Jun 2025 10:34:27 +0000

I submitted my Stack Overflow Challenges "cipher" entry

https://stackoverflow-challenges.github.io/cipher/index.html

The cipher is about black rook moves creating a Letter pattern on a chessboard. White pieces can not be captured.

Can you see what pixelated letter is on this board?

ChatGPT: What squares can the black rooks goto? Then what is the pixelated letter? White pieces can not be captured

it... eventually... comes up with the wrong answer:

Clear for every human:

AI is cool, but it ain't intelligent

Web Component

Danny Engelman — Thu, 16 Jan 2025 10:31:57 +0000

Sorry, I don't have the time to write an extensive blog post.

Then again, a good Web Component should explain itself.

More docs: https://language-select.github.io/

After loading the Web Component, all HTML required is:

<language-select caption="Select a language" 
                 selected="en" 
                 languages="en,nl,es,pt,jp,sk"></language-select>

My 1 year old GPT: Web Component Creator - is free source now

Danny Engelman — Wed, 25 Dec 2024 16:40:29 +0000

Requirements

an OPENAI Plus (or more) account
Knowing how to copy-paste text

My online GPT is at:
https://chatgpt.com/g/g-quK0nMtwZ-web-component-creator-vanilla-javascript

How to create your own ChatGPT

► Click Explore GPTs in the left bar:

► Click create in the top-right:

► Copy these GPT instructions: (select-all -> copy)
Make any changes you want

Set Title, Description and (above) Instructions

► Save

Share you knowledge

I am not asking any money for this. If you make cool changes let them know in the comments

:nth-child builder in a Web Component

Danny Engelman — Fri, 13 Dec 2024 13:37:14 +0000

Just a quick prototype.

It is more about the source code than the visual result

Better viewed at: https://nth-children.github.io

<nth-children cellcount="20" smile="🤪" columns="5"></nth-children>

Show favicon over A href link with a Web Component

Danny Engelman — Thu, 12 Dec 2024 09:24:14 +0000

After my previous longer blogpost Make It Snow!,
time for a smaller code-sized Web Component.

This blogpost: Using a CSS cursor to show the external link Favicon

converted to a <show-favicon> (Vanilla JavaScript) Web Component:

[open the Result tab of this JSFiddle and hover over a link]

That setTimeout explained:
Web Component developers do not connect with the connectedCallback (yet)

Web Components? Make it so!

Danny Engelman — Thu, 05 Dec 2024 17:03:52 +0000

written: December 2024

Zach his <snow-fall> Web Component

Is a single <snow-fall> Web Component creating 200 snow-ball DIVs falling down the screen.

Which made me wonder...

...

What if instead of ONE Web Component...

... each snowball would be a unique <snow-flake>?

... How many <snow-flake> Components can my CPU handle?

https://make-it-snow.github.io/

GitHub source code

<make-it-snow> Web Component

an experiment in more and more Web Components

Every snowflake is a unique Web Component <snow-flake> with an SVG image.
Snowflakes are animated with CSS to fall down rotating and drift sideways.
Snowflakes are removed from the DOM when they reach the bottom of the screen (onanimationend).
Instead of a fixed amount of snowflakes more snowflakes are added every second.
CSS animation FPS (Frames Per Second) is tracked. When FPS is above a threshold more new snowflakes (Web Components) are added at the top of the screen (5 more every second). Below the treshold less snowflakes are added.

FPS can be changed with UP and DOWN arrow keys (once a second, hold down CTRL for 10x).

On my slow? system I get an equilibrium at around 400 total snowflakes on screen:

https://make-it-snow.github.io/

GitHub source code

Creating a unique SVG snowflake

Create one "spike" from 3 SVG paths with random width and opacity

<g id="spike">
    ["M70 70v-60", 
    "M45 28l25 18l28-16", 
    "M50 11l20 20l20-20"]
    .map( (dpath) => {
        let width = random(3 , 9);
        let opacity = random(0.2 , 1);
        return `<path opacity="${opacity}" stroke-width="${width}" d="${dpath}"/>`;
    })
</g>

Rotate each spike 4,6 or 8 times

Array(spikecount - 1) // from random([4,6,8])
.fill(360 / spikecount) // calculate degrees offset for each spike
.map((degrees, idx) => {
    let spikerotation = (idx + 1) * degrees; // all spikes make up a snowflake
    // every snowflake is in a shadowDOM, so its save to reference ID values!!
    return `<use href="#spike" transform="rotate(${spikerotation} 70 70)"/>`;
})

That will create all unique SVG snowflakes:

https://make-it-snow.github.io/

GitHub source code

URL parameters and Attributes

The <make-it-snow> Web Component can be configured with URL parameters or Attributes. Also see index.html Page Source.

URL examples

https://make-it-snow.github.io/?flakecount=400 (already too much for my system)
https://make-it-snow.github.io/?maxflakes=100
https://make-it-snow.github.io/?size=4&spikecount=4&color=gold&speed=2
https://make-it-snow.github.io/?fps=60
60 is the default Browser FPS
https://make-it-snow.github.io/?fps=1
Will this get us the most snowflakes? And terrible "animation"!
https://make-it-snow.github.io/?counters=no&quotes=no Cleaner UI
https://make-it-snow.github.io/index.html?fps=10&quotes=no&size=20 -
Interesting, this make the H1 and H2 at higher z-index flicker

parameters

URL parameters only

Parameter	Description	Default Value
`flakecount`	Number of snow flakes to start with	`300`
`addflakes`	Number of snow flakes to add every second	`20`
`maxflakes`	A treshold when not to add more `<snow-flake>`	`1000`
`fps`	FPS threshold, change with (ctrl) arrow up/down keys	`30`
`minstrokewidth`	minimal SVG path width	`3`
`maxstrokewidth`	maximum SVG path width	`3`

<snow-flake> Attributes OR URL parameters

See https://make-it-snow.github.io/index.html page source

Attribute	Description	Default Value
`color`	(string/csv) snowflake color	random[internal colors]
`size`	(decimal) snowflake size	2
`rotate`	(int) initial start state	`90`
`spikecount`	(int/array) number of snowflake spike	`[4,6,8]`
`speed`	(int) fall down speed (seconds)	`[4 - 12]`
`drift`	(int) sideways motion	`[-5 - 5]`
`size`	default size	`1`
`opacity`	default opacity	`1`
`cssrotation`	CSS rotation	`random(-360,360)`

https://make-it-snow.github.io/

GitHub source code

Observations

Feel free to add more in the comments

300 <snow-flake> are 3 STYLE elements + 1 SVG in a shadowDOM
That is 5 DOM elements for every <snow-flake>
I did not do much animation optimization. Feel free to suggest low hanging fruit
CSS will-change:transform (or not) doesn't seem to have a notable effect
Its all CSS animation, I wonder what a fullscreen SVG with SMIL animation would do (requires some refactoring)
I now re-create a <snow-flake>; wonder what happens when every new snowflake will also become a totally new Web Component <snow-flake-[nr]>. Since we can not uncreate Web Components, will the customElementRegistry eventually cause a Stack Overflow error?

DEV Community: Danny Engelman

Web Components did not fail!

TL;DR:

Web Components Never Failed

Web Component history

Your Web Browser serves you Web Components... on every Web page!

<video> with sahdowDOM in Chromium

<video> with shadowDOM in Firefox

Web Components did NOT fail

Mortal developers and Web Components

We are still building Apps like it's 1899

"I can do Web Components better!"

What about (Google) Lit?

Developing Web Components

Web Components never failed.

Web Components without JavaScript?!

You can replace all <div></div>

with <tag-name></tag-name>

(since 2018) ANY tagname with a dash is a valid HTMLElement

👉 ANY 🤯 tagname with a dash is a valid HTMLElement

NOT HTMLUnknownElement as some claim

Then this DIV-soup:

Becomes valid HTML:

🧠 Good to know

🎉🎉🎉

No more hunting for that closing </div> tag

</tag-name> is just there!

Are they Web Components?

🛠 Prove ANY tagname with a dash IS a HTMLElement

NO MORE DIV-SOUP!

Using HTML to its full extend

Web Components - the untold story

2011: Alex Russell’s Amsterdam Lightbulb Moment

Browser Vendors Eat Their Own Dog Food

EVERY <tag-name> Is a Custom Element

The Takeaway

The era of “div-soup” is finally over!

Example replacing the DIV-soup

This DIV-soup:

Becomes valid HTML:

Your first Web Component (without JavaScript)

Not a DIV inside / in sight / in site

TL;DR;

Later written blogposts:

ANY <tag-name> with a dash is a valid HTMLElement

👉 ANY 🤯 <tag-name> with a dash is a valid HTMLElement

NOT HTMLUnknownElement as some claim

Then this DIV-soup:

Becomes valid HTML:

🧠 Good to know

🎉🎉🎉

No more hunting for that closing </div> tag

</tag-name> is just there!

Repetition is always great

Are they Web Components?

🛠 Prove ANY tagname with a dash IS a HTMLElement

NO MORE DIV-SOUP!

AI beaten by a Web Component

ChatGPT: What squares can the black rooks goto? Then what is the pixelated letter? White pieces can not be captured

Clear for every human:

AI is cool, but it ain't intelligent

Web Component

More docs: https://language-select.github.io/

My 1 year old GPT: Web Component Creator - is free source now

Requirements

How to create your own ChatGPT

Share you knowledge

:nth-child builder in a Web Component

Show favicon over A href link with a Web Component

Web Components? Make it so!

Zach his <snow-fall> Web Component

Which made me wonder...

What if instead of ONE Web Component...

... each snowball would be a unique <snow-flake>?

... How many <snow-flake> Components can my CPU handle?

<make-it-snow> Web Component

an experiment in more and more Web Components

Creating a unique SVG snowflake

Create one "spike" from 3 SVG paths with random width and opacity

Rotate each spike 4,6 or 8 times

Your Web Browser serves you Web Components...
on every Web page!

`<video>` with sahdowDOM in Chromium

`<video>` with shadowDOM in Firefox

You can replace all `<div></div>`

with `<tag-name></tag-name>`

(since 2018) ANY tagname with a dash is a valid `HTMLElement`

👉 ANY 🤯 tagname with a dash is a valid `HTMLElement`

NOT `HTMLUnknownElement` as some claim

No more hunting for that closing `</div>` tag

`</tag-name>` is just there!

🛠 Prove ANY tagname with a dash IS a `HTMLElement`

EVERY `<tag-name>` Is a Custom Element

ANY `<tag-name>` with a dash is a valid `HTMLElement`

👉 ANY 🤯 `<tag-name>` with a dash is a valid `HTMLElement`

NOT `HTMLUnknownElement` as some claim

No more hunting for that closing `</div>` tag

`</tag-name>` is just there!

🛠 Prove ANY tagname with a dash IS a `HTMLElement`