> This is a branding problem as much as it is an education problem. Neither the HTML standard nor the DOM standard mentions the term “web components” anywhere. And yet it’s present everywhere in documentation and learning material.
Very clear pattern forming in a few of my #WebComponents, creating a <template> element outside of the component code itself for reduced repetition and performance. I'm effectively polyfilling for Declarative Shadow DOMs inability to be defined once for many instances. Though I guess I'm also polyfillnig for a lack of “Declarative Light DOM" too 🤔
> This is a branding problem as much as it is an education problem. Neither the HTML standard nor the DOM standard mentions the term “web components” anywhere. And yet it’s present everywhere in documentation and learning material.
One of the teams I've been working with to climb the performance management maturity ladder is...Edge!?!
We build a lot of the browser out of web "stuff" these days (think bookmarks, history, downloads, settings, new-tab-page, etc.), and moving away from React to a modern Web Components + HTML-first architecture has had a huge benefit for users, particularly folks on low-end hardware:
"The random-source Web Component allows you to cycle randomly through different audio or video sources, utilising existing HTML elements and providing an elegant fallback experience.”
Started writing a decision log for our #DesignSystem. Documenting why we chose to build plain ol' #HTML and #CSS where we can and #WebComponents where client-side #JS is needed is turning into a bit of a manifesto. Essentially we're using (and encouraging others to use) #ProgressiveEnhancement 😉
A Web Component for filtering items using a text input. Made this for a friend a while back and thought I should wrap it up into a neat package to go alongside my other #WebComponents.