Don't we love CSS? it's so easy to do both complex things like 3D animations but also simple things like position something centered horizontally or vertically by just saying align:center, oh, sorry, it's margin: 0 auto, right, no? it's left:50% with a relative inside an absolute div, or was that an absolute div inside a relative span?
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
The really crazy thing is that we had great proposals for much better layout systems, and they were rejected:
- 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.
The CSS layout model (with float/clear, display:block|inline|table-cell, vertical align and so on) was based closely on how browsers already rendered layout. For example float, clear and align were attributes on image and table tags before the invention of CSS. CSS just allowed you to decouple these layout properties from the HTML elements.
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.
I've tried to find some sort of backing theory to CSS, but I've only found references to authors, not rationales . You would expect it to be founded on some solid typesetting theory. It would be very interesting to hear how the authors reasoned. I personally find that it seems really flexible, but anything that you want to acheive is hard or inconvenient. So what is the flexibility good for?
CSS was not based on any specific theory, but rather on the actual rendering model of browsers at the time. This in turn was presumably based on ad-hoc decisions by Netscape when they added features. For example, the float/clear model were created as a way to allow text to float around images when Netscape added support for embedded images at the dawn of time.
Does anyone have any insight as to why it is this way? To me it seems insane, but I don't trust my own judgement in domains like this because I've never built anything comparable. Are there really good reasons for CSS to be the way it is?
(I don't think they're good reasons, just reasons)
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.
Imagine if Ford, GM and Chrysler had to build cars that shared the same roads, used the same fuel, fit in the same overall dimensions for parking and driving, accepted the same basic controls: Steering, foot pedals, etc. It would be madness.
Those features are the madness of standards enforced under penalty of law. CSS is a recommendation, and the only penalty is a competitive disadvantage.
Back when the Internet was a graphically simpler place with a browser monopoly, there was little disadvantage to implement CSS however they damn felt. If Ford sold 90% of cars and a consortium recommended they add 12 new safety features, imagine how they'd respond.
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?
1. CSS1 started modestly by specifying very little over what browsers already did at the time, and from the start locked itself into HTML's inline/block/float/table model.
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.
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).
Your argument might hold more water if your example actually vertically centered anything.
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.
genuine question as a non front end engineer- do you recommend reading the CSS spec as a reference guide? im basically asking whether someone learning to be good in CSS should read the spec or pick up one of the recommended books (that appear from time to time on HN).
For example, i never had to read the spec for ruby to get jruby to work.
There may or may not be Great CSS books out there, but in 10 years, I never found any. They invariably teach you recipes, but not how to to think in the terms the language was designed.
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.
I'll admit I haven't read the CSS spec, but I have been reading the canvas element spec in detail, as there's little good, deep reference material for it. It's readable, or at least understandable, but it's challenging compared to more traditional reference books (like MDN's presentation, for example).
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.
I think generally speaking, reading the spec is useful when trying to figure out the details of more complex topics, I think this holds true for most languages. I used to pull out the C spec regularly, and even the c++ draft spec on occasion, it gets better for smaller languages, for Scheme for instance, I would pull out the spec rather quite often.
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.
I don't have a reference for this, but I always got the impression that CSS was intentionally limited to help browsers implementers write efficient layout engines with as few pathological cases as possible. For instance, if you could specify the value of object attributes using arbitrary expressions with other objects' attributes as input, it would be very easy to have circular dependencies, unexpectedly high computational costs, contradictions, and so on. Just defining how to solve a contradiction would have made the standard much more complex, and error reporting would have been a nightmare.
I think that while that may have originally been the case, I feel that we've long since passed the point of particularly efficient layout engines with as few pathological cases as possible. Particularly computational costs, since I think you'll find many sites doing some part of layout in javascript.
Because we used to do these things with tables but tables aren't cool enough since the "War on tables" (because tables aren't the right way to do layouts) and nothing better has been available. Hopefully CSS3 will fix these things.
I teach classes on SVG, and CSS is one of the toughest parts. The distinction between styles and attributes seems very arbitrary in SVG. There are many layers of inconsistency. Compare text-align for HTML and text-anchor for SVG:
text-align: left | center | end | justify
text-anchor: start | middle | end
The only argument in favor of CSS not being the most horrible thing ever invented is that as far as I know, nobody has come up with a better alternative yet…
That "spec" was a Working Draft in June 2012 and a Candidate Recommendation in September 2012. It's still not final. And browser vendors have implemented prefixed versions (even Microsoft!). I think it is reasonable to criticise the W3 for not finalising something we've been struggling with for over fifteen years.
plus:
these kind of "tricks" (changing opacity to alter the stacking order) will not always be (mostly not) accepted at work, because the logic behind it is not immediately clear and its not portable.
[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.
I had no idea that was the case. The CSS 2.1 spec [1] notes that "other properties may introduce stacking contexts, for example
'opacity'". The CSS 3 spec [2] elaborates:
> 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.
Serious question: why do stacking contexts exist? They seem to defeat the whole purpose of z-indexes, which is a global way of determining what shows up in front of what else.
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?
It seems to be to make pages more composable - so at the top level you can specify what order block A and B are stacked, and within A and B you can independently specify what order the blocks that make those up are stacked.
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.
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."
A stacking context is analogous to a frame buffer object in OpenGL or a render target in Direct3D. (I'm reasonably sure this is what at least some browsers do for rendering elements with partial opacity.) The difference in opacity (generally) necessitates rendering the content in its own buffer and then rendering it into the viewport.
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.
Long text for just a few explanation. As a developer I hate reading those kind of tips since it doesn't go straight to the point. Here's my tl;dr :
> 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.
11 paragraphs + code snippets just to say: "opacity" creates a stacking context. And a really annoying way of teasing and dragging the "observation" until the end of the article.
I've always wanted to get into web design, but every time I read an article like this, I get scared. Sometimes it seems like the web is
nothing but hacks piled on top of hacks...
(I'm guessing that) since opacity is a "postprocessing operation"[1] it has to 'redraw' the entire div which causes it to fall back to it's parent order in the stack.
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
Which is strange because many other frameworks will end up popping elements with postprocessing effects to the top of the stack, rather then rerender the entire stack.
I've learned never to add rules to the asterisk ever, after being badly burned on other projects multiple times.
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.
I can't find any information about `position:relative` impacting page render performance. Please share.
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.
While true, I find that the instances that I need something to be absolutely positioned outside of it's context are few and far between. Also, it is quite easy to set position static on the parent elements.
Every new developer will need to wrap their head around nonstandard page flow
I work with a team that is on board with this, so it hasn't been an issue yet.
position:relative is probably not that expensive, but the '*' causes very negative impact - the browser will scan the whole tree trying to match the rules every time the DOM changes.
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).
I've read that, his argument is that "it's negligible", not that it doesn't have an impact. In his anedoctal evidence link it's adding 15-30ms to render times.
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.
This seems more like a bug in opacity than anything. Logically, opacity should have no impact at all on layout positioning, only on blending. So this is more of a workaround created to speed up processing of elements with opacity less than 1 that introduces a design bug in the spec.
I'm no expert on the matter, as I just learned about this about 90 seconds ago… but here's my guess:
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.
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.
If the model were to stay the same, I'd like to see something like stacking-context:break to start a new stacking context with the targeted element as parent, stacking-context:inherit for children. Same as we have now, but with the option for manual control.
This article should really be titled "What No One Told You About Opacity". I think all the z-index stuff is pretty well-understood. At least by people who consider themselves pretty good at css.
I don't really want to add to the dogpile of comments explaining why you missed the point, but the blog post pretty clearly states what the criteria for the "challenge" were:
"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."
Yeah I'm really not sure what you're trying to say. He explictly set the z-index on the elements by editing the CSS. It wasn't the inherent act of editing the CSS that was the violation -- explicitly setting the z-index was.
The point was that there are factors other than z-index involved in determining the stacking order. I'm certainly not suggesting anyone use opacity to move things around in the stacking order. I was just trying to make people aware of it. It's confusing if you don't know what's going on.
The point of the example was to show how something other than z-index, position, and order can affect stacking. It wasn't demonstrating the correct way to go about changing the stacking order.
The point of this exercise was to show that opacity has an effect on element position, which was surprising to me! It matters because it might fix a z-index bug you have one day (:
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>