alt Hacker News> Your premise that the browser implementation is faster and better is rarely true.
I know that they’ve optimised this as much as they can, but it still seems to catch pretty much everybody by surprise that every single instance of a web component with a shadow DOM needs the site’s CSS reset added to it individually (or just skip it and keep forgetting that things like box-sizing will be inconsistent with your non-shadow-DOM styles). There’s no way to say “here’s my default styles” that will work consistently across the whole page once you start using web components. And then you have the !important fights between the web component and its contents as well.
Even though it’s been standard practice amongst web developers for 15+ years, the people working on the web platform seem to mostly act like CSS resets aren’t a thing.
Replies
I find that developers add a CSS reset without thinking about it as if there is always a need. We never used resets. There was never a need. Typically we would set something according to the design anyway and starting with a reset was like slamming something against one wall only to throw it back to a different wall later.
The history here, as I understand it, was that they imagined you would use custom elements from multiple third parties, so any shared CSS definitions would cause breakages.
See eg the (now removed) HTML imports standard.
The tension is between two kinds of CSS users. The ones who want cascading style sheets, and the ones who want scoped style sheets. And sometimes even people who think they want scope find out they also want the cascade, and just wanted to scope a bit "at the end" (something the cascade can do anyway)