Danny Engelman 🌷🏍️🛥️
@engelman.nl
I do modern Web Component Development with technologies supported by **all** WHATWG partners (Apple, Google, Microsoft & Mozilla)
👨🏻💻TRS-80 Scriptkiddie '79+
🎓 Computer Science '87 - '92
❤️ Online since 1990 yes! 1990 I started with Email and Gopher
👨🏻💻TRS-80 Scriptkiddie '79+
🎓 Computer Science '87 - '92
❤️ Online since 1990 yes! 1990 I started with Email and Gopher
> too lazy
Its dumping your code into ONE connectedCallback method and fixing some DOM creation
Took me maybe 10 minutes
I then refactored it, still as an experiment keeping all code in ONE Method
But mainly focussing on my own Web Components displaying a starter page
HTH
image-reveal.github.io
Its dumping your code into ONE connectedCallback method and fixing some DOM creation
Took me maybe 10 minutes
I then refactored it, still as an experiment keeping all code in ONE Method
But mainly focussing on my own Web Components displaying a starter page
HTH
image-reveal.github.io
November 5, 2025 at 12:02 PM
> too lazy
Its dumping your code into ONE connectedCallback method and fixing some DOM creation
Took me maybe 10 minutes
I then refactored it, still as an experiment keeping all code in ONE Method
But mainly focussing on my own Web Components displaying a starter page
HTH
image-reveal.github.io
Its dumping your code into ONE connectedCallback method and fixing some DOM creation
Took me maybe 10 minutes
I then refactored it, still as an experiment keeping all code in ONE Method
But mainly focussing on my own Web Components displaying a starter page
HTH
image-reveal.github.io
Carcassonne is easier with a rotating fixed size square layout in a CSS grid, where rows and columns are added Top-Bottom-Left-Right
Dominos probably requires masonry (not supported in a browser yet)
Maybe next weeks team Web Component challenge; we did Ludo once; all NAMED slots and CSS grid-area
Dominos probably requires masonry (not supported in a browser yet)
Maybe next weeks team Web Component challenge; we did Ludo once; all NAMED slots and CSS grid-area
October 31, 2025 at 4:29 PM
Carcassonne is easier with a rotating fixed size square layout in a CSS grid, where rows and columns are added Top-Bottom-Left-Right
Dominos probably requires masonry (not supported in a browser yet)
Maybe next weeks team Web Component challenge; we did Ludo once; all NAMED slots and CSS grid-area
Dominos probably requires masonry (not supported in a browser yet)
Maybe next weeks team Web Component challenge; we did Ludo once; all NAMED slots and CSS grid-area
.childNodes creates way too many <slot> elements.
Multiple <slot> can be used
But ONE unnamed <slot> can be enough,
.assign (can process a NodeList) sets the order.
But sorting is maybe not the best example for manual slot-assignment;
I keep lightDOM sort in lightDOM (2nd screenshot)
Multiple <slot> can be used
But ONE unnamed <slot> can be enough,
.assign (can process a NodeList) sets the order.
But sorting is maybe not the best example for manual slot-assignment;
I keep lightDOM sort in lightDOM (2nd screenshot)
October 31, 2025 at 11:38 AM
.childNodes creates way too many <slot> elements.
Multiple <slot> can be used
But ONE unnamed <slot> can be enough,
.assign (can process a NodeList) sets the order.
But sorting is maybe not the best example for manual slot-assignment;
I keep lightDOM sort in lightDOM (2nd screenshot)
Multiple <slot> can be used
But ONE unnamed <slot> can be enough,
.assign (can process a NodeList) sets the order.
But sorting is maybe not the best example for manual slot-assignment;
I keep lightDOM sort in lightDOM (2nd screenshot)
And we loaded software using our fingers from cool stacks of that printed stuff... what was it called... ah yeah, magazines... paper? was it?
Those frontpages really looked cool in the erly 80s!
I checked out some Web Components course frontpages just the other day... very inspirational... not
Those frontpages really looked cool in the erly 80s!
I checked out some Web Components course frontpages just the other day... very inspirational... not
October 28, 2025 at 12:36 PM
And we loaded software using our fingers from cool stacks of that printed stuff... what was it called... ah yeah, magazines... paper? was it?
Those frontpages really looked cool in the erly 80s!
I checked out some Web Components course frontpages just the other day... very inspirational... not
Those frontpages really looked cool in the erly 80s!
I checked out some Web Components course frontpages just the other day... very inspirational... not
> Note: Living HTML also knows Custom Elements
> Custom Elements are not countable and should be ignored
Custom Elements are countable, start at 1 and keep going
WITHOUT JavaScript!
Any (with a dash) IS a valid HTMLElement,
not HTMLUnknowElement as some claim.
dashed-html.github.io
> Custom Elements are not countable and should be ignored
Custom Elements are countable, start at 1 and keep going
WITHOUT JavaScript!
Any
not HTMLUnknowElement as some claim.
dashed-html.github.io
October 24, 2025 at 9:41 AM
> Note: Living HTML also knows Custom Elements
> Custom Elements are not countable and should be ignored
Custom Elements are countable, start at 1 and keep going
WITHOUT JavaScript!
Any (with a dash) IS a valid HTMLElement,
not HTMLUnknowElement as some claim.
dashed-html.github.io
> Custom Elements are not countable and should be ignored
Custom Elements are countable, start at 1 and keep going
WITHOUT JavaScript!
Any
not HTMLUnknowElement as some claim.
dashed-html.github.io
One issue, your code will only work when the Web Component is defined AFTER all DOM was parsed,
because the connectedCallback fires on the OPENING tag.
Thus when you define your Web Component EARLY (to prevent FOUCs) there is no innerHTML
JSFiddle and link to blogpost:
jsfiddle.net/WebComponent...
because the connectedCallback fires on the OPENING tag.
Thus when you define your Web Component EARLY (to prevent FOUCs) there is no innerHTML
JSFiddle and link to blogpost:
jsfiddle.net/WebComponent...
October 22, 2025 at 7:42 AM
One issue, your code will only work when the Web Component is defined AFTER all DOM was parsed,
because the connectedCallback fires on the OPENING tag.
Thus when you define your Web Component EARLY (to prevent FOUCs) there is no innerHTML
JSFiddle and link to blogpost:
jsfiddle.net/WebComponent...
because the connectedCallback fires on the OPENING tag.
Thus when you define your Web Component EARLY (to prevent FOUCs) there is no innerHTML
JSFiddle and link to blogpost:
jsfiddle.net/WebComponent...
Sigh... no education...
October 21, 2025 at 8:48 AM
Sigh... no education...
If native elements had part attributes in shadowDOM
I might have agreed with you, partially
shadowDOM on native elements is weird, 𝘱𝘴𝘦𝘶𝘥𝘰???
AI even answers with code you can NOT execute:
I might have agreed with you, partially
shadowDOM on native elements is weird, 𝘱𝘴𝘦𝘶𝘥𝘰???
AI even answers with code you can NOT execute:
October 19, 2025 at 9:21 AM
If native elements had part attributes in shadowDOM
I might have agreed with you, partially
shadowDOM on native elements is weird, 𝘱𝘴𝘦𝘶𝘥𝘰???
AI even answers with code you can NOT execute:
I might have agreed with you, partially
shadowDOM on native elements is weird, 𝘱𝘴𝘦𝘶𝘥𝘰???
AI even answers with code you can NOT execute:
attachShadow sets ands return this.shadowRoot
and append( ) (not available in IE) is a whole lot more versatile than oldskool appendChild( )
If you then add a 1 line framework
You end up with vanilla code:
and append( ) (not available in IE) is a whole lot more versatile than oldskool appendChild( )
If you then add a 1 line framework
You end up with vanilla code:
October 18, 2025 at 9:55 AM
attachShadow sets ands return this.shadowRoot
and append( ) (not available in IE) is a whole lot more versatile than oldskool appendChild( )
If you then add a 1 line framework
You end up with vanilla code:
and append( ) (not available in IE) is a whole lot more versatile than oldskool appendChild( )
If you then add a 1 line framework
You end up with vanilla code:
shadowDOM is older than React
But us mortal Web Component developers couldn't use it till years later
𝙨𝙞𝙣𝙘𝙚 𝙬𝙝𝙚𝙣 𝙙𝙤𝙚𝙨 𝙪𝙨𝙚𝙧-𝙖𝙜𝙚𝙣𝙩 𝙨𝙝𝙖𝙙𝙤𝙬𝙍𝙤𝙤𝙩 𝙚𝙭𝙞𝙨𝙩 𝙞𝙣 𝙩𝙝𝙚 𝙗𝙧𝙤𝙬𝙨𝙚𝙧𝙨?
#webcomponents
But us mortal Web Component developers couldn't use it till years later
𝙨𝙞𝙣𝙘𝙚 𝙬𝙝𝙚𝙣 𝙙𝙤𝙚𝙨 𝙪𝙨𝙚𝙧-𝙖𝙜𝙚𝙣𝙩 𝙨𝙝𝙖𝙙𝙤𝙬𝙍𝙤𝙤𝙩 𝙚𝙭𝙞𝙨𝙩 𝙞𝙣 𝙩𝙝𝙚 𝙗𝙧𝙤𝙬𝙨𝙚𝙧𝙨?
#webcomponents
October 8, 2025 at 8:20 AM
shadowDOM is older than React
But us mortal Web Component developers couldn't use it till years later
𝙨𝙞𝙣𝙘𝙚 𝙬𝙝𝙚𝙣 𝙙𝙤𝙚𝙨 𝙪𝙨𝙚𝙧-𝙖𝙜𝙚𝙣𝙩 𝙨𝙝𝙖𝙙𝙤𝙬𝙍𝙤𝙤𝙩 𝙚𝙭𝙞𝙨𝙩 𝙞𝙣 𝙩𝙝𝙚 𝙗𝙧𝙤𝙬𝙨𝙚𝙧𝙨?
#webcomponents
But us mortal Web Component developers couldn't use it till years later
𝙨𝙞𝙣𝙘𝙚 𝙬𝙝𝙚𝙣 𝙙𝙤𝙚𝙨 𝙪𝙨𝙚𝙧-𝙖𝙜𝙚𝙣𝙩 𝙨𝙝𝙖𝙙𝙤𝙬𝙍𝙤𝙤𝙩 𝙚𝙭𝙞𝙨𝙩 𝙞𝙣 𝙩𝙝𝙚 𝙗𝙧𝙤𝙬𝙨𝙚𝙧𝙨?
#webcomponents
I would choose Svelte too.
All is fine if you are happy with that Build step,
you don't care what the code in the browser looks like,
never debug vanilla in the Browser,
never continue with components from project A into project B.
All is fine if you are happy with that Build step,
you don't care what the code in the browser looks like,
never debug vanilla in the Browser,
never continue with components from project A into project B.
October 3, 2025 at 8:52 AM
I would choose Svelte too.
All is fine if you are happy with that Build step,
you don't care what the code in the browser looks like,
never debug vanilla in the Browser,
never continue with components from project A into project B.
All is fine if you are happy with that Build step,
you don't care what the code in the browser looks like,
never debug vanilla in the Browser,
never continue with components from project A into project B.
What word is spelled?
ChatGPT thought for 7 minutes and 17 seconds, and said:
𝙋𝘼𝙒𝙉𝙎𝙏𝘼𝙍
Wrong word, because AI is great at logic, but can't think...
What word do you see?
ChatGPT thought for 7 minutes and 17 seconds, and said:
𝙋𝘼𝙒𝙉𝙎𝙏𝘼𝙍
Wrong word, because AI is great at logic, but can't think...
What word do you see?
September 19, 2025 at 10:53 AM
What word is spelled?
ChatGPT thought for 7 minutes and 17 seconds, and said:
𝙋𝘼𝙒𝙉𝙎𝙏𝘼𝙍
Wrong word, because AI is great at logic, but can't think...
What word do you see?
ChatGPT thought for 7 minutes and 17 seconds, and said:
𝙋𝘼𝙒𝙉𝙎𝙏𝘼𝙍
Wrong word, because AI is great at logic, but can't think...
What word do you see?
> a bit reminiscent to the old days where you just drop in
> a bunch of js scripts to tinker your toy projects
You can even have fun WITHOUT JavaScript,
because all browsers support Custom Elements since 2018,
and EVERY tagname with a dash IS a VALID HTMLElement.
Thus you can replace every DIV
> a bunch of js scripts to tinker your toy projects
You can even have fun WITHOUT JavaScript,
because all browsers support Custom Elements since 2018,
and EVERY tagname with a dash IS a VALID HTMLElement.
Thus you can replace every DIV
September 15, 2025 at 6:54 PM
> a bit reminiscent to the old days where you just drop in
> a bunch of js scripts to tinker your toy projects
You can even have fun WITHOUT JavaScript,
because all browsers support Custom Elements since 2018,
and EVERY tagname with a dash IS a VALID HTMLElement.
Thus you can replace every DIV
> a bunch of js scripts to tinker your toy projects
You can even have fun WITHOUT JavaScript,
because all browsers support Custom Elements since 2018,
and EVERY tagname with a dash IS a VALID HTMLElement.
Thus you can replace every DIV
Dear AI,
You were trained on blog-posts that do not show the chaining of super in:
super().attachShadow({mode:"open"})
That does not make your statement below right.
super() DOES return the this scope
You were trained on blog-posts that do not show the chaining of super in:
super().attachShadow({mode:"open"})
That does not make your statement below right.
super() DOES return the this scope
September 15, 2025 at 8:35 AM
Dear AI,
You were trained on blog-posts that do not show the chaining of super in:
super().attachShadow({mode:"open"})
That does not make your statement below right.
super() DOES return the this scope
You were trained on blog-posts that do not show the chaining of super in:
super().attachShadow({mode:"open"})
That does not make your statement below right.
super() DOES return the this scope
Cool! Reminds me of ZebraZapps by dr. Michael Allen
who also did the infamous Macromedia Authorware in the 90s
We happily paid $999 a year for it
(in 2007 deleted from existence by Adobe)
en.wikipedia.org/wiki/Adobe_A...
flowline based authoring
www.zebrazapps.info/features
wiring based authoring
who also did the infamous Macromedia Authorware in the 90s
We happily paid $999 a year for it
(in 2007 deleted from existence by Adobe)
en.wikipedia.org/wiki/Adobe_A...
flowline based authoring
www.zebrazapps.info/features
wiring based authoring
September 13, 2025 at 8:21 AM
Cool! Reminds me of ZebraZapps by dr. Michael Allen
who also did the infamous Macromedia Authorware in the 90s
We happily paid $999 a year for it
(in 2007 deleted from existence by Adobe)
en.wikipedia.org/wiki/Adobe_A...
flowline based authoring
www.zebrazapps.info/features
wiring based authoring
who also did the infamous Macromedia Authorware in the 90s
We happily paid $999 a year for it
(in 2007 deleted from existence by Adobe)
en.wikipedia.org/wiki/Adobe_A...
flowline based authoring
www.zebrazapps.info/features
wiring based authoring
> never seen the execution of inline functions
> in a tagged template (pls correct me)
My Web Component (2021) creates
animated SVGs from a Template Literal
using (pre-defined) functions
innerHTML String ► Template Literal String ► SVG
BLOG: dev.to/dannyengelma...
> in a tagged template (pls correct me)
My
animated SVGs from a Template Literal
using (pre-defined) functions
innerHTML String ► Template Literal String ► SVG
BLOG: dev.to/dannyengelma...
September 9, 2025 at 8:18 AM
> never seen the execution of inline functions
> in a tagged template (pls correct me)
My Web Component (2021) creates
animated SVGs from a Template Literal
using (pre-defined) functions
innerHTML String ► Template Literal String ► SVG
BLOG: dev.to/dannyengelma...
> in a tagged template (pls correct me)
My
animated SVGs from a Template Literal
using (pre-defined) functions
innerHTML String ► Template Literal String ► SVG
BLOG: dev.to/dannyengelma...
September 3, 2025 at 3:12 PM
It only gets you HTML (and slightly changed CSS)
No JavaScript required
smaller HTML
faster HTML
readable HTML
I came up with these benefits myself, AI wrote 20 more
No JavaScript required
smaller HTML
faster HTML
readable HTML
I came up with these benefits myself, AI wrote 20 more
September 3, 2025 at 8:53 AM
It only gets you HTML (and slightly changed CSS)
No JavaScript required
smaller HTML
faster HTML
readable HTML
I came up with these benefits myself, AI wrote 20 more
No JavaScript required
smaller HTML
faster HTML
readable HTML
I came up with these benefits myself, AI wrote 20 more
A. The manual is right
B. The techology is right
Would you want A-Developors or B-Developers in your team?
I prefer a mix, drives the team further
They also came up with this [pun intended]:
Wasn't documented anywhere
B. The techology is right
Would you want A-Developors or B-Developers in your team?
I prefer a mix, drives the team further
They also came up with this [pun intended]:
Wasn't documented anywhere
August 28, 2025 at 4:07 PM
A. The manual is right
B. The techology is right
Would you want A-Developors or B-Developers in your team?
I prefer a mix, drives the team further
They also came up with this [pun intended]:
Wasn't documented anywhere
B. The techology is right
Would you want A-Developors or B-Developers in your team?
I prefer a mix, drives the team further
They also came up with this [pun intended]:
Wasn't documented anywhere
Yes standard zealots always reference these "ID" texts
Dive into Web Components and you see this a lot (screenshot from MDN)
Which is just plain wrong.
You can use ANY JS *before* the super() call...
you just can't reference the 'this' scope
😧 Documentation is never written by the creators
Dive into Web Components and you see this a lot (screenshot from MDN)
Which is just plain wrong.
You can use ANY JS *before* the super() call...
you just can't reference the 'this' scope
😧 Documentation is never written by the creators
August 28, 2025 at 3:53 PM
Yes standard zealots always reference these "ID" texts
Dive into Web Components and you see this a lot (screenshot from MDN)
Which is just plain wrong.
You can use ANY JS *before* the super() call...
you just can't reference the 'this' scope
😧 Documentation is never written by the creators
Dive into Web Components and you see this a lot (screenshot from MDN)
Which is just plain wrong.
You can use ANY JS *before* the super() call...
you just can't reference the 'this' scope
😧 Documentation is never written by the creators
FireFox returns the FIRST Element for duplicate IDs
Mozilla broke behavior in 2017, and never fixed it
Since I advice developers NOT to use this Standard! browser behaviour I never filed a bug report.
Its great knowlegde to use in a Web-Pub-Quiz
Mozilla broke behavior in 2017, and never fixed it
Since I advice developers NOT to use this Standard! browser behaviour I never filed a bug report.
Its great knowlegde to use in a Web-Pub-Quiz
August 28, 2025 at 3:42 PM
FireFox returns the FIRST Element for duplicate IDs
Mozilla broke behavior in 2017, and never fixed it
Since I advice developers NOT to use this Standard! browser behaviour I never filed a bug report.
Its great knowlegde to use in a Web-Pub-Quiz
Mozilla broke behavior in 2017, and never fixed it
Since I advice developers NOT to use this Standard! browser behaviour I never filed a bug report.
Its great knowlegde to use in a Web-Pub-Quiz
Or they know how browsers really work...
August 28, 2025 at 3:23 PM
Or they know how browsers really work...
IDs were never unique, and there never was a battle
All browsers implemented what Internet Explorer (90% market share) was designed to do 25+ years ago
😎 a HTML ID creates a variable on the window Object referencing the Element
😎 Duplicate IDs create a HTML collection (FireFox broke this in 2017)
All browsers implemented what Internet Explorer (90% market share) was designed to do 25+ years ago
😎 a HTML ID creates a variable on the window Object referencing the Element
😎 Duplicate IDs create a HTML collection (FireFox broke this in 2017)
August 28, 2025 at 3:12 PM
IDs were never unique, and there never was a battle
All browsers implemented what Internet Explorer (90% market share) was designed to do 25+ years ago
😎 a HTML ID creates a variable on the window Object referencing the Element
😎 Duplicate IDs create a HTML collection (FireFox broke this in 2017)
All browsers implemented what Internet Explorer (90% market share) was designed to do 25+ years ago
😎 a HTML ID creates a variable on the window Object referencing the Element
😎 Duplicate IDs create a HTML collection (FireFox broke this in 2017)
My favorite vanilla code to "subscribe" children to parent nodes (only when parent has an Array subscribers)
August 28, 2025 at 12:27 PM
My favorite vanilla code to "subscribe" children to parent nodes (only when parent has an Array subscribers)