5 ms·

I'm surprised only one person mentioned "inherit: none" for CSS (that's what they called it, anyway). If you've ever tried to develop a widget that anyone can s

by exogen 15y ago

I'm surprised only one person mentioned "inherit: none" for CSS (that's what they called it, anyway). If you've ever tried to develop a widget that anyone can stick on any old page, you know this: either you go with an IFRAME and your styles are fine but integration with page events and responding to content size changes are hard, or your styles are totally fucked. There is absolutely no way to "silo" any area of a page from rogue CSS selectors besides using an IFRAME. Even the <style scoped> feature [1] which isn't even supported yet (AFAIK) doesn't really address the issue. The result is that you're constantly building a bigger and bigger localized CSS reset for your widget and trying to win the specificity arms-race against the host page. I would love that feature. [1] http://dev.w3.org/html5/spec-author-view/the-style-element.html#attr-style-scoped http://dev.w3.org/html5/spec-author-view/the-style-element.h...

nephesh 15y ago
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 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.
- exogen 15y ago
  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.
laughinghan 15y ago
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.
paulirish 15y ago
so the `initial` value can functionally replicate this. https://developer.mozilla.org/en/CSS/initial 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 https://github.com/premasagar/cleanslate
- exogen 15y ago
  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.

by exogen 15y ago

nephesh 15y ago

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

exogen 15y ago
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.

laughinghan 15y ago

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.

paulirish 15y ago

so the `initial` value can functionally replicate this. https://developer.mozilla.org/en/CSS/initial 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 https://github.com/premasagar/cleanslate

exogen 15y ago
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.