What No One Told You About Z-Index
philipwalton.com
philipwalton.com
ok so doing it vertically is really easy, it's valign:middle, oh, wait, I'm confusing yucky table layout, it's much simpler, it's, ehm, line-height or something, or vertical-align, but only for text, sorry, silly of me, I just do top:50 and the relative inside absolute trick again (or vice versa, one sec let me check in JSFiddle),
Ok aligning might not be a good example, but it's so easy to have something snap to something else, like this DIV top right corner should always be on the buttom left of that other div, oh, can't do without some jQuery code? of course you can, let me go to codepen and show you for a sec, ok, never mind that, at least it's so easy to columns (more than exactly 3) that one of them is fixed width and the others are variable width, that's why we have float:left, float:right and well, nevermind.
But I can have a left navigation bar that will stretch to the bottom, or have a footer that will stay down when resizing, it's all easy and done without any workarounds or tricks or endless trips to stackoverflow or using zurb foundation / bootstrap.
So I'm surprised that a simple thing like putting something on top of the other got to be so complicated, well, you can't have it all, nothing is perfect
</rant>
- First, the model with "springs and struts", employed by all major native GUIs for decades, and also implemented in Firefox as the first Flexbox model (for XUL, the UI description markup language) since ages.
- Second, the constraints-based layout model, now employed by OSX 10.8 and considered even superior, was proposed in 1999! http://www.cs.washington.edu/research/constraints/web/ccss-u...
The only explanation I can come up with is a giant disconnect between users (web developers) and implementors.
So basically the CSS layout model were designed by Netscape before the CSS spec were developed.
Should the developers of CSS have discarded this model and instead proposed a different model would require the browser vendors to redesign their rendering engines? I think this would never have worked - remember this was at the height of the browser war, where Netscape and Microsoft routinely ignored W3C standard to pursue proprietary alternatives. We should probably be happy that we got something like CSS at all.
1. Unlike print layout, the dimensions of a webpage can change, and so we slowly invented an evolving layout framework for something without fixed dimensions. I've done typesetting since it was exacto knives and hot wax, and if you told me then to imagine a stretchable paper for news I would have cried in the corner.
2. The layout framework was independently built by a bunch of separate companies, who by nature of competition weren't going to agree on everything (see every browser).
3. The agreements that WERE made were done by committee, including the reluctant inputs of competing companies. This method of design will guarantee that they end up with something weird.
4. Make it backwards compatible with all the previous ghosts of architects past.
Imagine if Ford, GM and Chrysler had to build a joint car every few years.
Also, try designing a page in Flash and using (or just reading about) their graphics/layout/text frameworks. Some things are much harder than HTML/CSS, some are much easier, but it offers a great comparison on a completely different way of solving layout. I've implemented a spec like CSS for customizing Flash app appearances, and compared to what existed before, it made everything better.
This reminds me of DOCTYPE switching. From http://hsivonen.iki.fi/almost-precedent/: "Back when the Quirks Mode and the Almost Standards Mode were introduced ... committees created specs and that were enshrined as W3C Recommendations before there was solid implementation experience. Then the Web Standards Project lobbied browser-makers to implement the W3C specs as they were. The mindset was that the specs given from above couldn’t and shouldn’t change. People thought that vigorous upgrade evangelism would work and make Web authors change their existing sites."
Note that the Web Standards Project was also the one petitioning Netscape to cancel Mariner, which ended up contributing to the problem. Why did non-IE browsers have to implement document.all?
Back then the old Netscape engine was dominant and it couldn't get even those basics right (http://acid1.acidtests.org), so there was no hope of adoption of a more advanced layout mechanism.
2. CSS had deliberate limitations that did help early implementors: e.g. elements later in the document are not supposed to cause reflow of elements earlier (with tables being "legacy" exception). That's how Opera worked until v6. That what helped all browsers implement progressive rendering. The downside is abysmal vertical centering and limited selectors (flexbox and CSS4 selectors finally drop that limitation).
3. It was hard to get any progress on this for many, many years. First we had Netscape 4, then we had IE6 holding back use of CSS on the web, so specs from that time were mostly untested ivory tower science-fiction.
Things got better since, but of course now we have massive legacy and backward-compatibility constrains... and IE8/9 holding back flexbox.
"Does anyone have any insight as to why vertical centering of dynamic-height content is the way it is?"
Yes. The original standards committee created a layout model (block, inline, and inline-block elements) that (they felt) adequately balanced language complexity with features. It's easy to idiomatically achieve vertical centering. http://jsfiddle.net/aMMxj/10/
"Does anyone have any insight as to why people that code CSS complain about it so much?"
This is a much deeper question, but one that I think is far more informative. Having done front-end engineering for 10 years, across industries, and in very pricey and exclusive consultancies, I have never found another engineer who had read the bulk of the CSS spec, or even a book about it, for that matter.
Developers, the ones with the mind and experience to bring technical discipline to CSS and create a set of idiomatic patterns (both low-level and high-level), treat CSS as a second-rate citizen. The bulk of the rest of the CSS userbase consists of visual design types (coming from print or graphic design), where the tools of the trade are physical pen and paper, or something from Adobe Creative Suite. The remaining portion of the userbase are equally non-technical hobbyists.
This is the real problem of CSS. Those that have the mindset to devise idiomatic conventions to the community don't think the language is worth it. At best, you have semi-experienced developers duct-taping various non-idiomatic ideas together and giving it a fancy name.
that solution
1. only works for text, which is part of eranation's rant.
2. only works if you know the exact height of the container.
3. isn't even centered: http://i.imgur.com/lz8Mq.png
2. Fair enough. It would be nice to be able to set line-height to a percentage of height.
3. Bug, my bad. http://jsfiddle.net/aMMxj/51/
I added a background image with a grid that extends 80px from top and bottom. There's also a small margin/padding/border reset and doctype just to make sure defaults and quirks aren't messing with anything.
To continue down this path of the "natural" way to vertically-center, font-size must also be explicitly set. This works http://jsfiddle.net/nJy8t/3/ . Though it's certainly not without it's flaws (we lose font-size cascading).
It's 2013 and it's still in many ways easier to do pixel-perfect, scalable layouts using tables than it is with CSS. It's so bad a common CSS 'layout technique' is to force elements to be laid out like table cells! I find that incredibly depressing.
Many of those so-called 'idiomatic conventions' that you blame developers for not devising are avoided because they're needlessly complex, easy to get wrong, and hard to maintain. Nobody likes having to wrap every piece of content in 3-5 nested divs/spans with complex style rules applied to them.
Idiomatic solutions, by definition, cut out the non-semantic document structure. Certainly you will find layouts that cannot be achieved idiomatically in CSS, just as certain software patterns are more idiomatic in one OO language than another (e.g. observer pattern in C# vs Java). But the more scenarios you attempt to address with the language, the more complex it becomes. It's quite possible that extensions to CSS would open it further to the criticism that it's too complex.
Unfortunately, browser vendors do not support any other stylesheet language. Perhaps if this were different, there would be more effort to understand stylesheets from an engineering perspective. Since it's not, we're stuck with poorly-thought conventions and a community that's been trained to despise the language.
CSS is not a happy language, that much I'll agree with. But I find it no more painful than other computer languages. I reassert the lack of rigorous analysis by CSS users and the collective community as the main solvable problem. I have worked at extremely pricey consultancies, and the only thing I learned about CSS from them is that the more senior of a developer you are, the less respect you have toward CSS as an engineerable technology.
For example, i never had to read the spec for ruby to get jruby to work.
The ruby community is one of the most active and rigorously analyzed in contemporary programming. Blog articles are well vetted, and Google search can reliably point you to decent articles. Further, ruby belongs to a class of languages (interpreted, general purpose, imperative/OO) that is very well understood. Languages from this broader ecosystem include python, perl and even JavaScript, all contributing to a deeper analysis of each.
CSS is a stylesheet system. There are no other popular systems in use. The comparison could be made to Microsoft Word's style system (which has a very different conceptual model). Such a comparison could yield interesting ideas. But such a comparison is never made. Other stylesheet languages for structured documents include the unknown FOSI and DSSSL. When was the last time anyone cited those referenced in a blog post, tutorial, or book about CSS?
I'm not saying the specs are a good teaching device either. But teaching and precise description are different ends. Regardless, because there doesn't exist a good community (incl blogs, books, personalities) to fall back on, the specs are your best bet. Ultimately, they (along with other implementations) are what inform browser implementations.
there are other community-driven sources - like RubySpec [1], etc. but this is the (expensive!!) ISO standard.
FYI - I had intended it as an example. I'm really interested to know if the most effective way to work with CSS is to understand its spec... which is not the way it works with most programming languages.
But perhaps CSS is more similar to a rulebook (declarative) than a language.
Since I imagine the CSS spec is relatively small (compared to say C++) I imagine it would be useful for solving more adavnced use cases.
it would be nice if there was a modern update of CSS.
text-align: left | center | end | justify
text-anchor: start | middle | end16 years after CSS was released unto the world, and it still lacks a decent way to center content. Makes me lose all faith in the W3C.
<div id="container">
<div id="centered"></div>
</div>
#container {
display: flex;
width: 1000px;
height: 1000px;
background: gray;
}
#centered {
margin: auto;
width: 500px;
height: 500px;
background: red;
}
How not? It's strictly and clearly defined in the standard.
https://developer.mozilla.org/en-US/docs/CSS/Using_CSS_flexi...
[2] Firefox supports only single-line flexbox. To activate flexbox support, for Firefox 18 and 19, the user has to change the about:config preference "layout.css.flexbox.enabled" to true.
> New stacking contexts can be formed [… w]hen an element has an
> opacity value less than 1.
> Since an element with opacity less than 1 is composited from a
> single offscreen image, content outside of it cannot be layered
> in z-order between pieces of content inside of it.
Z-index only works on positioned elements. If you
try to set a z-index on an element with no position
specified, it will do nothing.
I'm trying to wrap my head around them -- I guess the main takeaway is, if you don't ever want to have to deal with them, then don't ever use nested elements where both have z-indexes?
This way you can change the relative order of A and B without worrying about how those blocks are internally structured, and whether they use z-index themselves.
"7 Styles
To enforce upper-boundary encapsulation, CSS rules declared by the document must not apply in a shadow DOM subtree, unless the apply-author-styles flag is set for this subtree. The flag signals that document CSS rules are applicable in the shadow DOM subtree.
Conversely, to enforce lower-boundary encapsulation, CSS rules declared in a shadow DOM subtree must not apply in the document tree."
It's fairly prohibitive to try to correctly break up the differing Z-indexes and do the right thing when rendering, and was probably easier, with no real loss of functionality, to introduce stacking contexts.
> the stacking order is the same as the order of appearance in the HTML
Actually this is false, as last in code is displayed on top
> When you introduce the position property into the mix, any positioned elements (and their children) are displayed in front of any non-positioned elements
Use a "position:" and it will go on top of div not using it.
> z-index only works on positioned elements
use "position:" to use "z-index" otherwise it won't work.
> ...
I felt like the rest was unnecessary unless you plan to play a lot with z-index. Then you can get a better tutorial/article/documentation on it.
If it's a stack, then the last one _is_ displayed on top.
But I'm not sure if this is a fair assessment, as you're applying opacity to the div instead of the span.red, the element where the rule was applied. When adding opacity to the span the z-index stays intact
Adding opacity to the span has no effect because it already has position:absolute.
* {
position:relative;
}
Refer to my GitHub repo for the code for my base structure for new projects.
At first glance, this rule appears more innocuous than others I've seen, because position is never inherited. (Unlike a font-size in a plug-in that broke every inherited font-size on the whole site).
But extra position:relative declarations can cause big problems on mobile browsers (including iOS6) when combined with CSS transitions. Don't ask me why, just browser bugs. I'd be extremely wary of any kind of global layout-fixes like this.
Given my experience of low impact on render performance of vanilla properties like this (transitions are a whole 'nother story), I'm much more concerned with whether this is of benefit to developer happiness.
You'll never be able to use `position:absolute` for anything outside of the context of an element's parent, and opting out of this back to default behavior is much more painful than opting in with a better-scoped `.feature * {position:relative}`.
Every new developer will need to wrap their head around nonstandard page flow, and customizations like this have a way of accumulating into a very intimidating environment. As a general rule, I don't want to inherit anything silent and clever without very compelling reasons (* {box-sizing:border-box} passes this test because it makes so many things so much easier).
You'll never be able to use `position:absolute` for anything outside of the context of an element's parent.
Every new developer will need to wrap their head around nonstandard page flow
Also, refer to this: http://css-tricks.com/things-it-might-be-funuseful-to-try-th...
The '*' selector shoots up the chart, and for some reason the browser lays down a lot more rules then when it's absent. 2ms is not much, but when complexity increases it all adds up (games, client-side apps, etc).
http://paulirish.com/2012/box-sizing-border-box-ftw/
Specifically the Performance section.
Add a couple * selectors - one in the reset, one more in your base sheet - plus a couple descendant * selectors, global box-sizing/position rules and you've put a heavy saddle on the matching and rendering engine. It might not matter for 80% of websites, but you need to be aware of it.
My understanding of it is that if an element has < 1 opacity, something different needs to occur to properly render that element. For an opacity of .99, not much visually, but if the opacity is .5 how will it know what elements to display under the partially opaque item?
I'd be curious to see some source code to know for sure, but that's my best guess.
http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparen...
The CSS3 spec describes that the element with opacity < 1 should be composited off screen. Therefor, an element with opacity < 1 must create a stacking context, because its content layers cannot 'intertwine' with other layers not inside the element.
Let's say you'd have a rule that pokes a hole in a layer. If that layer contains several pieces of paper, then the spec would say to take the layer with those pieces of paper aside, poke a hole though all of them, then place the layer back where you found it. This way, other layers on the page are not damaged. /end analogy.
It is a bad dream.
So the results is the same, but the method is incorrect? does it matter? hmm
"Here's the challenge: try to see if you can make the red <span> element stack behind the blue and green <span> elements without breaking any of the following rules:
Do not alter the HTML markup in any way. Do not add/change the z-index property of any element. Do not add/change the position property of any element."
He didn't enter text in the CSS editor. He pressed some buttons on a keyboard.
We could keep at this for a while, if you want.