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.

> 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.

so the `initial` value can functionally replicate this. https://developer.mozilla.org/en/CSS/initial

You just apply that to each property you want to reset. You might think that applying it to EVERY property is a nightmare but in many cases you wouldnt need to. Disqus, for example, operates in your own CSS so it can look native to the page. They only have to override a few properties to assure their layout is good.

So yeah, while `inherit:none` would be awesome, I think `prop: initial` gets us most of the way there.

Also related: https://github.com/premasagar/cleanslate

Hmm, you'd still have to ensure that your selector has higher specificity, right? That itself can be hard unless you're okay with adding !important to everything. I was thinking that inherit: none would somehow address this, but the rules would probably be pretty complicated.

Not to disagree, but this type of scenario has become much easier to deal with using iframe's and postMessage (https://developer.mozilla.org/en/DOM/window.postMessage). You can basically setup a client script that is embedded as the widget and some javascript inside your iframe to talk between each other. Just thought I'd throw out another option for those that are looking for one.

There is that, which is nice when you can get away with it. Unfortunately I still consider this the "hard" approach for a few reasons.

1. Supporting IE7, for which people tend to use an intermediate Flash object to do the communication.

2. There's still the content size problem. Does your IFRAME'd widget change size? Now you need to detect all size changes with JavaScript and send them back to the host page so it can resize the IFRAME.

3. Is your widget non-rectangular or concave? For instance, can it pop out a menu of a different size than the widget itself? Well, now you need an additional IFRAME for each piece that sticks out.