ContainerQuery now stores its feature requirements. When evaluated, it
uses these and the passed-in container name to identify a container
element to match against, then evaluates its condition against that
element.
None of this is yet in use anywhere, but will be soon.
A given element may be a container in different ways, depending on its
`container-type` property. For a container query to match an element,
that element must have the required container type for each feature
that the query checks. This commit implement a step to collect those
required types, so that we can quickly eliminate potential container
elements that lack a required containment type.
Different users of BooleanExpression have different requirements for
evaluation:
- `@media` needs a Document
- `@supports` doesn't need anything
- `@container` needs a container Element
To support these without expanding the API, replace the Document*
parameter with a BooleanExpressionEvaluationContext type which contains
these different values.
No behaviour changes.
No parsing yet, just CSSContainerRule and the supporting ContainerQuery
class.
CSSContainerRule is unusual in how it matches, because instead of it
either matching or not matching globally, it instead is matched against
a specific element. But also, some at-rules inside it always apply, as
if they were written outside it. This doesn't fit well with how
CSSConditionRule is implemented, and will likely require some rework
later. For now, `condition_matches()` always returns false, and
`for_each_effective_rule()` is overridden to always process those
global at-rules and nothing else.
