3 ms·

I believe this is an intentional design decision in CSS, and is related to all good user agents letting you run custom user scripts on page load to manipulate p

I believe this is an intentional design decision in CSS, and is related to all good user agents letting you run custom user scripts on page load to manipulate pages arbitrarily. What if I prefer reading white-on-black text, and have a custom stylesheet that does that? Your widget will be a glaring, angry block of black-on-white text in an ocean of calm black. In general, I would argue you should just try to play nice with whatever inheritable styles you're given to the extent you can. Sure, your widget will be unreadable if the page chooses black-on-black text, but so will the page, so that won't actually happen. Basically, your widget should be like a weaker version of the shadow DOM of replaced elements (buttons, textboxes etc), you supply good default styles but they have to be overridable by the page.

exogen 15y ago
> In general, I would argue you should just try to play nice with whatever inheritable styles you're given to the extent you can. Sure, your widget will be unreadable if the page chooses black-on-black text, but so will the page, so that won't actually happen. I can tell that you've never had to deal with this problem before. :) Ignoring useragent styles for a moment, it's not uncommon for pages to declare broad styles like: p { text-shadow: 0 1px 0 #000; } h1, h2, h3 { text-transform: uppercase; } a { color: red; } input { margin-bottom: 2em; } And it's likely that these styles are perfectly readable on the page. Now the author adds your widget, and suddenly your widget is also subject to these styles. If your widget is complex – think "mini app", not "ad unit" – you now have to reset every single possible CSS property for the widget to be usable on every site, and in a way that gives it the highest specificity compared to other selectors used by other page styles. I wasn't thinking inherit: none would disable a useragent's default styles. Just other styles directly on the page. But it's certainly not that simple to define those semantics.

exogen 15y ago

> In general, I would argue you should just try to play nice with whatever inheritable styles you're given to the extent you can. Sure, your widget will be unreadable if the page chooses black-on-black text, but so will the page, so that won't actually happen. I can tell that you've never had to deal with this problem before. :) Ignoring useragent styles for a moment, it's not uncommon for pages to declare broad styles like: p { text-shadow: 0 1px 0 #000; } h1, h2, h3 { text-transform: uppercase; } a { color: red; } input { margin-bottom: 2em; } And it's likely that these styles are perfectly readable on the page. Now the author adds your widget, and suddenly your widget is also subject to these styles. If your widget is complex – think "mini app", not "ad unit" – you now have to reset every single possible CSS property for the widget to be usable on every site, and in a way that gives it the highest specificity compared to other selectors used by other page styles. I wasn't thinking inherit: none would disable a useragent's default styles. Just other styles directly on the page. But it's certainly not that simple to define those semantics.