CSS Anchor Positioning Module Level 2

1. Delta specification

This is a delta specification, meaning that it currently contains only the differences from CSS Anchor Positioning Level 1 [CSS-ANCHOR-POSITION-1].

2. Container Queries for Anchor Positioning

This section extends container queries from [css-conditional-5] to allow querying certain aspects of elements using anchor positioning.

2.1. Extending container-type with anchored

This specification extends the container-type property defined in CSS Conditional 5 § 5.1 Creating Query Containers: the container-type property with a new anchored keyword. anchored can be combined with existing container types such as scroll-state and size:

normal | [ [ size | inline-size ] || scroll-state || anchored ]

anchored

Establishes a query container for container queries, allowing for descendants of an anchor positioned element to be styled based on certain features of the anchoring. (Currently, limited to which of the position-try-fallbacks are applied, if any.)

The anchored container-type applies style containment to the query container.

NOTE: Style containment is necessary to avoid a layout cycle for the following case using counters:

• We have an anchored container

• A counter is incremented by a descendant of the anchored container based on a fallback query.

• An in-flow element, following the anchored container in tree order, generates content, with the counter, affecting the size of the in-flow element.

• The in-flow element affects the position / size of the anchor element. In fact, the in-flow may be the anchor element itself.

• The changed position / size of the anchor element may change which fallback is chosen, which in turn affects the anchored query evaluation, hence the counter increment.

#anchored { container-type: anchored; }
#anchored-size { container-type: anchored inline-size; }

2.2. Extending @container syntax for anchored queries

To query an anchored container, a new anchored() function is added to the @container syntax. It extends the container query syntax by adding the following production to the '<query-in-parens>' grammar:

<query-in-parens> = ...
                  | anchored( <anchored-query> )

<anchored-query> = not <anchored-in-parens>
                | <anchored-in-parens> [ [ and <anchored-in-parens> ]* | [ or <anchored-in-parens> ]* ]
                | <anchored-feature>
<anchored-in-parens> = ( <anchored-query> )
                    | ( <anchored-feature> )
                    | <general-enclosed>

2.3. Anchored Container Features

2.3.1. Applied position-try-fallbacks: the fallback feature

The fallback container feature queries whether an anchor positioned element has any of its computed position-try-fallbacks options applied.

none

The anchored container does not have any position-try-fallbacks applied.

<dashed-ident> || <try-tactic>

The anchored container matches a combination of <dashed-ident> and <try-tactic> applied from position-try-fallbacks. If any of the <dashed-ident> or <try-tactic> are left out of the query value, they need to be left out in the applied value from position-try-fallbacks, and vice versa, in order to match.

The <dashed-ident> try rule name is not considered to be a tree-scoped name for the sake of matching fallback.

The order of <try-tactic>s is significant. For instance flip-start flip-block is not the same as flip-block flip-start. Hence, the order must match for fallback queries.

<position-area-query>

The anchored container has a <position-area> applied from position-try-fallbacks. The query matches if the applied <position-area> from the fallback and the query value represent the same physical area. That is, block-start will match top when the writing-mode is horizontal-tb.

A query value of any always matches for the given axis.

#container {
  container-type: anchored;
  position: absolute;
  position-anchor: --a;
  position-area: left;
  position-try-fallbacks: right;
  &::before { content: ">"; }

  @container anchored(fallback: right) {
    &::before { content: "<"; };
  }
}

.anchored {
  container-type: anchored;
  position-try-fallbacks: --foo, --bar flip-inline;

  @container anchored(fallback: --bar flip-inline) {
    /* Applies if the '--bar' fallback applies */
    .inner { background-color: green; }
  }
  @container anchored(fallback: --bar) {
    /* Does not apply because the try-tactic also must match */
    .inner { background-color: red; }
  }
}

.anchored {
  container-type: anchored;
  position-anchor: --a;
  position-try-fallbacks: right;
  writing-mode: vertical-rl;

  @container anchored(fallback: self-block-start) {
    /* Applies if the 'right' fallback applies since block-start is 'right'
        in 'vertical-rl'. */
    .inner { background-color: green; }
  }
}

.anchored {
  container-type: anchored;
  position-anchor: --a;
  position-try-fallbacks: bottom right;
  writing-mode: vertical-rl;

  @container anchored(fallback: bottom any) {
    /* Applies because 'any' matches 'right'. */
    .inner { color: lime; }
  }
  @container anchored(fallback: right) {
    /* Applies because implicit 'any' in the vertical axis matches 'bottom'. */
    .inner { background-color: green; }
  }
}

2.3.2. Syntax of <position-area-query> Values

Values for querying position-area fallbacks have the same syntax as <position-area>, with an additional any keyword added to every production:

<position-area-query> = [
  [ left | center | right | span-left | span-right
  | x-start | x-end | span-x-start | span-x-end
  | self-x-start | self-x-end | span-self-x-start | span-self-x-end
  | span-all | any ]
  ||
  [ top | center | bottom | span-top | span-bottom
  | y-start | y-end | span-y-start | span-y-end
  | self-y-start | self-y-end | span-self-y-start | span-self-y-end
  | span-all | any ]
|
  [ block-start | center | block-end | span-block-start | span-block-end | span-all | any ]
  ||
  [ inline-start | center | inline-end | span-inline-start | span-inline-end
  | span-all | any ]
|
  [ self-block-start | center | self-block-end | span-self-block-start
  | span-self-block-end | span-all | any ]
  ||
  [ self-inline-start | center | self-inline-end | span-self-inline-start
  | span-self-inline-end | span-all | any ]
|
  [ start | center | end | span-start | span-end | span-all | any ]{1,2}
|
  [ self-start | center | self-end | span-self-start | span-self-end | span-all | any ]{1,2}
]

any

any can be used for one or both of the axes. It is ambiguous about which axis it refers to, and is handled like other ambiguous keywords for '<position-area>' such as start or center when it comes to assigning axis and duplicating single keyword values.

start, end, self-start, self-end

top, bottom, left, right

y-start, y-end, self-y-start, self-y-end

x-start, x-end, self-x-start, self-x-end

block-start, block-end, self-block-start, self-block-end

inline-start, inline-end, self-inline-start, self-inline-end

center

span-start, span-end, span-self-start, span-self-end

span-top, span-bottom, span-left, span-right

span-y-start, span-y-end, span-self-y-start, span-self-y-end

span-x-start, span-x-end, span-self-x-start, span-self-x-end

span-block-start, span-block-end, span-self-block-start, span-self-block-end

span-inline-start, span-inline-end, span-self-inline-start, span-self-inline-end

span-all

See respective definitions for '<position-area>'.

If only a single keyword is given, '<position-area-query>' behaves as if the second keyword is any if the given keyword is unambigous about its axis. This is different from how single keywords are handled for '<position-area>', which behaves as if the second keyword is span-all. Otherwise, '<position-area-query>' behaves as '<position-area>' when it comes to assigning axes.

3. Security Considerations

No Security issues have been raised against this document.

4. Privacy Considerations

No Privacy issues have been raised against this document.