To be Strict or not to be
I am about to geek out so bad it will make your eyes roll back and have you snoring before you finish the first paragraph. But to be honest, it’s not for you that I write this stuff, it’s for posterity and so that I can always look it up in the future, if such a thing should ever happen to me again.
I have finally nailed down an obscure little bug in cataLog (and in turn Acumen) that was causing the second level navigation to jump up about 14 or so pixels when the user used the “Tidy” setting in RapidWeaver and when the user used code or content that tripped the “Tidy” setting into converting the document into a Transitional DOCTYPE. The reason the bug remained so illusive is that this set of circumstances was not immediately clear and is not necessarily something the end user is mindful of.
My repeated testing, assuming that there had to be a difference in the content area or navigation area, kept leading me down the wrong path. One assumes, when “Tidy” is at work, that the HTML of the document is somehow being altered or “tidied up” as it were. And this is where I continued to search extensively but came up empty handed every time. Having exhausted nearly all HTML avenues and having run countless DIFF comparisons I finally turned my attention on the one thing in each document that I knew was different; the DOCTYPE. By simply switching the DOCTYPE from Strict to Transitional, regardless of whether the embodied code was in fact one or the other, I could trigger this odd navigational occurrence.
As much as this was a major breakthrough in the tracking of this bug, I now knew that the game had gotten that much more complex. I was no longer dealing with a bug in my code or the theme as a whole. I was now dealing with what was potentially a rendering bug, or interpretational difference in the two DOCTYPE’s, meaning that the bug being presented may very well be an issue in the HTML standard itself. Eeek!
Since I knew that the navigation in question uses inline-block as a value on its display property, and since I am well aware of the lack of widespread support that inline-block has among browsers, I knew that this was probably the place to look. I need to look in the CSS of the second level navigation.
Through considerable trial and error I found that an attempt to display the ancestor, or hidden navigation inline was what was causing the trouble. In DOCTYPE Strict, the combination of ul {display: inline;} and ul ul {dispay:inline-block;} caused the initial ul to have height, despite having tried to suppress it with ul {height:0; margin:0; padding:0;} etc… While in DOCTYPE Transitional, the initial ul rendered correctly (which is to say it didn’t render at all and had no height), so the latter ul would shift up to takes it’s position. The fix was simply this: ul {margin:0; padding:0;} with no attempt at any display value other that what it would naturally inherit (which would be “block”).
So is this in actual fact a bug in the Strict DOCTYPE standard? It’s hard to say really. In the making of RapidWeaver themes, we pour a lot of effort and trickery into making things happen the way we want them too. In the case of split navigation we use the same set of code in multiple locations and simply turn on or off the bits we want shown or hidden. This probably is not a typical practice in web design but a necessity in RapidWeaver theme development. Still, why would one DOCTYPE behave differently from another where such a small property in concerned?