CSS Containment Draft

[Wilto]

So, there are two sides to this: the CSS side of things (“what do the element queries look like”) and the element side of things (“how do we define an element as having viewport-like qualities”).

We can’t treat every element as having viewport-ish behavior, or we end up with a fractal nightmare of reevaluation and potential infinite loops: an element sets a child element to width: 200% which cascades back upward and changes a series of parent elements each with potential element queries attached, and one of those causes the width: 200% EQ to no longer apply, and so on unto infinity. There have been a few things up for discussion: a specific “treat as a viewport” element or attribute among them.

http://dev.w3.org/csswg/css-containment/#containment seems like something we should be keeping an eye on, since it deals with special-casing elements independent of the rest of the page, though in a very different way.

[tabatkins]

We can’t treat every element as having viewport-ish behavior, or we end up with a fractal nightmare of reevaluation and potential infinite loops: an element sets a child element to width: 200% which cascades back upward and changes a series of parent elements each with potential element queries attached, and one of those causes the width: 200% EQ to no longer apply, and so on unto infinity.

Nah, the point of viewport-ish behavior is that children have no effect on your layout, so it's okay. The reason we can't treat everything as having that behavior is because it's a terrible behavior for most elements, who really do want to be sized according to their children.

[Wilto]

Ah, okay, thought it upped the “infinite loop” potential.

[uniqname]

I've been bouncing my thoughts on this off my co-workers but I apologize if it's still rather unformed or too low level right now. I just needed to get it out of my head and in front of those with a deeper understanding of it's implications.

Currently floated or inline-blocked elements take on a size imposed by their content/children. This is what sets up the infinite loop problem, no?

Is it possible to invert this model for an element that defines an element query? For example, when the CSS parser comes across an element query, anything matching the selector within it would be layout deferred until the rest of the those element's subtree's styles are applied. At that time the parent of the element using an EQ would have determined it's size as per the traditional model, based off it's children not using element queries. Then, children querying the parent element have accurate properties to query against with the layout engine enforcing that styles applied to elements using EQs do not affect the properties queried against on the parent element.

IOW. if an selector queries on it's parent being a certain width, and it applies a width to itself. The element would simply overflow it's parent container rather than affecting the parent container's width.

This would mean any styles applied to an element that is using EQs that may be defined in another stylesheet, and which affect the property being queried against, would still not affect the parent property. In effect the querying element would be but in an element query mode that would prevent the property styles being queried against from "bubbling" up.

I'm sure I'm missing some important issue here, apart from the probably dramatic impact to the layout engine this would have.

[tabatkins]

Browsers aren't generally happy with drastically changing how they do layout based on style information, because that means they can't usefully start doing layout early (they might have to throw out a whole subtree of work when they realize it's viewport-ish). They want something that can be determined at the markup level, hopefully.

[uniqname]

I was hoping to avoid that with the deferring of rendering the specific element doing the querying, but I admit I don't know enough about layout engines to know if that would matter enough.

[tabatkins]

"Rendering" is one thing, but layout calculations are another, and an element becoming viewport-ish can change the entire page's layout.

[davidjgoss]

This syntax idea is far from thought through, but I might be worth throwing into the ring.

@container ".block" and (min-width:615px) {

    .block__element {
        // rules
    }

    .block__other-element {
        // more rules
    }

}

This is expressing: "When there is an element that matches the selector ".block" whose computed style matches the query "min-width:615px", apply these rules only descendants of that element".

I'm hoping that having a selector for the container in the @container -part will avoid the need for an attribute in the HTML to declare an element that will be viewport-y --- that is, that the parser could do a sweep of the stylesheet to find out before starting to fully apply the styles.

Any thoughts?

[Wilto]

Ah—suuuper early to start talking syntax. There are a lot of technical things we have to sort out way beforehand, just to see whether there can be a viable approach to this.

[davidjgoss]

@wilto Yeah sorry, jumping ahead with the specifics of the syntax, but my main thought was whether the viewport- ish elements being declared in CSS with selectors like that would be an option technically as opposed to markup.

[yoavweiss]

+1 to having "viewportish" hints in markup. Is go further and say that the actual dimensions should be available at preload time, if we want to throw responsive images into the mix (and I think we would want that). So they'd have to be either in the markup itself, or inlined

[tabatkins]

I think that's unnecessarily limiting; having the element respond to its surroundings by, say, being in a grid layout is very useful.

We shouldn't restrict this more than the existing