I mean… why not just make it work if you apply it, since any element has a position intuited whether it’s defined or not? Is there any reason this wasn’t done, or is it sloppiness on the part of the consortium. Just kinda curious on that…
Because the natural position for all elements is somewhere where they don’t overlap other elements so that z-index is not required where the default non-overlapping position is chosen.
not sure I follow. I know most times unless you start floating or absolutely positioning things that you won’t have overlapping elements and z-index won’t do anything, but I don’t see how that translates into needing to define a positioning type before z-index will function since every element has a position type even if it isn’t expressly set.
It’s even more evil than that. Most of the time you need to set a position on the ancestor of the element which you want the z-index set relative to. Even though many times you don’t want to apply any position to this at all, but this is how CSS determines what we call “positioning context”, ie the ancestor element you’re positioning the child element relative to.
You not only have to establish a positioning context with z-indexes, but absolute positioning as well. It’s not obvious, but a critical part of learning how to make CSS actually do what you want it to. IMO learning positioning context and understanding block vs. inline XHTML elements are the two most important things you can do to transform CSS from a “black art” and render it substantially more comprehensible.
Only because of IE. Aka on dropdowns the nested <ul> having a z-index isn’t enough. The outer parent needs one because of how IE is. Normally you don’t.
. Even though many times you don’t want to apply any position to this at all, but this is how CSS determines what we call “positioning context”, ie the ancestor element you’re positioning the child element relative to.
If you are talking about the child being absolute positioned it’s best to have a parent as the containing block, so if that’s what you meant then sorry 
When CSS was being created it just didn’t make sense for static blocks to be able to overlap (and have you control it)
Specifying stack levels (z-index) can only be applied to those elements which are positioned; that is, elements that have a ‘position’ value of ‘relative’, ‘absolute’, or ‘fixed’. A reason detailing why you don’t want to have ‘position:relative’ set globally, is described below.
Using absolute positioning, you can offset an element relative to any of it’s ancestors, which can be a powerful tool (when used in the right context). For example (assuming no ancestor of the element is already positioned), if you specify ‘top:0;right:0’, by default the element will be offset relative to the initial containing block = the root element of a language (in HTML, it’s the HTML element). This is due to the fact that no containing blocks (apart from the initial containing block) have been established, since all ancestors use the normal flow positioning scheme (namely the initial ‘static’ value, which has no effect in establishing a containing block).
In order to control which ascendant establishes the containing block of the absolutely-positioned element, a ‘position’ value of either ‘relative’ or ‘absolute’ is applied to the chosen ancestor. If you were to set ‘position:relative’ globally, you would quickly run into complications with using (particularly) absolute positioning outside of an element’s parent. It’s best to retain this flexibility so I’d recommend only setting ‘position:relative’ on a case by case basis.
If you’re having trouble understanding the above, then I suggest you look at the following links- although I’m sure they are some sites that offer more ‘digestible’ definitions of the relevant terms, if you did a Google -
Apologies, upon re-reading my reply it appears that I failed to understand your original question. Although, I covered the answer very briefly in my last post, I’ll reiterate it
The answer relates specifically to positioning schemes that can be appied to an element. You’re correct in saying all elements have position, and by default, all elements (except ROOT) have a position value of static. However, in order for an element to generate a stacking context (participate in z-indexing), it must have a position value other than static.
With that in mind, I suggest you re-read my first post, and it should make slightly more sense
Not if you specify your code in the right order it doesn’t. As long as the following content that is to be under the dropdowns is defined before the outer parent <ul> in the HTML the dropdowns will still appear in front of it. It is only if you apply the more natural ordering that the outer parent needs a z-index.
Of course you are right that only IE has that issue.
No problem. On the one hand it’s sort of nice that CSS provides a limited flexibility. In practice though, I agree with you, it’s usually much easier to deal with a design that consistently ensures that absolutely positioned elements are within positioned parents. Consistency is always a key element of improving the comprehensibility (and thus the implementation and maintenance) of a website or application.
That’s a good question and James has answered the technicalities of “why” etc but I happen to agree that sometimes it would be useful if z-index could actually be divorced from the positioning process and exist in its own right and just obey its index irrespective of its parent or positioning scheme.
In most cases however it works fine as it is but as usual there’s always one case when you need something different. (and while I’m asking can I have float:center and float:bottom as well please :))
Holy #$%@#$% Yes!
And while we’re wishing, is there any reason we can’t have IF and FOR statements? I appreciate that CSS is kept simple and that’s wonderful, but even Freakin’ Excel has a library of functions hidden away from newbies that you can learn and use if you need them. The absence of ANY decision making code in CSS really sucks.
You can combine PHP in CSS files (assuming you configure your server to parse CSS files through the PHP parser).
Paul had a good link like 8 months ago which explained it perfectly. You can do if/else in there ;).
but in the shared hosting accounts most of my freelance clients (and I!) can afford, that’s not an option. 
It is all a matter of deciding what the requirements are before you get the hosting. There are a lot of cheap shared hosting that do allow PHP and if it turns out that the difference between hosting that allows it and hosting that doesn’t is a certain extra charge each month then you need to decide whether having that ability is worth that money or not…
It’s a good question and there’s no reason why it must be that way - but that’s just the way it is.
The great thing about open standards is that people who are interested enough can actually influence them. Here’s some more outside-the-box thinking on future CSS specs.
http://www.stubbornella.org/content/2009/11/09/css-wish-list/
I don’t really agree with all of Ella’s points but a lot of them make sense to me.
(and while I’m asking can I have float:center and float:bottom as well please
And while we’re wishing, is there any reason we can’t have IF and FOR statements?
And vertical auto-margins or vertical-align for blocks. And parent selectors. And a p0ny.
The great thing about open standards is that people who are interested enough can actually influence them.
Hm. I’d like to keep my hair.
Since the discussion was becoming completely off-topic, I felt it appropriate to establish a new thread for discussion relating to feature requests in CSS.