css boundaries
As css developers, we all love the cascade. It brings us many great opportunities and saves us heaps of time. But below that shiny surface of the cascade is a darker streak, popping up at the most annoying of times. Sometimes the cascade tires me, sometimes I just want to build a wall and tell the cascade to go and bug someone else. Sadly I cannot do that, and a while ago I wondered why it was I couldn't do just that.
the css cascade
Earlier this year I wrote an article on how to protect yourself when delivering a stand-alone component. In that article the main problems with the cascade were quickly highlighted and some solution to minimize damage were given. Still, there should be better ways.
To quickly summarize the main issue, I'll royally quote myself:
... there's a realistic chance that your nicely tweaked piece of code will be overruled by already existing css declarations
The problem arises when you need to integrate one piece of code into a different context. I've been running into these exact kind of problems lately (displaying a newsletter in site, developing an overlay for an intranet without having access to said intranet, displaying stand-alone code examples/previews, ...) so I started looking for some solid solutions to this problem (apart from using an iframe).
playing around
Maybe I didn't look well enough, but I found nothing. Since you can never be sure where your code will end up, there's no way to anticipate what css rules will influence your component. You can of course define everything on anything, but that's not exactly efficient and would require too much hassle.
In theory, the solution is quite simple. As css developer, we should have the power to stop the cascade, or define an area in our code where a certain set of rules could be applied. Build a wall which the cascade cannot cross. This could have several obvious advantages:
- You save some processing time as rules won't be needlessly applied to a part of your page and these rules don't need to be overruled.
- The page owner is still in full control, he decides whether styles are applied in external code.
- No more irritating cascade problems when including external components.
- No troubles with iframe workarounds.
Sadly, this is just dreaming out loud, but after toying with the idea for a while, I still haven't found any considerable drawbacks (apart from not-so-experienced css developers screwing it up for themselves).
Sadly, I feel little about making suggestions myself to the css development team, as it takes a lot of time and hassle to get in there and get some solid ground for discussion (as it often requires syntax propositions and the like). That said, I think it's a pretty good idea and would only increase the control one has over the way css is applied on a document. I'd sure use it.
so ...
Any comments on the idea would be welcomed, especially on loop holes I haven't figured out myself. And if any of you would like to propose it, go right ahead. Wouldn't it be nice to start using this in 10-15 years time?