tl;dr Developers would like the idea to style components based on a parent's width rather than depend solely on the viewport media query. This would allow modular components to style themselves while being agnostic to the viewport.
There is currently a lot of developer interest in getting a feature like Container Queries (née "Element Queryies") shipped in a browser.
Here are official'ish documents to outline the developer community's desires.
- RICG Container Queries Editor Draft - this is an incomplete rough draft but outlines the need and usecases for Container Queries fairly well.
- RICG CQ Usecases - Active issue threads circling around usecases.
- Container Query Demos - This repo will eventually house usecase demos.
Initial feedback from spec authors (namely, Tab Atkins) was that Container Queries could quickly enter recursive layout calculation if a matching query on a child element affected layout on the parent element.
.parent:container(max-width: 500px) {
.child { width: 600px }
}
- Jonathan Neal compiled a list of properties that could affect layout, there are quite a lot of properties. This seems like a no-go.
- Tab suggested maybe this aligns with CSS Containment, maybe in the Shadow DOM, and/or there's an
iframelike layout property that can be set (e.g.layout: contain) - Martin Auswöger has proposed and polyfilled a slightly modified method where if a width is detected, a property is set by the browser and children are re-evaluated. The double-evaluation is a noted concern.
There are lots of repos dedicated to polyfilling this experience. Each with it's own custom syntax.
- elementQuery (Jun 2013)
- css-element-queries (Jun 2013)
- eq.js (Oct 2013)
- Elementary (Nov 2014)
- Boomqueries (Dec 2014)
- EQCSS (Dec 2014)
- cq-prolyfill (Jul 2015)
- Shopify - Using CQs all across the site and User Interface
- Weather.com - All news submodules are using EQ.js
- Cassina Group - Card interface in a Real Estate website
RICG CQ Use case URL needs an update to: https://wicg.github.io/cq-usecases/