CSS Stacking Contexts

Intro

Today we’ll be learning about a lesser-known feature of CSS: Stacking contexts.

You may have been working on a project before and been surprised when you set the z-index for an element and it refused to move forward, remaining behind some other stubborn element.

There’s a reason for this behavior, and that reason is stacking contexts.

Stacking Context

A stacking context is essentially a group of elements whose z-index value determines their position within that group. If two elements do not share a stacking context, then they will ignore each other’s z-index values.

In this case, the stacking order is based on their relative order in the DOM (See image under “Creating a Stack”).

Creating a Stack

All of the common stacking context types.
All of the common stacking context types. Order is relative, fixed, absolute, opacity, transform.

A stacking context is created in the following cases:

  • The root stacking context (html element)
  • Absolute or relative position with a set z-index
  • Fixed position
  • Opacity less than 1
  • A set transform
  • A few other less common instances

I’ll be covering only the common instances that developers will normally encounter.

The Root Stacking Context

This case is pretty clear. Initially, all elements are part of a single stacking context under the DOM, meaning that their relative position on the z axis is determined entirely by their z-index property. If no z-index is set, their order is determine by the order in which they appear in the DOM (See image under “Creating a Stack”).

Absolute or Relative Position With a Set Z-Index

This case is the second-most common. This is almost always intentional, but occasionally, developers may try to position an element in another stacking context over some absolutely positioned element and find that it’s not possible.

Fixed Position

Another common case, but one that can be confusing. Most but not all browsers have this behavior now. Fixed position elements create their own stacking context, which without a z-index normally places it behind the document root. This can create a case of disappearing elements.

Opacity less than 1

This is a rare case, but one that everyone should be aware of. If you’re going to set opacity, then you have to know the consequence will be a new stacking context. If all you want is a translucent element, it will be more predictable if you simple set an rgba background with an alpha less than 1.

The reason for this is clear: If it did not create a new stacking context, what elements would show through the transparent element?

A Set Transform

This is a case which is more and more common lately, as CSS transforms become the norm. This often throws people off, as we assume when we scale an element it should retain its position in the flow of the document. The new stacking context can cause a transformed element to hide menus and other elements which would normally appear in front.

How Stacking Contexts Interact

Of course, the most important thing is how to apply this knowledge to create layouts and fix problems in the real world. For this reason, I’ve supplied some examples of how stacking contexts interact with each other. Most importantly, how do their children determine their z-positioning relative to other stacking context’s children?

Well, using the example from “Creating a Stack”, here’s what happens:

Z-Index Set

Z-Index on Relative Element's Children
Z-Index on Relative Element’s Children

If we set the z-index of the child elements, the result is the same as our original elements.

Z-Index Positive, Position Relative

Z-Index on Relative Element's Children - Children Are Relatively Positioned
Z-Index on Relative Element’s Children – Children Are Relatively Positioned

If we set the z-index of the child elements to a positive value, but additionally set the children’s positions to relative (creating a new stacking context for each child), then they will position completely independently of their parent, moving out in front of the other elements.

Z-Index Negative, Position Relative

Negative Z-Index on Relative Element's Children - Children Are Relatively Positioned
Negative Z-Index on Relative Element’s Children – Children Are Relatively Positioned

If we set the z-index of the child elements to a negative value, but additionally set the position to relative (creating a new stacking context for each child), then they will position completely independently of their parent, moving behind the other elements.

Z-Index Greater Than Other Stacking Context’s Children

Relative and Fixed Element with a Set Z-Index, Children With Set Z-Index Values
Relative and Fixed Element with a Set Z-Index, Children With Set Z-Index Values

In this case, we have given both the relative element, and the fixed element a z-index. The z-indices of their children do not interact, so even though the relative children are positioned ahead of the fixed children, they do not appear that way. The children are each in separate stacking contexts, though their parents share the same stacking context.

Conclusion

Stacking contexts are groups of elements whose z-index values position them along the y axis relative to each other. If an element is the root of a stacking context, its children will ignore the z-index values of the children of other stacking contexts, even if they are larger than its own.

Stacking contexts are very important when creating layouts in CSS. A lack of understanding of stacking contexts can lead to difficulty implementing relatively simple UIs, and in fixing bugs which arise commonly in today’s UIs. Stacking contexts are very commonly created when showing things like menus, popups, windows, etc. These types of UI controls are very common in web applications today, and therefore so is knowledge of stacking contexts and how they interact.

Representational State Transfer (REST)

What is REST?

REST is an architecture which describes a system that transfers generally non-static content between a client and server. This content is called a resource, and is always some uniquely identifiable “thing”. RESTful services implemented on top of HTTP are a popular solution for web applications today.

Representational

