There are plenty of great responses already, but to add a perspective I think might benefit folks who don’t especially care about the style and Web Component isolation aspects: Shadow DOM standardized those aspects of encapsulation not just for user-authored stuff, but also for encapsulated behavior of browser-native functionality. So for a very silly example, you can now inspect the shadow DOM of an image that failed to load and see the resulting DOM representation that the browser uses in place of the intended image. You can do the same for form field elements and a lot of other elements which used to be totally opaque.
This is great not just to understand more about what’s happening when browser-specific stuff goes sideways, it’s also a really good place to take design inspiration for encapsulating your own stuff. Besides scoping styles and fully isolating children as implementation details, the native implementations often make judicious use of `part` and `slot` aspects of the relevant/related APIs to handle interop with the non-encapsulated parts of their interface. In a lot of ways this allows elements (both native and custom) to provide much stronger contracts than the mostly tag soup that HTML tends to be by default. And it’s especially great that the interface for this is largely (if not totally now?) how built in behavior works, so writing code that targets the browser has the same privileges and the same limitations as the equivalent code the browser provides.
This is great not just to understand more about what’s happening when browser-specific stuff goes sideways, it’s also a really good place to take design inspiration for encapsulating your own stuff. Besides scoping styles and fully isolating children as implementation details, the native implementations often make judicious use of `part` and `slot` aspects of the relevant/related APIs to handle interop with the non-encapsulated parts of their interface. In a lot of ways this allows elements (both native and custom) to provide much stronger contracts than the mostly tag soup that HTML tends to be by default. And it’s especially great that the interface for this is largely (if not totally now?) how built in behavior works, so writing code that targets the browser has the same privileges and the same limitations as the equivalent code the browser provides.