Public Domain Image Archive
Explore our hand-picked collection of 10,046 out-of-copyright works, free for all to browse, download, and reuse. This is a living database with new images added every week.
Explore our hand-picked collection of 10,046 out-of-copyright works, free for all to browse, download, and reuse. This is a living database with new images added every week.
So what are the advantages of the Custom Elements API if you’re not going to use the Shadow DOM alongside it?
- Obvious Markup
- Instantiation is More Consistent
- They’re Progressive Enhancement Friendly
I am going to continue to write this newsletter. I am going to spend hours and hours pouring over old books and mailing lists and archived sites. And lifeless AI machines will come along and slurp up that information for their own profit. And I will underperform on algorithms. My posts will be too long, or too dense, or not long enough.
And I don’t care. I’m contributing to the free web.
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.
React has become a bloated carcass of false promises, misleading claims, and unending layers of backwards compatibility – the wrong kind of backwards compatibility, as they still occasionally break your fucking code when updating.
Pretty much anything else is a better tool for pretty much any web development task.
A library of CC-licensed photos.
Next time you’re tempted to use a generative “AI” tool to make an image for a slide deck, use this instead.
This is an interesting thought from Scott: using Shadow DOM in HTML web components but only as a way of providing sort-of user-agent styles:
providing some default, low-specificity styles for our slotted light-dom HTML elements while allowing them to be easily overridden.
One dev team made the shift from React’s “overwhelming VDOM” to modern DOM APIs. They immediately saw speed and interaction improvements.
Yay! But:
…finding developers who know vanilla JavaScript and not just the frameworks was an “unexpected difficulty.”
Boo!
Also, if you have a similar story to tell about going cold turkey on React, you should share it with Richard:
If you or your company has also transitioned away from React and into a more web-native, HTML-first approach, please tag me on Mastodon or Threads. We’d love to share further case studies of these modern, dare I say post-React, approaches.
I really, really like Paul’s idea of splitting up the indie web principles into one opinionated nerdy list of dev principles, and a separate shorter list of core principles for everyone:
- Own your identity An independent web presence starts with an online identity you own and control. The most reliable way to do this today is by having your own domain name.
- Own your content You should retain control of the things you make, and not be subject to third-parties preventing access to it, deleting it or disappearing entirely. The best way to do this is by publishing content on your own website.
- Have fun! When the web took off in the 90’s people began designing personal sites with garish backgrounds and animated GIFs. It may have been ugly but it was fun. Let’s keep the web weird and interesting.
So many of the problems and challenges of working with Web Components just fall away when you ditch the shadow DOM and use them as a light wrapper for progressive enhancement.
My secret is safe.
The main reason I’m so hot on Light DOM is that I find the styling story of Web Components using Shadow DOM annoying.
Browse through some truly web-native artwork by Eric, and read all about it:
There is a lot, and I mean a lot, of room for variability in web technologies. We work very hard to tame it, to deny it, to shun it.
I’ve worked with Web Components a little bit over the last few, but really struggled to understand the use case for them.
Until this week.
Between Jeremy Keith’s article on HTML Web Components, plus using one for a client project with NASA, something just clicked in my brain finally.
I’m now convinced that they’re the best way to author DOM manipulation libraries.
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 search engine for images and audio that’s either under a Creative Commons license or is in the public domain.
When Dan wrote this a week ago, I thought it sounded very far-fetched. Now it sounds almost inevitable.
I believe strongly in the indieweb principles of distributed ownership, control, and independence. For me, the important thing is that this is how we get to a diverse web. A web where everyone can define not just what they write but how they present is by definition far more expressive, diverse, and interesting than one where most online content and identities must be squished into templates created by a handful of companies based on their financial needs. In other words, the open web is far superior to a medium controlled by corporations in order to sell ads. The former encourages expression; the latter encourages consumerist conformity.
The slides from Tess’s presentation on the W3C’s ethical web principles—there’s a transcript too.