This is a great way to organise code snippets—listed by use case, and searchable too!
Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.
Trys describes exactly the situation where you really do need to use the Shadow DOM in a web component—as opposed to just sticking to HTML web components—, and that’s when the component is going to be distributed and you have no idea where:
This component needed to be incredibly portable, looking great on any third-party website, in any position, at any viewport, with any amount of content. It had to be a “hyper-responsive” component.
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
This is an excellent step-by-step walkthrough by Tess of creating a web component, with real thought given to what should be in the HTML (which will act as a fallback) and what’s better generated in the Shadow DOM (like buttons for interactivity).
This perfectly mirrors something Chris was saying in a recent episode of the Shop Talk Show:
I think of the image comparison one. That’s a classic example in Web component. What’s inside is just two IMG tags. That’s it. When it fails, you don’t want a weird div with little arrows on it being rendered on the page. That’s not doing anything because it has failed to load the JavaScript.
You just take some normal HTML markup, wrap it with a custom element, and then write some JS to add capabilities which you can then style with regular CSS! Everything’s of the Light Side of the Web. No need to pierce the Vale of Shadows or whatever.
I think Eric’s approach here should be the default for most web components: you probably don’t need to mess around with the shadow DOM, and you should definitely be wrapping your web component around existing HTML instead of witing opening and closing tags with nothing in between.
Augment, don’t replace.
A handy reference for explaining the differences between confusingly similar bits of HTML, CSS, and JavaScript.
Try writing your HTML in HTML, your CSS in CSS, and your JavaScript in JavaScript.
Inside me there are two wolves. They’re both JavaScript.
Trying to understand a different mindset to mine.
Responses to my thoughts on why developers would trust third-party code more than a native browser feature.
I’m trying to understand why developers would trust third-party code more than a native browser feature.