css boundaries/stopping the cascade
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:
quote ... there's a realistic chance that your nicely tweaked piece of code will be overruled by already existing css declarations . unquote
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?
As someone suggested to me earlier:
.newsletterInclude {cascade:no-cascade;}
The only practical way around this at the moment (which I can think of, anyway!) would be to do a local CSS "reset" on a wrapper
div, or define the styles in aclass, say "standalone", and do something like this:.standalone, .standalone *{
background: white;
color: black;
clear: none;
font-size: 1em;
/* etc, etc, etc.*/
}
(In reality you would probably need much more specific selectors, to ensure that these styles override the existing ones...)
You're absolutely right, it's those etc.. marks I'm worrying about the most. Too many thing that can go wrong.
But even then, other problems will arise. Not actually related to the cascading properties of css (I think), but consider the following css rule in your own site:
h2 {margin-left:60px;}There is no wrapper div that can stop this, as it will spill over the wrapper anyway and hit any h2 tags in the external code. Maybe the term cascade is not the best option to go here as what I'd really want is to stop all css from spilling over a certain div.
True, the wrapper
div/classmethod which I mentioned above does have its limitations, as you pointed out in your last comment. Unfortunately, there seems to be no way of isolating a specific area to be overlooked by the cascade.However, I quite like your
iframeidea - this is as near as you can get to achieving the desired effect. Just out of interest, what are your reasons for not using aniframe? I know they're a bit retro, but do you have any technical concerns (accessibility issues etc.) that prevents you from using them? (I only ask because I have never really used or looked intoiframes much...)Well, one problem you have with iframes is the height declaration, it won't size with your content. There are javascript solutions to fix this though.
In the end, using an iframe works relatively well, though I'm not sure how different user agents react to iframes (fe how well do screen readers behave), how it prints, ...
Hey Niels, great concept, this would come in handy for me. Now how to implement it?
What if a CSS reset were used? And prepend all those declarations with the ID of your standalone component?
(NOTE: these should be ID's, but this comment form doesn't allow numbersign-word combos, weird.)
See Meyer's CSS Reset for the etc. etc. : http://meyerweb.com/eric/tools/css/reset/
I haven't tried it yet, so I can't vouch for it's effectiveness. But it might be worth a shot?
I like the
iframeidea, too. That'd be a sure way out.Hey Jason, the problem with your solution is that it effectively resets all styles, including all styles to render to external code. If, for example, I'd defined a padding on all h2 in my external component, I wouldn't want the including page to erase all that, rather I want the including page to leave the styling as is.
Apart from using iframes, there's really no good solution around this at the current time, hopefully future versions of css will give us more power.
I'm not a browser developer, so I'm only guessing, but concerning this:
the reverse may actually be true as the browser has to spend more time analysing the document to determine which bits should receive which stylesheets before the page can be fully rendered.
True, I guess it depends on the complexity of the matter. You could of course set up multiple separated areas, but in my examples (or the ones I've come across myself) there was always only need for one shielded area.
It would surprise me if a simple wall like that would slow down the rendering more than all the effective rendering itself. Though like yourself, I'm no browser developer :)
guys can u explain me what do you actually required.......
* required fields