January
2008
Reverse Cascade?
I’m doing some experiments with navigation lists in CSS and have come across a stumbling block which relies on DOM scripting to work around. The examples given here are not intended to work, we would know it as “parent selectors”
Aside from this being a really cool sounding technique you could throw across the dinner table as “have you tried the reverse cascade trick” which is what I would name the technique, after the juggling trick, I actually know this is impossible to do with CSS as it involves cascading “up” not “down”. At source the W3C have decided that would take too much processing power to “cascade up”. Andy Budd has tackled this on his blog long with many others. CSS is one directional, for good reason I can see why cascading backwards is not a great idea, but equally it’s on of those brilliant contradictory evil ideas.
It’s nearly 2010, do you know how close the second decade is? Contradictory evil ideas are all around us, but it amazes me why this parent selector has been left to fill blogs all over the world, such a useful feature and as we push into a “must work without JavaScript” world this has to happen.
However imagine the power the parent selector would give us if we have a simple navigation list with some sub navigation which is hidden. This is great until we would like to “fold out” the sub navigation without reloading the page and adding classes to fold out certain bits of the menu. Although we have hidden the sub menus with CSS we cannot un-hide with CSS alone (this is not drop down in nature, more explorer tree), we can’t really use mouse events and the way keyboards traverse navigation lists is through the anchor tags, which is really inconvenient for this.
<ul id="nav">
<li><a href="/">Home</a>
<li class="selected"><a href="/about/">About Us</a>
<ul>
<li><a href="/about/history/">History</a></li>
</ul>
</ul>
--
ul#nav ul { display : none; }
ul#nav li.selected ul { display : block;}
So I could in theory trigger an a:focus in the main navigation list, but because my sub nav is contained in the LI above the A tag, I can’t use the A tag to fold out the sub nav, and li:focus doesn’t make sense as the keyboard would tab through the A tags. That’s pretty useless as the A usually is closed right away, it doesn’t make structural sense to move the end of the A tag so that it wraps the UL block. We could train wreck it with DIV’s but let’s not go there.
However if we could reverse cascade we might be able to pass triggers back up the tree and re-cascade from that point onwards. How would that look for it to make sense? One of the beauties of of CSS is that the syntax is easy to understand so this must be maintained and it can’t break an existing conceptual model of how forward cascading works, the two have to coexist.
Example one
ul li < a:focus ul
Without confusion with other characters this could work, the single arrow could signify that the a:focus should be passed to the parent node only a double “<<" could pass the focus up two levels up the DOM tree.
Example two
ul li <- a:focus +> ul
Perhaps a little more long winded but we could say that the a:focus is a go between, in that it supplies the trigger to the LI with the “<-" character and then cascades normally from the "+>” character.
So would the world be a better place with reverse cascading or is the world just not ready for it? CSS classes rule the world and are used to forsake good structure in the HTML so what hope is there of moving away from className switches in DOM scripting?
