The guide I wrote on z-index positioning was linked on WaSP Buzz and was there spotted by the Safari developer, Dave Hyatt. Dave effectivelly overturned (what seemed like) 95% of my claims about standard compliance. Thanks to Axl who left a comment here I was able to quickly respond and update the guide accordingly.
After the whole thing settled down, it got me thinking on two issues…
First, Dave actually corrected only a fragment of the guide, but it was a very unfortunate place to make mistakes. I did it at the very first paragraph, overlooking the fact that non-auto z-index does not create stacking context. All my following conclusions and claims were drawn from that first paragraph. They were all correct when based on such basis. Since the basis was wrong, the entire guide turned-out wrong.
By simply changing the basis to correct information, I managed to update the entire 8-page guide in practically no time at all. I had grasped 95% of the concept correctly, so the re-typing went like a breeze.
Good thing was that essence of the guide, the examples, were correct from the beggining. Last three pages showed the right combination of z-indexes on both RPs and APs to get indentical rendering on all browsers. That was my intention from the start; I need to learn to refrain from the definitive sentences though.
This build-your-own-theory case reminded me of high-school classes about Lobachevsky geometry theory. Back then, most us had problems grasping it because we were first taught according to the old greek Euclid’s theory. Thus everything in the Lobachevsky universe seemed utterly wrong. But it was simply a question of habit; russian mathematician simply changed the basic axioms and build on top of that, thus everthing he did was entirely correct on this new basis.
Now I can completly understand that. There’s nothing better than hands-on learning. :)
Second…before I got linked on WaSP, I posted this on css-discuss and submitted it to css-vault, where it was quickly included. According to my site stats, the guide received quite a bit of visits after that, but no one said anything. Zoe echoed my own suspicions that something was wrong here, as it looked quite impossible that both gecko and khtml engines were wrong in exact the same way, while IE was right.
But when Chris Kaminski buzzed me on WaSP, unique visits for the guide tripled in a day and quality explanation came in a matter of hours. It’s the proof of both weight and influence that WaSP holds.
Probably the most complex CSS layout I built is the one that runs the Internet channel of my company’s main product. As this channel is viewed by customers of our clients, each design has to be different enough. Sites must not look like copycats with different colours. They also need to run on the same server-side code, to simplify maintenance and development.
CSS floats and positioning is the right tool for that job on today’s Internet. While I fully grasp the float stuff and use it with much joy, the positioning part is often giving me headache. The online channel interface relies heavily on positioning, showing/hiding elements and neat stacking of boxes below/above each other.
Positioning also gives me way too much trouble with my multi-level menu.
Trying to clarify these things for myself and resolve ongoing problems, I built a series of pages to see how various
z-index values influence the placement of relatively and absolutely positioned elements. I have dozens of nested RP and AP elements in the mentioned interface, and some overlapping issues seems unsolvable.
After three or four pages, I realized that this could be a neat tutorial, especially because I don’t see that this issue is tackled much in books, blogs and other resources.
Thus, here it is: The effect of z-index value on RP and AP blocks.
The best part: the only browser(s) that correctly implements CSS2.1 specification is IE. Yes, really.
update (Sep 15th): Dave Hyatt responded and proved me very wrong. The guide is now updated with (hopefully) correct information.
I tested in Firefox 0.9.2, Opera 7.5, IE6.01, IE5.2.3/Mac, Safari 1.2.3, OmniWeb 5.0, Camino 0.8.
I believe that every last one of you reading this page have read Doug Bowman’s Throwing Tables Out the Window and wondered what exactly he did to make microsoft.com CSS-based. I know I did.
Doug did not want to release the makeover code without speaking to Microsoft first. I don’t quite dig that, since there were numerous make-overs done in the past, with open-hearted approach. I doubt that someone will spend a weekend re-doing anyone’s web site simply to rub-it-up-their-nose. That’s stupid thing to do.
I wanted to test my knowledge and skills and see how quickly I can do this. It might prove useful when price-quoting similar job in the future.
Without further a do, here is the final result.
I don’t intend to explain every part of this, I just want to emphasize some of the most interesting issues.