REST is representational in the sense that every request must uniquely identify a resource. A resource is something which is uniquely identifiable. The meaning of uniquely identifiable can essentially be defined by the system, and is dependent on the level of granularity at which the system works.

For instance, on one system, perhaps a hospital is a unique resource, but on another system, each of the hospital’s buildings are considered independently, so you could not for instance request the completion date of the hospital, but only of a specific hospital building.

State

A RESTful service always returns stateful data. That is, it is returning the current or specified state of the specific resource, which is not necessarily and not usually composed of static data.

For instance, suppose that our hospital added a new wing. The resource representing the hospital, if it is a correct stateful representation, would then reflect this new building. Any request made prior to the addition of the new wing would return it’s current state – without the new wing.

This should not be confused with the statelessness of the requests. A RESTful server maintains no data about the state of the client or its requests.

Transfer

Transfer of course refers to the movement of data between a client and server. Data can flow both ways in a RESTful service, which usually supports the CRUD operations in addition to request types like HTTP OPTION, etc.

How did REST come about?

First, HTTP

The Hypertext Transfer Protocol, or HTTP, was the necessary precursor to what we consider a modern implementation of a RESTful service. HTTP provides a client-server architecture that focuses on text-based requests of documents. Because the text-based requests use URIs (unique resource identifiers), they are uniquely suited for use in a REST implementation, which is based on the concept of resources.

HTTP was originally proposed by Tim Berners-Lee, as a document storage and retrieval system between remote clients and servers. The original HTTP had only one method, GET, meaning that it would not be as suitable for a REST implementation as it is today.

HTTP soon added many methods, which made HTTP suited for a REST implementation. These methods included POST, PUT, and DELETE, which are used in today’s RESTful services to represent update, create, and delete operations respectively.

The Concept

The concept was coined in 2000 for a PhD dissertation by Roy Fielding. The concepts behind REST were used as the backbone for the URI standard used in HTTP requests. HTTP was therefore RESTful in its initial implementation (v 1.1). The difference between this and modern REST concepts is that the resource can be many more things than simply a static HTML document.

From this point, RESTful concepts were heavily adopted in the Web 2.0 age of asynchronous requests which loaded content in real-time into the browser. RESTful concepts enabled relatively simple and very consistent APIs to be created which abstracted this process heavily and eased implementation of complex applications handling asynchronous data requests.

What makes something RESTful?

There are five aspects necessary for a system to be considered RESTful, and one optional.

Client-Server Interactions

The architecture must start with a client-server model, where a single server hosts the unique resource, which a client may request.

Stateless Requests

This constraint means that the server cannot store session data from a client. Each request must include the session data necessary to execute the request.

Cacheability

Requests much be created in such a manner as to be identifiably cacheable or not. This allows an intermediate component to perform caching, without special system knowledge.

Layered Architecture

Each point of processing should not have awareness of other parts of the processing chain.

Uniform Interface

The system must define a consistent API, which decouples the requests from the implementation.

Transfer of Logic

An additional concept sometimes considered is the ability to transfer logic representations that can be executed on the client. This includes scripts, applets, etc. Many people are surprised to learn that this idea is part of the original PhD dissertation, and that implementation did not catch up to the possibility of the concepts for about a decade.

What is the purpose of REST?

The purpose of REST is to provide an architecture which creates sufficient abstraction in a large complex, distributed system of unique resources, so that a client-server model of resource access, alteration, and creation, can occur without significant complexity and overhead, even in a system of global scale such as the World Wide Web has become today.

How is REST Used?

REST today is the backbone of HTTP. All common HTTP requests are stateless, and conform to all the five criteria for a REST implementation.
However, the more common modern usage of REST today is in the implementation of a RESTful service on top of HTTP. These services are used to provide a layer of abstraction from data access and representation, so that client code can easily manipulate the resulting structures and compose requests to interact with this data.

Many times, the RESTful service is implemented as an API for simple external access, with an authentication scheme built on top of it. These heavily abstracted interfaces can allow several entirely tangent applications to consume and alter data in a manner consistent with their implementation, while maintaining a single distinct data source.
It also can allow for the distribution of the total request load across several servers, which simply have to be aware of the API implementation and a data source.

Conclusion

REST is an important architectural model that defines itself as a set of five or six restrictions on top of an “unbounded” architecture. REST is not any one implementation, or any one concept or use case. It’s a highly extensible architecture that drives the web as we know it today, but is independent of its implementation in HTTP.

Many descriptions of REST are overly academic or too specific to a single implementation. I hope that I’ve provided a good resource on the fundamental meaning and purpose of REST, independent of HTTP, as well as its use in HTTP and web services today.

Given that this is a complex topic, on which all information essentially traces itself back to that single dissertation, it’s possible that some information may be inaccurate, so please let me know if you find these types of mistakes and they will be corrected immediately.