In the current proposal for Container Queries, a container is any element with both layout
and size
containment. With the addition of 1D size containment (currently only inline
), that can include size-containment in the axis being queried. At this point:
.container-2d { contain: layout size; } .container-inline { contain: layout inline-size; }
If block-only containment is possible, that could expand to:
.container-block { contain: layout block-size; } .container-width { contain: layout width; } .container-height { contain: layout height; }
Once a container is established, it acts as a container-query target for descendants. That raises a few related questions:
layout
and size
containment, without establishing a new container context for descendant queries? (I don't believe that there is, based on my research so far. Authors generally want to query the closest context possible.)New syntax might help address any one or all of those cases, but each use-case might lead to slightly different solutions. This could happen with new values on the contain
property, or with a new property (all names to-be-bikeshed):
/* keyword as shortcut for layout/size */ .container-2d { contain: query; } .container-inline { contain: inline-query; } .container-block { contain: block-query; } .container-width { contain: width-query; } .container-height { contain: height-query; } /* new property, also triggers appropriate layout/size containment */ .container-2d { container: size; } .container-inline { container: inline; } .container-block { container: block; } .container-width { container: width; } .container-height { container: height; } /* queries that don't rely on size containment?? */ .container { container: ???; }
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3