【この訳に特有な表記規約】
◎表記記号1. 序論
~CSSの`絶対~位置決め$は、 ~boxを~page上のどこにでも — ~boxの包含塊は別として，他の~boxの~layoutに関わることなく — 配置することを作者に許容する。 この柔軟性は、 ごく有用になり得るが，ごく制限されてもいる — ~boxを他の`何らか^emの~boxに相対的に位置するよう求まれることは多い。 `~anchor位置決め@ は、［ `position-anchor$p, `position-area$p ］~propや `~anchor関数@ — `anchor$f, `anchor-size$f の総称 — を介して，これを達成することを作者に許容する — それは、 ある`絶対的に位置され$た~boxを ~page上の他の 1 個以上の［ 当の~boxの `~anchor参照@ により参照rされる要素 `~anchor候補@ † ］を “~anchor先に” しながら，［ 他と重合する／~overflowする ］ことを避ける “最良な” ものを見出すよう［ いくつかのアリな位置を試行する ］ことを許容する。 ◎ CSS absolute positioning allows authors to place boxes anywhere on the page, without regard to the layout of other boxes besides their containing block. This flexibility can be very useful, but also very limiting—often you want to position relative to some other box. Anchor positioning (via the position-anchor and position-area properties and/or the anchor functions anchor() and anchor-size()) allows authors to achieve this, “anchoring” an absolutely positioned box to one or more other boxes on the page (its anchor references, while also allowing them to try several possible positions to find the “best” one that avoids overlap/overflow.
【 何が`~anchor参照$を成すのかは，原文には定義されていないが、 具体的には`~anchor指定子$が該当しよう。 】【† `~anchor候補$は、 この訳にて導入した用語 — 原文は、［ `~anchor参照$, それらが参照rするもの ］を一緒くたにして述べているので。 】【 `既定の~anchor要素$も`~anchor候補$に含まれるかどうかは、 はっきりしない （原文には、 どちらを示唆する記述もある）。 】
作者は、 ある~tooltip【 `.tooltip^css 】を ~targetにされた要素【 `.anchor^css 】の中央かつ上に — ただし、 そうすると~screen外に配置される事例では，下に — 位置するよう求めることもあろう。 これは、 次の~CSSで行える： ◎ For example, an author might want to position a tooltip centered and above the targeted element, unless that would place the tooltip offscreen, in which case it should be below the targeted element. This can be done with the following CSS:
.anchor {
/*
【`--tooltip^v と命名された`~anchor要素$。】
*/
anchor-name: --tooltip;
}
.tooltip {
/*
`固定d位置決め$は、
包含塊の関係性を気にする必要は無いことを意味する
— 当の~tooltipは、
~DOM内のどこに在ってもよい。
◎
Fixpos means we don’t need to worry about containing block relationships; the tooltip can live anywhere in the DOM.
*/
position: fixed;
/*
~anchor法の挙動は、
すべて，既定では `--tooltip^v と命名された~anchorを参照rするようにする。
◎
All the anchoring behavior will default to referring to the --tooltip anchor.
*/
position-anchor: --tooltip;
/*
~tooltipの下端を~anchorの上端に整列させる。
これはまた、
既定では，~tooltipと~anchorを横方向において中央に整列させる（横組みにおいては）。
◎
Align the tooltip’s bottom to the top of the anchor; this also defaults to horizontally center-aligning the tooltip and the anchor (in horizontal writing modes).
*/
position-area: block-start;
/*
~UIwindowを~overflowする場合、
~tooltipの上端が~anchorの下端に整列するよう，自動的に入替える。
◎
Automatically swap if this overflows the window so the tooltip’s top aligns to the anchor’s bottom instead.
*/
position-try: flip-block;
/*
広くなり過ぎるのを防止する。
◎
Prevent getting too wide
*/
max-inline-size: 20em;
`~popover~API＠~HTMLpopover#the-popover-attribute$を利用している場合、 `position$p は自動的に設定され，~anchor法の関係性は［ `anchor-name$p や `position-anchor$p ］の値が設定されなくても （`暗黙的な~anchor要素$を定義することにより） 自動的に作成されることに注意。 なので、 それらの~propを明示的に設定する必要はなくなる。 正しい~markupの下では、 上の例は，次に単純~化できる： ◎ Note that using the Popover API will automatically set position and create the anchoring relationship without setting anchor-name or position-anchor value (by defining an implicit anchor), so those properties wouldn’t need to be explicitly set again. So with the correct markup, this example can be simplified to:
.tooltip {
/*
［
`popover$a, `popovertarget$a
］属性を利用すれば、
すでに `position:fixed^p は設定され，
必要yな `position-anchor$p 関係性も作成される。
【`参照＠~HTMLrendering#flow-content-3$】
◎
Using the popover + popovertarget attributes sets 'position: fixed' and creates the necessary position-anchor relationship already.
*/
position-area: block-start;
position-try: flip-block;
max-inline-size: 20em;
}
1.1. 値~定義
【 この節を成す他の内容は `~CSS日本語訳 共通~page＠~CSScommon#values$に移譲。 】
この仕様における特能は、［ 選択子の照合-法は別として，~CSSにおける ほとんどの演算 ］と同様に，`平坦~tree$に対し演算する。 ◎ Like most operations in CSS besides selector matching, features in this specification operate over the flattened element tree.
2. ~anchorの決定-法
2.1. ~anchorの作成-法： `anchor-name^p ~prop
`anchor-name$p ~propは、 当の要素は `~anchor要素@ になり，その`首要~box$は`~anchor~box$になるものと宣言する。 当の要素は、 この~propに与えた~listを成す各 `~anchor名@ を通して~targetにされる。 各種 値は、 次に従って定義される： ◎ The anchor-name property declares that an element is an anchor element, whose principal box is an anchor box, and gives it a list of anchor names to be targeted by. Values are defined as follows:
- `~noneN@v
- この~propによる効果は無い。 ◎ The property has no effect.
- `dashed-ident$t#
- 当の要素は、 `首要~box$を生成するならば， `~anchor要素$になり、 所与の~listを成す`~anchor名$たちを伴う。 各`~anchor名$は、 `緩く照合される$tsN `~tree視野な名前$になる。 ◎ If the element generates a principal box, the element is an anchor element, with a list of anchor names as specified. Each anchor name is a loosely matched tree-scoped name.
- 他の場合、 この~propによる効果は無い。 ◎ Otherwise, the property has no effect.
`~anchor名$は、 一意になる必要はない。 すべての要素が［ 所与の~boxの`~target~anchor要素$になる能力を有する ］とは限らないので、 各利用に対する視野が適切に絞られていれば，同じ名前を複数の箇所で再利用できる。 ◎ Anchor names do not need to be unique. Not all elements are capable of being the target anchor element of a given box. Thus a name can be reused in multiple places if the usages are scoped appropriately.
注記： 複数個の要素が同じ`~anchor名$を共有していて， それらが所与の有位置な~boxから可視になる場合、 `~target~anchor要素$は，それらのうち`~tree順序$【！~DOM順序】で最後のものになる。 `anchor-scope$p ~propを利用すれば、 どの`~anchor名$が所与の［ それを参照している~box ］から可視になるかを更に制限できる。 ◎ Note: If multiple elements share an anchor name and are all visible to a given positioned box, the target anchor element will be the last one in DOM order. The anchor-scope property can be used to further limit what names are visible to a given referencing box.
`~anchor名$は、 既定では，`封込め$により視野が絞られる`ことはない^em。 要素が［ `~style封込め$／`~layout封込め$ ］（あるいは、 それらに類似な封込め） を伴う場合でも、 その子孫の`~anchor名$は，~page内の他所にある要素からは可視になる。 ◎ Anchor names are not scoped by containment by default; even if an element has style or layout containment (or any similar sort of containment), the anchor names of its descendants are visible to elements elsewhere in the page.
注記： 要素は、 別の要素の`飛ばされた内容$内に在る間は （一例として， `content-visibility$p に因り）， `受容-可能な~anchor要素$にはならない — その間は、 実質的に，~anchor名【！名前】が無かったかのように動作する。 ◎ Note: While an element is in the skipped contents of another element (due to content-visibility: hidden, for instance), it’s not an acceptable anchor element, effectively acting as if it had no names.
注記： `~shadow~tree$内の有位置な要素は， “`higher^en” な~tree【 “先祖~tree” 】内に定義された`~anchor名$を参照し得るが、 現時点では，“`lower^en” な~shadow~tree内に定義された`~anchor名$を参照し得ない。 ◎ Note: Positioned elements in shadow trees can reference anchor names defined in “higher” trees. Currently, they cannot reference anchor names defined in “lower” shadow trees, though.
2.1.1. 暗黙的な~anchor要素
一部の仕様は、 ある種の状況下で［ 特定0の要素が別の要素~用の `暗黙的な~anchor要素@ になる ］ものと定義し得る — 定義されない場合、 ~NULL になるとする†。 ◎ Some specifications can define that, in certain circumstances, a particular element is an implicit anchor element for another element.
【† ~NULL に関する記述は、 この訳による追加 — この用語を参照する `HTML$r の `§ ~popover＠~HTMLpopover$においては、 そのように述べられているので。 】
新たな［ `~popover＠~HTMLpopover$に関係する詳細 ］を伴う例で，ここを埋める （~HTML仕様において，それが最終的に着地したなら【`参照＠https://github.com/whatwg/html/pull/9144$】）。 ◎ TODO: Fill in an example new popover-related details (once that finally lands in the HTML spec).
`暗黙的な~anchor要素$は、 何らかの `anchor-name$p 値【`~anchor名$】ではなく， 次に挙げるいずれかにより参照され得る：
- `position-anchor$p において，~keyword `auto$vA を利用する
- `~anchor関数$において，~anchor参照【 `anchor-name$t 】を省略する
`疑似要素$の`暗黙的な~anchor要素$は、 他が指定されない限り，その`出自の要素$になるとする。 ◎ The implicit anchor element of a pseudo-element is its originating element, unless otherwise specified.
2.1.2. ~anchor~box
この仕様を成すいくつかの特能は、 `~anchor~box@ の位置と~sizeを参照rする。 これは、 他が指定されない限り， 当の`~anchor要素$の`首要~box$を成す`~border~box$辺を参照rする。 `~anchor~box$の［ 位置, ~size ］は、 ~layoutより後に決定される。 ◎ Several features of this specification refer to the position and size of an anchor box. Unless otherwise specified, this refers to the border box edge of the principal box of the anchor element. The anchor box’s position and size is determined after layout.
以下における “当の有位置な~box” は、 当の`~anchor~box$を参照rしている`絶対的に位置され$た要素の`首要~box$を指すとする。 ◎ ↓
この［ 位置, ~size ］は、［ `zoom$p, `position$p に基づく調整（ `position:relative^p や `position:sticky^p など）, 変形（ `transform$p や `offset-path$p など） ］を含む。 これらの事例では、 代わりに 当の`~anchor~box$の［ 当の有位置な~boxの`包含塊$の座標~空間と軸が揃えられた限界~矩形 ］が利用される。 変形は，異なる~threadで遂行するよう最適化されることが多いので、 `~anchor~box$の位置に対する変形に基づく更新は 何~frameか遅延され得る。 作者は、［ 実用的になる所では，代わりに［ 絶対~位置決め／相対~位置決め ］を利用する ］ことにより，この遅延を避けれる。 ◎ This position and size includes zoom and position-based adjustments (such as position: relative or position: sticky) as well as transforms (such as transform or offset-path). In these cases, the axis-aligned bounding rectangle of the anchor box in the coordinate space of the absolutely positioned element’s containing block is used instead. Transforms are often optimized onto a different thread, so transform-based updates to an anchor box’s position may be delayed by a few frames. Authors can avoid this delay by using absolute or relative positioning instead where practical.
`~anchor~box$が ある`断片化~文脈$ %文脈 の下で`断片化-$されていて， 当の有位置な~boxの`包含塊$は %文脈 の外側にある場合、 代わりに，当の`~box断片$の［ 【当の包含塊の座標~空間と】軸が揃えられた限界~矩形 ］が利用される。 （ %文脈 の内側にある場合、 当の`~anchor~box$は，当の有位置な~boxからは まだ断片化されてないものとして見える — それ自体は、 【後で】 %文脈 により断片化され得る。） ◎ If the anchor box is fragmented, and the containing block of the absolutely positioned box referring to that anchor box is outside the relevant fragmentation context, the axis-aligned bounding rectangle of its box fragments is used instead. (If the absolutely positioned box is inside the fragmentation context, it sees the anchor box as unfragmented—and can be itself fragmented by the fragmentation context.)
処理能の理由から，~scrollingは特別に取扱われる （ `§ ~scrollの織り込み法＠#scroll$ を見よ）。 他の~layout後の効果 — ~filterなど — は、 `~anchor~box$の位置には影響しない。 ◎ For performance reasons, scrolling is handled specially, see § 3.3 Taking Scroll Into Account. Other post-layout effects, such as filters, do not affect the anchor box’s position.
2.2. ~anchor名の視野-法： `anchor-scope^p ~prop
この~propは、 指定された`~anchor名$たちの視野を絞る — 【 `none^v 以外が指定された場合には、】その検索を当の要素の下位treeに限るよう。 `§ ~anchorの決定-法＠#determining$ を見よ。 ◎ This property scopes the specified anchor names, and lookups for these anchor names, to this element’s subtree. See § 2 Determining the Anchor.
各種 値の意味は： ◎ Values have the following meanings:
- `none@v
- `~anchor名$の視野における変更は無い。 ◎ No changes in anchor name scope.
- `all@v
-
［ 当の要素, その各~子孫 ］により定義される どの`~anchor名$ %~anchor名 に対しても：
-
%~anchor名 を視野に入れるものは†、 当の要素の子孫に限るものと指定する — %~anchor名 の視野が［ すでに，ある子孫により `anchor-scope$p を利用して制限されていない ］ならば。
【† すなわち、 %~anchor名 を通して［ 当の要素／その子孫 ］を~targetにするもの。 】【 言い換えれば、 所与の %要素 に対し， `~target~anchor要素$( %要素, %~anchor名 ) の結果が［ 当の要素／その子孫 ］になるならば、 %要素 は当の要素の子孫になる。 】
-
当の要素の子孫が %~anchor名 を照合する対象†は、 当の要素の下位treeの中††にある`~anchor要素$に限るよう制限する。
【† すなわち、 子孫が %~anchor名 を通して~targetにするもの。 】【†† 当の要素も含まれる。 】【 言い換えれば、 `~target~anchor要素$( 子孫, %~anchor名 ) の結果は，［ 当の要素／その子孫 ］になる。 】
-
- この値は、 同じ~tree視野に入る`~anchor名$にしか影響しない — それが`厳密に照合される$tsN `~tree視野な名前$であったかのように （すなわち、 `anchor-scope: all$p は，関連な`~anchor名$すべてを~listしている `anchor-scope: --foo, --bar, ...^p と同じに動作する。） ◎ This value only affects anchor names in the same tree scope, as if it were a strictly matched tree-scoped name. (That is, anchor-scope: all acts identically to anchor-scope: --foo, --bar, ..., listing all relevant anchor names.)
- `dashed-ident$t#
- 対象になる`~anchor名$が［ 所与の `dashed-ident$t いずれかに合致するもの ］に限られることを除いて， `all$v と同じにふるまう。 ◎ Specifies that a matching anchor name defined by this element or its descendants—whose scope is not already limited by a descendant using anchor-scope—to be in scope only for this element’s descendants; and limits descendants to only match these anchor names to anchor elements within this subtree.
- 各 `dashed-ident$t は、 `厳密に照合される$tsN `~tree視野な名前$を表現する。 すなわち，同じ~shadow~tree内の~anchor名にしか合致しない。 `CSS-SCOPING-1$r ◎ The <dashed-ident> represents a strictly matched tree-scoped name, i.e. it can only match against anchor names in the same shadow tree.[CSS-SCOPING-1]
この~propには、 `暗黙的な~anchor要素$に対する効果は無い。 ◎ This property has no effect on implicit anchor elements.
ある設計~patternが再利用され， 互いに一致する複数の~componentがあるとき、 `anchor-scope$p は，それらに またがる命名の衝突を防止できる。 例えば、 ある~listが各~list~itemの中に有位置な要素を包含していて， それらの要素は［ 各自が属する~list~itemに相対的に位置する ］よう求まれるとする： ◎ When a design pattern is re-used, anchor-scope can prevent naming clashes across identical components. For example, if a list contains positioned elements within each list item, which want to position themselves relative to the list item they’re in,
li {
anchor-name: --list-item;
anchor-scope: --list-item;
}
li .positioned {
position: absolute;
position-anchor: --list-item;
position-area: inline-start;
}
`anchor-scope$p を伴わない下では、 どの `li$e 要素も， 【それに指定された`~anchor名$は】これら有位置な要素~すべてから可視になる — その結果、 すべてが`最後の^em `li$e に相対的に位置され，そこへ積層される。 ◎ Without anchor-scope, all of the li elements would be visible to all of the positioned elements, and so they’d all positioned themselves relative to the final li, stacking up on top of each other.
2.3. ~anchorの見出法
この仕様~内のいくつかのものは、 所与の`~anchor指定子$から`~target~anchor要素$を見出す。 `~anchor指定子@ は、［ ε （指定子は欠落である）／ `auto$vA ／ `dashed-ident$t ］である。 `dashed-ident$t は、 ~page上の他所における `anchor-name$p 値に合致するべき名前であり， `~tree視野な参照$である。 ◎ Several things in this specification find a target anchor element, given an anchor specifier, which is either a <dashed-ident> (and a tree-scoped reference) that should match an anchor-name value elsewhere on the page, or the keyword auto, or nothing (a missing specifier).
注記： これらの【~target~anchor要素を見出すための】条件は、［ ある要素が，それを~anchorとして参照するよう求める有位置な~boxの`~target~anchor要素$になり得る ］のは［ 当の有位置な~boxが~lay-outされる前に， 当の要素の自前の~boxが全部的に~lay-outされる場合に限られる ］とする一般~規則を捕捉する。 ~CSSの~layout規則は、 このことについて，いくつか有用な保証を — 当の［ ~anchor, 有位置な~box ］の［ 互いの関係性, 包含塊 ］に依存して — 供する。 以下に挙げる条件は、［ ~anchor位置決めが循環依存になるアリ性 ］は無いことを確保するよう，［ 積層~文脈~用の規則のうち，この目的に関連なもの ］だけを正確に言い直す。 ◎ Note: The general rule captured by these conditions is that an element can only be a positioned box’s target anchor element if its own box is fully laid out before the positioned box that wants to reference it is laid out. CSS’s layout rules provide some useful guarantees about this, depending on the anchor and positioned box’s relationship with each other and their containing blocks. The list of conditions below exactly rephrases the stacking context rules into just what’s relevant for this purpose, ensuring there is no possibility of circularity in anchor positioning.
`~target~anchor要素@ 【略して “~anchor先（ `anchored^en ）” とも称される】 を決定する ~algoは、 所与の ( 【`絶対的に位置され$た】~queryしている要素 %~query要素, `~anchor指定子$ %指定子 ~DF ε ) に対し，［ ある`~anchor要素$ ／ ε（ “無し” ） ］を返す： ◎ To determine the target anchor element given a querying element query el and an optional anchor specifier anchor spec:
- ~IF［ %指定子 ~EQ ε ］ ⇒ ~RET ［ %~query要素 用の`既定の~anchor要素$は存在するならば それ／ ~ELSE_ ε ］ ◎ If anchor spec was not passed, return the default anchor element if it exists, otherwise return nothing.
-
~IF［ %指定子 ~EQ `auto$vA ］： ◎ If anchor spec is auto:
- ~IF［ %~query要素 は`暗黙的な~anchor要素$ %~anchor ~NEQ ~NULL ］~AND［ %~anchor は【 %~query要素 用に】`受容-可能な~anchor要素$である ］ ⇒ ~RET %~anchor ◎ If query el has an implicit anchor element that is an acceptable anchor element, return that element.
- ~RET ε ◎ Otherwise, return nothing.
注記： 将来の~APIは、 暗黙的な~anchor要素を定義するかもしれない。 そうなったときは、 他との協調を確保するよう， この~algo内で明示的に取扱われることになる。 ◎ Note: Future APIs might also define implicit anchor elements. When they do, they’ll be explicitly handled in this algorithm, to ensure coordination.
- ~Assert： %指定子 は `dashed-ident$t である。 ◎ Otherwise, anchor spec is a <dashed-ident>.＼
-
%~anchor群 ~LET 次を満たす`~anchor要素$ %~anchor たちが成す集合 ⇒ ［ %指定子 ~IN %~anchor の`~anchor名$たちが成す集合 ］~AND［ %~anchor の`~anchor名$たちに結付けられた`~tree$【！の`根$】 ~EQ %指定子 に結付けられた`~tree$【！の`根$】 ］
注記： `~anchor名$は`~tree視野な名前$である一方、 %指定子 は`~tree視野な参照$である。
◎ Return the last element el in tree order that satisfies the following conditions: • el is an anchor element with an anchor name of anchor spec. • el’s anchor name and anchor spec are both associated with the same tree root. • Note: The anchor name is a tree-scoped name, while anchor spec is a tree-scoped reference. • el is an acceptable anchor element for query el. - %~anchor群 を成す ~EACH( %~anchor ) に対し，`~tree順序$の逆順で ⇒ ~IF［ %~anchor は %~query要素 用の`受容-可能な~anchor要素$である ］ ⇒ ~RET %~anchor ◎ ↑
-
~RET ε ◎ If no element satisfies these conditions, return nothing.
注記： `anchor-scope$p は、 ある種の`~anchor名$の可視性を制約し得る — それは、 所与の検索において，どの要素が`~anchor要素$になり得るかに影響し得る。 ◎ Note: anchor-scope can restrict the visibility of certain anchor names, which can affect what elements can be anchor elements for a given lookup.
【 この注記は、 この手続きの中では， “〜に結付けられた`~tree$” として反映されているものと見受けられる。 】
注記： ある`~shadow~tree$内の~style内の `anchor-name$p により定義された`~anchor名$は、 異なる`~shadow~tree$内の~style内の`~anchor関数$からは見えない （~capsule化を保全するため）。 しかしながら，異なる`~shadow~tree$内にある`要素どうし^emであっても、［ `~anchor名$, `~anchor関数$ ］どちらも — ある~shadowの内側にある要素を `part()$pe を利用して~styleするなどにより — 同じ~tree内の~styleから来ているならば，互いに他を~anchorできる。 （`暗黙的な~anchor要素$は，内在的には単独の~treeに制限されないが、 その詳細は，それをアテガっている~APIに依存することになる。） ◎ Note: An anchor-name defined by styles in one shadow tree won’t be seen by anchor functions in styles in a different shadow tree, preserving encapsulation. However, elements in different shadow trees can still anchor to each other, so long as both the anchor-name and anchor function come from styles in the same tree, such as by using ::part() to style an element inside a shadow. (Implicit anchor elements also aren’t intrinsically limited to a single tree, but the details of that will depend on the API assigning them.)
ある要素 %~anchor候補 は ある`絶対的に位置され$た要素 %有位置な要素 用の `受容-可能な~anchor要素@ であるとは、 ~AND↓ が満たされることをいう： ◎ An element possible anchor is an acceptable anchor element for an absolutely positioned element positioned el if all of the following are true:
- %~anchor候補 は［ `要素$／`全部的に~style可能な疑似要素$【！不要：`~treeに留まる疑似要素$】 ］である ◎ possible anchor is either an element or a fully styleable tree-abiding pseudo-element.
- %~anchor候補 は、 %~anchor候補 の ある`広義-先祖$の `anchor-scope$p の効果により， %有位置な要素 の視野に入る ◎ possible anchor is in scope for positioned el, per the effects of anchor-scope on possible anchor or its ancestors.
-
~OR↓ （すなわち、 %~anchor候補 は，厳密に【？】 %有位置な要素 よりも前に~lay-outされる）： ◎ possible anchor is laid out strictly before positioned el, aka one of the following is true:
-
~AND↓： ◎ ↓
- %~anchor候補 の`元の包含塊$ ~EQ %有位置な要素 の`元の包含塊$ ◎ possible anchor and positioned el have the same original containing block and＼
-
~OR↓： ◎ either
- %有位置な要素 は %~anchor候補 `より高い上端~層~内$に在る ◎ possible anchor is in a lower top layer than positioned el, or
-
~AND↓：
- ( %有位置な要素, %~anchor候補 ) は、 `同じ上端~層~内$【！同じ`上端~層$内】に在る
-
~OR↓：
- %~anchor候補 は`絶対的に位置され$ていない
- %有位置な要素 は`平坦~tree$順序において %~anchor候補 に後続する
-
~AND↓ を満たす要素 %要素 が在る
- %要素 は %~anchor候補 の`包含塊$を生成している
- %要素 は %有位置な要素 用の`受容-可能な~anchor要素$である
-
-
%~anchor候補 が ある要素の`飛ばされた内容$内に在るならば、 %有位置な要素 も同じ内容~内に在る ◎ If possible anchor is in the skipped contents of another element, then positioned el is in the skipped contents of that same element.
注記： このことは、 次を意味する： ◎ Note: In other words, positioned el can anchor to possible anchor if they’re both in the same skipped "leaf", but it can’t anchor "across" leafs. This means＼
- ［ 有位置な要素, その~anchor先 ］両方を包含する要素【の内容？】が飛ばされても， 有位置な要素が急に別の~anchorへ移動することはない。 ◎ skipping an element that contains both of them won’t suddenly cause the positioned el to move to another anchor,＼
- 同じ~page内の`他所^em【飛ばされない内容~内】に在る有位置な要素の~anchor先が飛ばされた【内容~内に在る？】要素になることを防止する。 ◎ but still prevents positioned elements elsewhere in the page from anchoring to the skipped element.
2.4. 既定の~anchor： `position-anchor^p ~prop
`position-anchor$p ~propは、 【当の［要素／~box］用の】 `既定の~anchor要素@ を指定する — それは、 当の~box【！this element】に適用される［ `position-area$p ~prop, `position-try$p ~prop, （既定では）すべての`~anchor関数$ ］により利用される。 ◎ The position-anchor property specifies the default anchor element, which is used by position-area, position-try, and (by default) all anchor functions applied to this element.＼
`position-anchor$p ~propは、 `position$p ~propの`設定し直すのみ$な下位propである。 ◎ position-anchor is a reset-only sub-property of position.
- `auto@vA
- 当の要素~用の`暗黙的な~anchor要素$は存在するならば、 それを利用する — 他の場合、 当の~box用の`既定の~anchor要素$は無い。 ◎ Use the implicit anchor element if it exists; otherwise the box has no default anchor element.
- `anchor-name$t
- 当の~box用の`既定の~anchor要素$は、 指定された `anchor-name$t により選定される`~target~anchor要素$になる。 ◎ The target anchor element selected by the specified <anchor-name> is the box’s default anchor element.
所与の`絶対的に位置され$た~boxの `既定の~anchor~box@ は、 当の~box用の`既定の~anchor要素$は在るならば，その`首要~box$を指す — 無い場合は ε とする。 ◎ The principal box of the default anchor element is the box’s default anchor box.
例えば，次の~codeにおける［ `.foo^css, `.bar^css ］要素は、 各自が参照rしている~anchor要素だけを変更しながら， どちらにも同じ位置決め~propたちを利用できる： ◎ For example, in the following code both .foo and .bar elements can use the same positioning properties, just changing the anchor element they’re referring to:
.anchored {
position: absolute;
top: calc(.5em + anchor(outside));
/*
この `anchor^f は、
`~anchor名$【`~anchor指定子$】を指定していないので，
自動的に`既定の~anchor~box$を参照rする。
◎
Since no anchor name was specified, this automatically refers to the default anchor box.
*/
}
.foo.anchored {
position-anchor: --foo;
}
.bar.anchored {
position-anchor: --bar;
}
2.5. ~anchorの関連性
所与の要素 %要素 は、［ ~AND↓ を満たす［ %~box, %~anchor ］が在る ］ならば，`利用者に関連する$ものと見なすモノトスル：
- %~box は`絶対的に位置され$た~boxである
- %~anchor は %要素 の子孫である
- %~anchor は %~box 用の`~target~anchor要素$である
- %~box の`内容は飛ばされ$ていない
- %~box の包含塊を確立しているものは［ %要素 ／ %要素 のある子孫 ］でない
注記： このことは、 例えば， %要素 が `content-visibility:auto$p を伴う場合でも、 %~anchor に依拠している %~box の`内容は飛ばされ$ていない間は， %要素 の`内容は飛ばされ$なくなることを意味する （ %~box も %要素 の下位tree内にある場合を除いて — %~anchor, %~box が互いに他方を可視に保つような循環依存は生じ得ない）。 ◎ Note: This means that, for example, an anchor in a content-visibility: auto subtree will prevent its subtree from skipping its contents as long as the positioned box relying on it is also not skipped. (Unless the anchor and the positioned box are both under the same content-visibility: auto element; they can’t cyclicly keep each other visible.)
3. ~anchorに基づく位置決め
`絶対的に位置され$た~boxは、 自身を~pageの 1 個以上の`~anchor~box$に相対的に位置できる。 ◎ An absolutely positioned box can position itself relative to one or more anchor boxes on the page.
`position-area$p ~propは、 `既定の~anchor~box$に相対的な位置決め用に，簡便な格子に基づく概念を提供する。 対して，［ より複階的な位置決め／ 複数個の~boxに相対的な位置決め ］用には、 `~inset~prop$において［ `~anchor~box$の辺を明示的に参照rする `anchor$f 関数 ］を利用できる。 ◎ The position-area property offers a convenient grid-based concept for positioning relative to the default anchor box; for more complex positioning or positioning relative to multiple boxes, the anchor() function can be used in the inset properties to explicitly refer to edges of an anchor box.
3.1. `position-area^p ~prop
`~anchor位置決め$に共通的な利用事例では、 所与の有位置な~box %~box に対し，［ %~box の`包含塊$の各~辺, %~box の`既定の~anchor~box$の各~辺 ］以外は懸念する必要がない場合がほとんどである。 これらの線（辺）は、 縦横とも 3 分された格子 — `位置~区画~用の格子$ — を定義しているものと捉えれる。 `position-area$p は、 `位置~区画$ — %~box を，この格子を成す どの区画~内に~lay-outするか — を容易に指定できるようにする。 ◎ Most common use-cases of anchor positioning are only concerned with the edges of the positioned box’s containing block and the edges of the default anchor box. These lines can be thought of as defining a 3×3 grid; position-area lets you easily specify what area of this position-area grid to lay out the positioned box in.
- `none@vI
- この~propによる効果は無い。 ◎ The property has no effect.
- `position-area$t
-
当の~boxが ~OR↓ を満たす場合、 この値による効果は無い：
- その`既定の~anchor~box$ ~EQ ε
- `絶対的に位置され$ていない
-
他の場合の効果は、 `位置~区画$を指定する — それが、 当の~boxの`包含塊$になる。 ◎ Otherwise, selects a region of the position-area grid, and makes that the box’s containing block.
注記： このことは、 次を意味する：
- `~inset~prop$は、 `位置~区画$からの~offsetを指定する。
- 一部の~prop用の一部の値 — `max-height: 100%$p など — は、 `位置~区画$に相対的になる
`none$vI 以外の値には、 次に挙げる追加的な効果がある： ◎ Values other than none have the following additional effects:
- 適用-可能な所では†、 `局所的な包含塊$に代えて，`~scroll可能な包含塊$が利用される — （概して）`~scroll可能な~overflow区画$全体が位置決め用に可用になるよう。 【† すなわち，包含塊が`~scroll容器$により確立される場合。】 ◎ The scrollable containing block is used in place of the local containing block where applicable, so that the entire scrollable overflow area (typically) is available for positioning.
- `~inset~prop$用の値 `auto$v は `0^v に解決される。 ◎ Any auto inset properties resolve to 0.
- `自己-整列~prop$用の値 `normal$vS は、 当の値に対応する値に解決される — `§ 位置~区画に特有な既定の整列＠#position-area-alignment$ を見よ。 ◎ The normal value for the self-alignment properties resolves to a corresponding value, see § 4.1 Area-specific Default Alignment.
3.1.1. 位置~区画~用の格子の解決-法
所与の~box %~box の `位置~区画~用の格子@ は、 縦横とも 3 分された格子である — それは、 軸ごとに，次に挙げる 4 本の線から （および，`包含塊$の`書字~mode$を利用して） 構成される： ◎ The position-area grid is a 3×3 grid, composed of four grid lines in each axis. In order (using the writing mode of the containing block):
-
次のうち，より`始端$寄りにある方：
- %~box の［ 改変される前の`包含塊$ ］の始端~辺
- %~box の`既定の~anchor~box$の始端~辺
- %~box の`既定の~anchor~box$の始端~辺 ◎ the start edge of the default anchor box
- %~box の`既定の~anchor~box$の終端~辺 ◎ the end edge of the default anchor box
-
次のうち，より`終端$寄りにある方：
- %~box の［ 改変される前の`包含塊$ ］の終端~辺
- %~box の`既定の~anchor~box$の終端~辺
注記： `既定の~anchor~box$が当の~boxの［ 改変される前の`包含塊$ ］を はみ出るときは、 `位置~区画~用の格子$を成す一部の［ ~row／~col ］の~size【 “太さ” 】は， 0 になることもある。 ◎ Note: When the default anchor box is partially or completely outside of the pre-modified containing block, some of the position-area grid’s rows or columns can be zero-sized.
3.1.2. `position-area^t 値の構文
`position-area$t 値は、 `位置~区画$を 2 個の値が成す~pair†として指定する — それらの値は、［ `~flow相対$／`物理的$ ］な用語で表出される。 ◎ Positions are specified as a pair of values, which can be expressed in flow-relative or physical terms.＼
【† 以下に述べられるとおり、 各~値は，異なる軸に対応し、 値が 1 個だけ指定された場合でも，もう 1 個の値が導出される。 】
`position-area$t の構文は： ◎ The allowed syntax of a <position-area> value is:
`position-area@t
= [Ⓐ] || [Ⓑ]
| [Ⓒ] || [Ⓓ]
| [Ⓔ] || [Ⓕ]
| [Ⓖ]{1,2}
| [Ⓗ]{1,2}
Ⓐ
= 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
Ⓑ
= 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
Ⓒ
= block-start
| center
| block-end
| span-block-start
| span-block-end
| span-all
Ⓓ
= inline-start
| center
| inline-end
| span-inline-start
| span-inline-end
| span-all
Ⓔ
= self-block-start
| center
| self-block-end
| span-self-block-start
| span-self-block-end
| span-all
Ⓕ
= self-inline-start
| center
| self-inline-end
| span-self-inline-start
| span-self-inline-end
| span-all
Ⓖ
= start
| center
| end
| span-start
| span-end
| span-all
Ⓗ
= self-start
| center
| self-end
| span-self-start
| span-self-end
| span-all
【 ⒶⒷⒸⒹⒺⒻⒼⒽは、 簡明にするための，この訳による追加。 】
`position-area$t 値は、 `位置~区画@ — `位置~区画~用の格子$を成す ある領域 — を［ それが占める［ ~rowたち, ~colたち ］を次に従って指定する ］ことにより選定する： ◎ The <position-area> value selects a region of the position-area grid by specifying the rows and columns the region occupies as follows:
【 区画は，それらの交差域になる。 】【 以下に現れる語 “筋（ `track^en ）” とは、［ ~row, ~col ］どちらかを指す総称である。 】
- `start@vI
- `end@vI
- `self-start@vI
- `self-end@vI
- `top@vI
- `bottom@vI
- `left@vI
- `right@vI
- `y-start@vI
- `y-end@vI
- `self-y-start@vI【！self-x-start】
- `self-y-end@vI
- `x-start@vI
- `x-end@vI
- `self-x-start@vI
- `self-x-end@vI
- `block-start@vI
- `block-end@vI
- `self-block-start@vI
- `self-block-end@vI
- `inline-start@vI
- `inline-end@vI
- `self-block-start@vI
- `self-inline-end@vI
- `center@vI
-
1 本の筋を占める：
-
どの軸を参照rするか — ［ ~row, ~col ］どちらに対応するか — は：
- 当の~keywordが ある軸を指定する場合、 それになる （例： `block-start$vI は、 `塊-軸$を参照rする）。
- 他の場合、 下に述べる。
- 3 本ある筋のうち どれを占めるかは、 当の~keywordにより指示される （例： ~keywordが `start^v を含むなら “始端”, 等々）。
-
どの側が［ “始端” ／ “終端” ］とされるかは、 次に基づく：
- `self-^v を含む~keyword用には、 当の~boxの【！own】`書字~mode$
- 他~keyword用には、 当の~boxの`包含塊$の`書字~mode$
-
- `span-start@vI
- `span-end@vI
- `span-self-start@vI
- `span-self-end@vI
- `span-top@vI
- `span-bottom@vI
- `span-left@vI
- `span-right@vI
- `span-y-start@vI
- `span-y-end@vI
- `span-self-y-start@vI
- `span-self-y-end@vI
- `span-x-start@vI
- `span-x-end@vI
- `span-self-x-start@vI
- `span-self-x-end@vI
- `span-block-start@vI
- `span-block-end@vI
- `span-self-block-start@vI
- `span-self-block-end@vI
- `span-inline-start@vI
- `span-inline-end@vI
- `span-self-inline-start@vI
- `span-self-inline-end@vI
- 中央にある筋も占めることを除いて，［ 当の~keywordから `span-^v を除去した~keyword ］と同じになる （例： `span-top$vI は、 { “中央”, “上端” } を占める）。 ◎ Two adjacent rows or columns, depending on which axis this keyword is specifying: the center row/column, and the row/column corresponding to the other half of the keyword as per the single-track keywords. ◎ (For example, span-top spans the first two rows—the center row and the top row.)
- `span-all@vI
- 3 本~すべての筋を占める。 ◎ All three rows or columns,＼ ↓↓ depending on which axis this keyword is specifying.
~keywordには、 どの軸を参照rするか多義的なものがある （ `center$vI, `span-all$vI, `start$vI, 等々） — それらが参照rする軸は：
- 他方の~keywordが ある軸を指定する場合 ⇒ もう一方の軸になる （例： `block-start center^v を成す~keyword `center^v は、 `行内-軸$を参照rする）。
- 他の場合 ⇒ 順に，当の~boxの`包含塊$の［ `塊-軸$, `行内-軸$ ］を参照rする （例：`span-all start^v は `span-all inline-start^v と等価になる）。
~keywordが 1 個だけ与えられた場合：
- 所与の~keywordが ある軸を指定する場合 ⇒ 2 個目の~keywordは `span-all$vI であったかのように挙動する （例： `top$vI は `top span-all^v と等価になる）。
- 他の場合 ⇒ 所与の~keywordが繰返されたかのように挙動する （例： `center$vI は `center center^v と等価になる）。
3.1.3. `position-area$t の算出d値と直列化
`position-area$t 値の`算出d値$は、 各~軸において選定された筋たちを指示する 2 個の~keywordからなる — 長い論理-~keywordと短い論理-~keyword （例： `block-start$vI と `start$vI ） は、 【同じ軸を参照rするならば，】等価なものとして扱われる。 算出d値は，前節の文法~内に与えられた順序で直列化され、 各~論理-~keywordは，短い形で直列化される （例： `block-start inline-start^v の代わりに `start start^v ）。 ◎ The computed value of a <position-area> value is the two keywords indicating the selected tracks in each axis, with the long (block-start) and short (start) logical keywords treated as equivalent. It serializes in the order given in the grammar (above), with the logical keywords serialized in their short forms (e.g. start start instead of block-start inline-start).
【 あるいは、 `center block-start^v の代わりに `start center^v の様に，順序も変わり得る。 】
3.2. ~anchorに相対的な~inset： `anchor^f 関数
`絶対的に位置され$た~boxは、 自身の`~inset~prop$の値として `anchor@f 関数を利用することにより，［ 1 個以上の`~anchor~box$ ］の位置を参照rできる。 `anchor$f 関数は、 `length$t に解決される。 この関数は、 `~inset~prop$内に限り，許容される （他においては無効になる）。 ◎ An absolutely positioned box can use the anchor() function as a value in its inset properties to refer to the position of one or more anchor boxes. The anchor() function resolves to a <length>. It is only allowed in the inset properties (and is otherwise invalid).
`anchor()^t = anchor( `anchor-name$t? && `anchor-side$t, `length-percentage$t? ) `anchor-name@t = `dashed-ident$t `anchor-side@t = `inside$vA | `outside$vA | `top$vA | `left$vA | `right$vA | `bottom$vA | `start$vA | `end$vA | `self-start$vA | `self-end$vA | `percentage$t | `center$vA
`anchor$f 関数は、 3 個の引数をとる — 以下における %~box は、 この関数を利用している`絶対的に位置され$た~boxを指すとする： ◎ The anchor() function has three arguments:
-
`anchor-name$t は、 `~anchor要素$を見出す方法を指定する 【すなわち、`~anchor指定子$を与える】。 %~box の位置決め情報は、 それにより見出された`~anchor要素$ 【すなわち，`~target~anchor要素$】 から引き出されることになる： ◎ the <anchor-name> value specifies how to find the anchor element it will be drawing positioning information from. Its possible values are:
- `dashed-ident$t が指定された場合 ⇒ `~anchor要素$のうち［ 所与の識別子を`~anchor名$に伴うもの ］を探す。 この名前は、 `~tree視野な参照$になる。 ◎ <dashed-ident> • Specifies the anchor name it will look for. This name is a tree-scoped reference.
- 省略された場合 ⇒ アリなら， %~box 用に定義された`既定の~anchor要素$を選定する。 ◎ omitted • Selects the default anchor element defined for the box, if possible.
詳細は、 `~target~anchor要素$を見よ。 ◎ See target anchor element for details.
-
`anchor-side$t は、 `~target~anchor要素$の［ その値に対応している側 ］を位置として参照rする。 以下における %~prop は、 この関数を利用している`~inset~prop$を指すとする。 アリな値は： ◎ the <anchor-side> value refers to the position of the corresponding side of the target anchor element. Its possible values are:
- `inside@vA
- `outside@vA
- `inside$vA は、 `~anchor~box$の各~側のうち， %~prop と同じ側を参照rする （ %~box を当の`~anchor~box$の “内側” に付する） よう解決される。 `outside$vA は、 その反対-側†を参照rするよう解決される。 ◎ Resolves to one of the anchor box’s sides, depending on which inset property it’s used in. inside refers to the same side as the inset property (attaching the positioned box to the "inside" of the anchor box), while outside refers to the opposite.
- 【† ~keywordの意味から、 “内側” の反対を表す “外側” を意味すると思われる — %~prop が指示する側と反対（例： %~prop が `top^p なら下端）を意味するかもしれないが。 】
- `top@vA
- `right@vA
- `bottom@vA
- `left@vA
- `~anchor~box$の［ 所与の~keywordにより指定された側 ］を参照rする。 ◎ Refers to the specified side of the anchor box.
- 注記： これらの~keywordが利用-可能になるのは、［ ~keywordが参照rする軸, %~prop が対象にする軸 ］が合致している場合に限られる。 例えば， `left$vA を利用-可能な~propは、 横~軸を対象にする`~inset~prop$ — `left$p, `right$p, これらと同じ側に対応する~flow相対な~prop — に限られる。 ◎ Note: These are only usable in the inset properties in the matching axis. For example, left is usable in left, right, or the logical inset properties that refer to the horizontal axis.
- 【 これらは、 “物理-~keyword” とも総称される。 】
- `start@vA
- `end@vA
- `self-start@vA
- `self-end@vA
- `~anchor~box$の各~側のうち， %~prop が対象にする軸に属するいずれかを参照rする 【例： %~prop が `top$p ならば上端か下端】 — 所与の~keywordに応じて， ⇒＃ ［ `self-start$vA ／ `self-end$vA ］ならば， %~box ／ ［ `start$vA ／ `end$vA ］ならば， %~box の`包含塊$ ◎終 の`書字~mode$を基準に解決することにより。 ◎ Refers to one of the sides of the anchor box in the same axis as the inset property it’s used in, by resolving the keyword against the writing mode of either the positioned box (for self-start and self-end) or the positioned box’s containing block (for start and end).
- 【 これらは、 “論理-~keyword” とも総称される。 】
- `percentage$t
- `center@vA
- ［ `start$vA 側, `end$vA 側 ］の合間における所与の百分率に対応する位置を参照rする — ［ `0%^v ／ `100%^v ］は［ `start^v ／ `end^v ］と等価になる。 ◎ Refers to a position a corresponding percentage between the start and end sides, with 0% being equivalent to start and 100% being equivalent to end.
- `center$vA は、 `50%^v と等価になる。 ◎ center is equivalent to 50%.
- 省略可能な 3 個目の引数 `length-percentage$t は、 ~fallback値を与える。 これは、 当の `anchor$f が`解決-可能な~anchor関数$でない場合に， 何に算出するべきかを指定する。 ◎ the optional <length-percentage> final argument is a fallback value, specifying what the function should compute to if it’s an unresolvable anchor function.
`anchor$f 関数は、 `解決-可能な~anchor関数$を表現しているならば， （`~styleと~layoutの差挟み$を介して） `算出d値$の時点で `length$t に解決される — ［ 当の有位置な~boxの`~insetで改変された包含塊$ ］の［ 当の関数が現れる~propに対応している辺 ］を［ `~target~anchor要素$の`~anchor~box$の辺 ］に整列するような。 ◎ An anchor() function representing a resolvable anchor function resolves at computed value time (using style & layout interleaving) to the <length> that would align the edge of the positioned boxes' inset-modified containing block corresponding to the property the function appears in with the specified edge of the target anchor element’s anchor box.
注記： このことは、 `~anchor関数$を利用している~propの［ `遷移＠~WANIM#_animation-class-css-transition$【！~TRANSITION#transitions】／ `~animation＠~WANIM#_animation-class-css-animation$【！~WANIM#concept-animation】 ］は，［ アリなすべての類の変化に対し， “期待されるとおり” に働くようになる ］ことを意味する ⇒＃ `~anchor~box$が移動されたとき, `~anchor要素$が文書に追加されたとき, `~anchor要素$が文書から除去されたとき, `~anchor要素$の `anchor-name$p ~propの値が変化したとき, 等々 ◎ Note: This means that transitions or animations of a property using an anchor function will work "as expected" for all sorts of possible changes: the anchor box moving, anchor elements being added or removed from the document, the anchor-name property being changed on anchors, etc.
例えば， `.bar { inset-block-start: anchor(--foo block-start); }^css においては、 `anchor$f は，［ `.bar^css 要素の塊-始端~辺と`~anchor要素$ `--foo^v の塊-始端~辺が揃うような長さ ］に解決されることになる。 ◎ For example, in .bar { inset-block-start: anchor(--foo block-start); }, the anchor() will resolve to the length that’ll line up the .bar element’s block-start edge with the --foo anchor’s block-start edge.
他方， `.bar { inset-block-end: anchor(--foo block-start); }^css においては、［ `.bar^css 要素 の`塊-終端~辺^emと`~anchor要素$ `--foo^v の塊-終端~辺が揃うような長さ ］に解決されることになる。 ◎ On the other hand, in .bar { inset-block-end: anchor(--foo block-start); }, it will instead resolve to the length that’ll line up the .bar element’s block-end edge with the --foo anchor’s block-start edge.
［ `inset-block-start$p, `inset-block-end$p ］の値は，異なる辺 （要素の`包含塊$の［ 塊-始端, 塊-終端 ］辺） からの~insetを指定するので、 双方の `anchor$f は同じでも，それらを解決した結果の長さは異なることになる。 ◎ Since inset-block-start and inset-block-end values specify insets from different edges (the block-start and block-end of the element’s containing block, respectively), the same anchor() will usually resolve to different lengths in each.
`anchor$f 関数は、 `length$t に解決されるので，他の長さと同様に`~math関数$内でも利用できる。 ◎ Because the anchor() function resolves to a <length>, it can be used in math functions like any other length.
もっと良い例を追加する — この例は、 `anchor-center$vS で容易に成遂げれるので。 `10776$issue ◎ Add a better example; this one can be accomplished easily with anchor-center. [Issue #10776]
例えば，次は、［ 要素の`~insetで改変された包含塊$ ］が［ `~anchor~box$上で中央に寄せられ， 要素の`包含塊$を~overflowしない~~範囲でアリな限り幅広になる ］よう，要素を設定しておくことになる： ◎ For example, the following will set up the element so that its inset-modified containing block is centered on the anchor box and as wide as possible without overflowing the containing block:
.centered-message {
position: fixed;
max-width: max-content;
justify-self: center;
--center: anchor(--x 50%);
--half-distance: min(
abs(0% - var(--center)),
abs(100% - var(--center))
);
left: calc(var(--center) - var(--half-distance));
right: calc(var(--center) - var(--half-distance));
bottom: anchor(--x top);
}
これは例えば、 `input$e 要素に対する~error~message用に適切になることもあろう — 中央に寄せたことにより，当の~messageが どの入力を参照rしているか発見し易くなるので。 ◎ This might be appropriate for an error message on an input element, for example, as the centering will make it easier to discover which input is being referred to.
3.2.1. `anchor^f の解決
所与の `anchor$f 関数 %関数 は、［ それを指定した`~inset~prop$ %~prop, %~prop が適用される~box %~box ］に関して ~AND↓ が満たされる場合に限り， `解決-可能な~anchor関数@ になる： ◎ An anchor() function is a resolvable anchor function only if all the following conditions are true:
- %~box は`絶対的に位置され$ている ◎ It’s applied to an absolutely positioned box.
-
%関数 の `anchor-side$t が物理-~keywordを指定している場合、 %~prop は当の~keywordが参照rする軸に適用-可能である ◎ If its <anchor-side> specifies a physical keyword, it’s specified in an inset property applicable to that axis.＼
（例えば， `left$vA を利用し得る~propは、 横~軸に適用-可能な`~inset~prop$ — `left$p, `right$p, これらと同じ側に対応する~flow相対な~prop — に限られる。） ◎ (For example, left can only be used in left, right, or a logical inset property in the horizontal axis.)
- `~target~anchor要素$( %~box, %関数 内に指定された `anchor-name$t ) ~NEQ ε ◎ There is a target anchor element for the box it’s used on, and the <anchor-name> value specified in the function.
これらいずれかの条件が満たされない場合 ⇒＃ ~fallback値（ 3 個目の引数）が指定されていた場合，それが %関数 の`算出d値$を与える。 他の場合， %関数 を参照している宣言は`算出d値の時点で無効$になる。 ◎ If any of these conditions are false,＼ the anchor() function computes to its specified fallback value.＼ If no fallback value is specified, it makes the declaration referencing it invalid at computed-value time.
3.3. ~scrollの織り込み法
処理能の理由から、 各~実装は，通例的に~scrollingを別々な［ ~scroll／“組成-” ］用の~threadで遂行する — それが有する能力は，ごく制限されるので （単純な動きや変形, 等々であり，~layoutや それに類似な高価な演算を伴わない）、 ~scrollingが［ ヒトの知覚からは “瞬時” と見なされるほど十分~速く応答する ］ことに依拠できる。 ◎ For performance reasons, implementations usually perform scrolling on a separate scrolling/"compositing" thread, which has very limited capabilities (simple movement/transforms/etc., but no layout or similar expensive operations) and thus can be relied upon to respond to scrolling fast enough to be considered "instant" to human perception.
~scrollingが ある~anchorへ位置された有位置な要素 %要素 を`移動させるだけ^emならば、 理論~上は，課題は無い — 当の動きは，~scroll用の~threadで遂行できるので、 %要素 は，~scrollしている内容と伴に滑らかに移動する。 しかしながら、 `~anchor位置決め$は， %要素 の自前の［ ある辺, その対~辺 ］の位置が`異なる^em~scroll用の文脈における何かに依存するようになる ］ことを許容する。 それは、 ~scrollingが %要素 の`片方の辺だけ^em移動し得ることを意味する — その結果、 %要素 の~sizeが変化して，~scroll用の~threadでは遂行できない~layoutを遂行させる。 ◎ If scrolling just causes an anchor-positioned element to move, there is in theory no issue; the movement can be performed on the scrolling thread so the positioned element moves smoothly with the scrolling content. However, anchor positioning allows an element to make the positions of its own opposite edges depend on things in different scrolling contexts, which means scrolling could move just one edge and cause a size change, and thus perform layout. This can’t be performed on the scrolling thread!
アリな限り様々な要素を~anchor先にする自由度を依然として許容しながら，これを補償するため、 `~anchor位置決め$は，［ `記憶した~scroll~offset$, `~scroll補償$ ］の組合nを利用する。 ◎ To compensate for this, while still allowing as much freedom to anchor to various elements as possible, anchor positioning uses a combination of remembered scroll offsets and compensating for scroll.
注記： ここに与える詳細は技術的であるが、 要は，所与の有位置な要素 %要素 に対し： ◎ The details here are technical, but the gist is:
-
%要素 が［ 最初に表示される／`~fallbackを変更する＠#fallback$ ］とき、 %要素 の位置は［ %要素 のすべての`~anchor候補$の最新な位置 ］に則って正しく計算される。 ◎ When a positioned element is first displayed, or when it changes fallbacks, its position is correctly calculated according to the up-to-date position of all anchor references.
これらの`~anchor候補$どうしが異なる~scroll文脈~内にある場合、 それらによる総~scroll~offsetが`記憶され^em， 【 %要素 の】~layoutは — それら【！の要素】が後で~scrollされる場合でも — この記憶された~offsetを利用して継続される （~scroll~offsetに限り記憶される — それらが実際~lay-outされる位置は、 各回に新規に計算され，正確aであり続ける）。 それらは、 %要素 が［ 表示されるか否かが変化した場合／ ~fallbackを変更した場合 ］に限り，計算し直されることになる。 ◎ If these anchor references are in a different scroll context, their total scroll offsets are memorized, and layout will continue using those memorized offsets, even if those elements are scrolled later. (Only the scroll offsets are memorized; their actual laid-out positions are freshly calculated each time and remain accurate.) They’ll only recalculate if the positioned element stops being displayed and starts again, or changes fallbacks.
- 唯一の例外は，`既定の~anchor要素$であり、 当の~anchorが その`記憶した~scroll~offset$から離れるよう~scrollされた場合、 %要素 は，それと伴に移動する。 これは，`純粋に^em 位置におけるズレなので、 %要素 の~sizeは変化し得ない — さもなければ、 それに呼応して~layoutが要求される。 ◎ The one exception to this is the default anchor element; if it’s scrolled away from its remembered scroll offset, the positioned element moves with it. Because this is *purely* a shift in position, the positioned element can’t change size or otherwise require layout in response.
その結果として，`~anchor位置決め$は、 一般には，%要素 の~anchor先が何であれ “そのとおりに働く” べきであるが、 自身が~scrollingに対し どう応答し得るかにおいては，制限されるかもしれない。 ◎ The end result is that anchor positioning should generally "just work", regardless of what the element is anchoring to, but it might be limited in how it can respond to scrolling.
`絶対的に位置され$た要素 %要素 用の `~anchor再~計算@ （ `anchor recalculation point^en ）は： ◎ An anchor recalculation point occurs for an absolutely positioned element＼
- %要素 が~boxを生成し始めるとき （すなわち， %要素 の `display$p が［ `none^v ／ `contents^v ］から他の値へ切替わったとき） に生じる — %要素 が~CSS~animationの稼働を開始するときと一致するように 【おそらく， `display^p の`~animate法＠~CSSDISP#display-animation$を指す】 。 ◎ whenever that element begins generating boxes (aka switches from display:none or display:contents to any other display value), identical to when it starts running CSS animations.
- %要素 用に`位置~fallback~style群を決定する$ときにも生じる — その結果として，~fallback~style群が変化した場合、 %要素 は，選ばれた~fallback~style群に結付けられた`~anchor再~計算$の結果を利用する。 ◎ An anchor recalculation point also occurs for an element when determining position fallback styles for that element; if it changes fallback styles as a result, it uses the result of the anchor recalculation point associated with the chosen set of fallback styles.
-
それが生じたときは、 %要素 の`首要~box$ %~box の各`~anchor候補$ %~anchor に対し， `記憶した~scroll~offset@ （ `remembered scroll offset^en ） を結付ける — それは、 `その時点における^em，［ %~anchor の先祖である`~scroll容器$のうち， %~box の`包含塊$に~~達する前までのものすべて ］の`~scroll~offset$の総和に等しい。 `記憶した~scroll~offset$は、 ~scrollに依存する他の位置決め変更 — `position:sticky$p など — も織り込む。 %~box は`既定の~anchor要素$ %既定の~anchor を有する場合、 常に %既定の~anchor 用にも`記憶した~scroll~offset$を計算する — %~box が %既定の~anchor を指す`~anchor参照$を実際には有さない場合でも。 ◎ When an anchor recalculation point occurs for an element abspos, then for every element anchor referenced by one of abspos’s anchor references, it associates a remembered scroll offset equal to the current sum of the scroll offsets of all scroll container ancestors of anchor, up to but not including abspos’s containing block. The remembered scroll offset also accounts for other scroll-dependent positioning changes, such as position: sticky. If abspos has a default anchor element, it always calculates a remembered scroll offset for it, even if abspos doesn’t actually have an anchor reference to it.
- すべての`~anchor候補$【の位置？】は、［ すべての`~scroll容器$が各自の`初期~scroll位置$にあって， 各~anchor候補に対し，それに結付けられた`記憶した~scroll~offset$を それらに加算した ］かのように計算される。 ◎ All anchor references are calculated as if all scroll containers were at their initial scroll position, and then have their associated remembered scroll offset added to them.
変形には~scrollingと同じ課題【この節の冒頭に述べた課題】があるので、 類似に，`~anchor位置決め^citeは、 通常は，それらに対し注意を払わない【？】。 ここに変形の効果も組入れることはできるか？ ◎ Transforms have the same issue as scrolling, so Anchor Positioning similarly doesn’t pay attention to them normally. Can we go ahead and incorporate the effects of transforms here?
上述は、 有位置な要素 %要素 に対し，［ %要素 の`~anchor候補$たちの~scroll位置【の変化？】に対し`一回だけ^em応答する ］ことを許容するが、 それらのうちいずれかが~scrollされた場合、 %要素 は，もはや それら【いずれか】へ~anchorされたように現れなくなることになる （ %要素 は、 ~scrolling以外による動きに対しては，応答し続けることになるが）。 この問題は，`一般には^em解けないが、 `1 個^emの`~anchor候補$ — 特定的に，`既定の~anchor要素$ — の~scrollingに対しては`応答できる^em： ◎ The above allows a positioned element to respond to the scroll positions of its anchor references once, but if any of them are scrolled, the positioned element will no longer appear to be anchored to them (tho it will continue to respond to their non-scrolling movement). While this problem can’t be solved in general, we can respond to the scrolling of one anchor reference; specifically, the default anchor element:
`絶対的に位置され$た~box %~box は，所与の［ 横~軸／縦~軸 ］ %軸 において `~scroll補償@ を有する（ `compensates for scroll^en ）とは、 ~AND↓ が満たされることをいう： ◎ An absolutely positioned box abspos compensates for scroll in the horizontal or vertical axis if both of the following conditions are true:
- %~box の`既定の~anchor~box$ ~NEQ ε — 以下， %既定の~anchor と記す。 ◎ abspos has a default anchor box.
-
~OR↓ （ %~box の`~anchor参照$のうちいずれかは、 %既定の~anchor か，同じ~scrolling文脈~内にある何かを指している）： ◎ abspos has an anchor reference to its default anchor box or at least to something in the same scrolling context, aka at least one of:
- %~box の［ %軸 を対象にする`自己-整列~prop$ ］の`使用~値$ ~EQ `anchor-center$vS ◎ abspos’s used self-alignment property value in that axis is anchor-center;
- %~box の `position-area$p の値 ~NEQ `none$vI ◎ abspos has a non-none value for position-area
-
( ある `anchor$f 関数 %関数, ある`~anchor要素$ %~anchor ) に関して， ~AND↓ が満たされる：
- %~box の［ %軸 を対象にする`~inset~prop$ ］のうちいずれかの`使用~値$は %関数 を利用している
- %~anchor ~EQ `~target~anchor要素$( %~box, %関数 内に指定された `anchor-name$t )
- ［ %~anchor の先祖である`~scroll容器$のうち %~anchor に最も近いもの ］ ~EQ ［ %既定の~anchor の先祖である`~scroll容器$のうち %既定の~anchor に最も近いもの ］
注記： %~box の`位置~option~list$は空でない【！has】場合、 それにより適用された~fallback~styleも， ある軸において`~scroll補償$を有するかどうかに影響する。 ◎ Note: If abspos has a position options list, then whether it compensates for scroll in an axis is also affected by the applied fallback style.
`絶対的に位置され$た~box %~box の `~scrollに対する既定のズレ@ （ `default scroll shift^en ）は、 2 個の長さ — 順に［ 横~軸, 縦~軸 ］用のそれ — が成す~pairである。 これらの長さは、 各 %軸 に対し，次に従って計算される： ◎ abspos’s default scroll shift is a pair of lengths for the horizontal and vertical axises, respectively. Each length is calculated as:
- ~IF［ %~box は %軸 において`~scroll補償$を有する ］ ⇒ ~RET 次に挙げる 2 つの［ %軸 における差 ］ ⇒＃ `既定の~anchor要素$の`記憶した~scroll~offset$, 現在の`記憶した~scroll~offset$を計算し直したとするときの結果 ◎ If abspos is compensating for scroll in the axis, then the length is the difference between the remembered scroll offset of the default anchor element and what its current remembered scroll offset would be if it were recalculated.
- ~RET 0 ◎ Otherwise, the length is 0.
%~box は、 それ用に~layoutが遂行された後に，`~scrollに対する既定のズレ$により追加的にズラされる — ある変形【！~STREAMS#generictransformstream-transform】により影響されたかのように （他の変形よりも前に【？】）。 ◎ After layout has been performed for abspos, it is additionally shifted by the default scroll shift, as if affected by a transform (before any other transforms).
【`~scrollに対する既定のズレ$を】 ~snapshotする精確な時機を定義する必要がある — 各【描画】~frameごとに，~styleの再~計算より前に更新されるよう。 ◎ Define the precise timing of the snapshot: updated each frame, before style recalc.
`記憶した~scroll~offset$と類似に、 `既定の~anchor要素$に対する変形に対しても，注意を払えるか？ ◎ Similar to remembered scroll offset, can we pay attention to transforms on the default anchor element?
注記： `記憶した~scroll~offset$は， `anchor$f 関数の値に影響する一方で、 `~scrollに対する既定のズレ$は， 当の要素を直にズラす — 当の要素に対し［ `~inset~prop$の値を決定する, 整列を適用する, 等々 ］より`後^emに。 これは，`通例的^emには判別-不能になるが、 `round(anchor(outside), 50px)＠~CSSVAL#funcdef-round$v の様な事例では， `既定の~anchor要素$の位置を線形でない流儀で変形するので、 挙動における相違を公開することになる。 ◎ Note: While remembered scroll offsets affect the value of anchor() functions, default scroll shift directly shifts the element, after determining the value of its inset properties, applying alignment, etc. This is usually indistinguishable, but cases like round(anchor(outside), 50px), which transform the default anchor element’s position in a non-linear fashion, will expose the difference in behavior.
4. ~anchorに基づく整列
4.1. 位置~区画に特有な既定の整列
`position-area$p が `none$vI 以外をとるときは、 `自己-整列$用の値 `normal$vS の挙動は， `position-area$t の値に依存して — 当の~boxを~anchorへ向けて整列するよう — 変化する。 すなわち、 所与の軸 %軸 における既定の整列は， %軸 において選定された`位置~区画$に応じて： ◎ When position-area is not none, the behavior of the normal self-alignment value changes depending on the <position-area> value, to align the box towards the anchor:
- ［ “中央” 筋のみ ／ 3 本の筋すべて ］を占める場合 ⇒ `anchor-center$vS になる。 ◎ If the only the center track in an axis is selected, the default alignment in that axis is center. ◎ If all three tracks are selected, the default alignment in that axis is anchor-center.
- 他の場合 ⇒ `位置~区画$が占めない筋がある側になる — “始端” 筋が指定されたならば `end$vS になる，等々。 ◎ Otherwise, the default alignment in that axis is toward the non-specified side track: if it’s specifying the “start” track of its axis, the default alignment in that axis is end; etc.
しかしながら， %軸 における`~inset~prop$のうち片方だけが `auto$v をとる場合、 既定の整列は，代わりに もう片方の~insetを伴う辺へ向かう — これは、 `unsafe$v な（安全でない）整列になる。 ◎ However, if only one inset property in the relevant axis is auto, the default alignment is instead towards the edge with the non-auto inset; and this is an unsafe alignment.
注記： この片方だけ `auto$v の挙動は、［ ~insetが片方だけ指定された下で，`絶対的に位置され$た~boxの位置を制御する仕方 ］を保全する。 ◎ Note: This single-auto behavior preserves the way a single specified inset controls the position of an absolutely positioned box.
例えば，`書字~mode$が英語と等価である（ `horizontal-tb^v, `ltr^v ）と見做すなら、 値 `span-x-start top^v により指定される`位置~区画$は：
- 縦~軸においては、 【 `top^v により指定され，】 “始端（上端）” 筋【！`start$vI 領域】に解決される。 なので、 既定の整列は `align-self:end$p になる （当の~boxの下端`~margin辺$と “上端” 領域の下端~側が接合するようになる）。
- 横~軸においては、 【 `span-x-start^v により指定され，】 { “始端（左端）”, “中央” } 筋【！領域】 ］に解決される。 なので、 既定の整列は `justify-self:anchor-center$p になる （当の~boxの終端`~margin辺$と { “始端”, “中央” } 領域の終端~側が接合するようになる）。
注記： 当の~boxが［ その`~insetで改変された包含塊$を~overflowする ］が，それでも［ その`元の包含塊$の中には収まる ］場合、 既定では，`元の包含塊$の中に居続けるよう “ズラされる” — そうすると，通常の整列に違反する場合でも。 詳細は、 `CSS-ALIGN-3$r `§ ~overflow時の整列＠~CSSALIGN#overflow-values$ を見よ。 ◎ If the box overflows its inset-modified containing block, but would still fit within its original containing block, by default it will “shift” to stay within its original containing block, even if that violates its normal alignment. See CSS Box Alignment 3 § 4.4 Overflow Alignment: the safe and unsafe keywords and scroll safety limits for details.
この挙動は、 有位置な~box %~box を なるべく［ 【 %~box 全体が】可視になるよう，意図される限界域の中にあり続ける ］ようにする — %~box の`包含塊$が見越される~sizeより小さいときでも。 ◎ This behavior makes it more likely that positioned boxes remain visible and within their intended bounds, even when their containing block ends up smaller than anticipated.
例えば， `position-area$p 用の値 `bottom span-right^v は、 %~box を その~anchor先 %~anchor の左端~辺から自身の包含塊の右端~辺まで伸張できるようにする — %~box は、［ 既定では，この空間~内で %~anchor の左端に整列する ］が［ %~box が この空間より大きい場合には （ %~anchor が~screenの右端~辺に ごく近いときなど）， 可視であり続けるよう左方へズラされる ］ことになる。 ◎ For example, a position-area: bottom span-right value lets the positioned box stretch from its anchor’s left edge to its containing block’s right edge, and left-aligns it in that space by default. But if the positioned box is larger than that space (such as if the anchor is very close to the right edge of the screen), it will shift leftwards to stay visible.
4.2. ~anchor上での中央~寄せ： `anchor-center^v 整列~値
`自己-整列~prop$は、 `絶対的に位置され$た~boxが［ その`~insetで改変された包含塊$の中で自身を整列する ］ことを許容する。 通例的には，［ 既存の値に加えて，`~inset~prop$を注意深く選ぶこと ］で有用な整列~用には十分になるが、 ~anchor先での位置決め用に共通的な事例 — `~anchor~box$上で中央に寄せること — を達成するためには、 注意深い, いくぶん複階的な設定-法が要求される。 ◎ The self-alignment properties allow an absolutely positioned box to align itself within the inset-modified containing block. The existing values, plus carefully chosen inset properties, are usually enough for useful alignment, but a common case for anchored positioning—centering over the anchor box—requires careful and somewhat complex set-up to achieve.
新たな値 `anchor-center@vS は、 この事例を極めて単純にする — 所与の~box %~box が ~AND↓ を満たす場合…
- `絶対的に位置され$ている
- その`既定の~anchor~box$ %~anchor ~NEQ ε
…場合、 関連な軸 【この値を利用している~propが対象にする軸】 において：
◎ The new anchor-center value makes this case extremely simple: if the positioned box has a default anchor box,＼- %~box は %~anchor 上で（アリな限り）中央に寄せられるようになる。 ◎ then it is centered (insofar as possible) over the default anchor box in the relevant axis.
- %~box の`~inset~prop$用の値 `auto$v は `0^v に解決される。 ◎ Additionally, any auto inset properties resolve to 0.
%~box が上の条件を満たさない場合、 `anchor-center$vS は `center$vS として挙動する — `~inset~prop$の解決-法に対する追加的な効果は無い。 ◎ If the box is not absolutely positioned, or does not have a default anchor box, this value behaves as center and has no additional effect on how inset properties resolve.
注記： `anchor-center$vS を利用しているときは、 %~anchor が %~box の`元の包含塊$ %包含塊 の辺に近過ぎる場合には — %包含塊 の中にあり続けるよう — 既定では，中央から “ズラされる” ことになる。 詳細は、 `CSS-ALIGN-3$r `§ ~overflow時の整列＠~CSSALIGN#overflow-values$ を見よ。 ◎ Note: When using anchor-center, by default if the anchor is too close to the edge of the box’s original containing block, it will “shift” from being purely centered, in order to remain within the original containing block. See CSS Box Alignment 3 § 4.4 Overflow Alignment: the safe and unsafe keywords and scroll safety limits for more details.
4.3. 条件付きな中央~寄せ： `dialog^v 整列~値
~dialog~boxは、 ~screenの中央に寄せて表示されることが多い — 他の何らかの要素を~anchor先としていない限り。 ◎ Dialog boxes are often displayed centered on the screen, unless they are anchored to some other element.
新たな値 `dialog@vS は、 この挙動を指定することを許容する ⇒ 当の~boxが［ `絶対的に位置され$ていて， その `position-area$p の値は `none$vI 以外をとる ］ならば、 当の~boxは `normal$vS に従うよう整列される — `§ 位置~区画に特有な既定の整列＠#position-area-alignment$ を見よ。 他の場合、 `center$vS に従うよう整列される。 ◎ The new dialog value allows this behavior to be specified: if the box is absolutely positioned and its position-area value is not none, it is aligned as per normal (see § 4.1 Area-specific Default Alignment); otherwise, it is aligned as per center.
5. ~anchorに基づく~sizing
`絶対的に位置され$る~boxは、［ 自身の`~sizing~prop$において `anchor-size@f 関数を利用する ］ことにより［ 1 個以上の`~anchor~box$の~size ］を参照rできる。 この関数は、 `length$t に解決される。 この関数は、 `position-try^at に`受容される~prop$内【かつ `position-try$at 規則の中？】に限り，許容される （他においては無効になる）。 ◎ An absolutely positioned box can use the anchor-size() function in its sizing properties to refer to the size of one or more anchor boxes. The anchor-size() function resolves to a <length>. It is only allowed in the accepted @position-try properties (and is otherwise invalid).
5.1. `anchor-size^f 関数
anchor-size() = anchor-size( [ `anchor-name$t || `anchor-size$t ]?, `length-percentage$t? ) `anchor-size@t = `width$v | `height$v | `block$v | `inline$v | `self-block$v | `self-inline$v
`anchor-size$f 関数は、 `anchor$f と類似する — それは、［ `anchor-side$t が `anchor-size$t に置換される 【かつ省略可能である】 ］ことを除いて，同じ引数をとる。 ◎ The anchor-size() function is similar to anchor(), and takes the same arguments, save that the <anchor-side> keywords are replaced with <anchor-size>,＼
`anchor-size$t は、 反対-側にある 2 辺の距離を参照rする： ◎ referring to the distance between two opposing sides.
- `width@v
- `height@v
- これらの物理-~keywordは、 順に，`~target~anchor要素$の［ 横幅, 縦幅 ］を参照rする。 `anchor$f と違って、 軸が合致しなければならない制約は無い — 例えば、 `width: anchor-size(--foo height)$p は妥当になる。 ◎ The physical <anchor-size> keywords (width and height) refer to the width and height, respectively, of the target anchor element. Unlike anchor(), there is no restriction on having to match axises; for example, width: anchor-size(--foo height); is valid.
- `block@v
- `inline@v
- `self-block@v
- `self-inline@v
-
これらの論理-~keywordは、 次に依存して， いずれか適切な方の物理-~keywordに対応付けられる：
- ［ `self-block$v ／ `self-inline$v ］用には、 当の~boxの`書字~mode$
- ［ `block$v ／ `inline$v ］用には、 当の~boxの`包含塊$の`書字~mode$
`anchor-size$t ~keywordが省略された場合の既定では、 何であれ［ `anchor-size$f を利用した~propが対象にする軸に合致する~keyword† ］が指定されたかのように挙動する （例えば、 `width:anchor-size()$p は， `width: anchor-size(width)^p と等価になる）。 ◎ If the <anchor-size> keyword is omitted, it defaults to behaving as whatever keyword matches the axis of the property that anchor-size() is used in. (For example, width: anchor-size() is equivalent to width: anchor-size(width).)
【† 対象にする軸が，例えば塊~軸である場合、 `block^v, `self-block^v どちらも合致し得るが， どちらなのかは指定されていない（前者？）。 】
`anchor-size$f 関数は、 `解決-可能な~anchor~size関数$を表現しているならば， （`~styleと~layoutの差挟み$を介して） `算出d値$の時点で［ `~target~anchor要素$の`~anchor~box$を成す関連な 2 つの辺 — 横幅を参照するならば左端と右端／ 縦幅を参照するならば上端と下端 — の距離 ］を成す `length$t に解決される。 ◎ An anchor-size() function representing a resolvable anchor-size function resolves at computed value time (via style & layout interleaving) to the <length> separating the relevant edges (either left and right, or top and bottom, whichever is in the specified axis) of the target anchor element’s anchor box.
5.1.1. `anchor-size^f の解決
所与の `anchor-size$f 関数 %関数 は、 ある~box %~box に関して ~AND↓ が満たされる場合に限り， `解決-可能な~anchor~size関数@ になる： ◎ An anchor-size() function is a resolvable anchor-size function only if all the following conditions are true:
- %~box は`絶対的に位置され$ている ◎ It’s applied to an absolutely positioned box.
- `~target~anchor要素$( %~box, %関数 内に指定された `anchor-name$t ) ~NEQ ε ◎ There is a target anchor element for the box it’s used on, and the <anchor-name> value specified in the function.
他の場合 ⇒＃ ~fallback値（ 3 個目の引数）が指定されていた場合， %関数 はそれに解決される。 他の場合， %関数 を参照している宣言は`算出d値の時点で無効$になる。 ◎ If any of these conditions are false, the anchor-size() function resolves to its specified fallback value. If no fallback value is specified, it makes the declaration referencing it invalid at computed-value time.
6. ~overflowの管理
~anchor位置決めは、 強力ではあるが，予測-不能にもなり得る。 `~anchor~box$は，~page上のどこにでも~~現れ得るので、 ある有位置な~boxを特定0の流儀（当の~anchorの上や右端など）で位置した結果、 当の~boxは，［ 自身の`包含塊$を~overflowする／ 部分的に~screen外に位置される ］かもしれない。 ◎ Anchor positioning, while powerful, can also be unpredictable. The anchor box might be anywhere on the page, so positioning a box in any particular fashion (such as above the anchor, or the right of the anchor) might result in the positioned box overflowing its containing block or being positioned partially off screen.
これを~~改善するため、 `絶対的に位置され$る~boxは， `position-try-fallbacks$p ~propを利用して，［ 当の~boxが初期~位置では~overflowする場合に，~UAが試行できる~option ］たちを参照rできる。 各~optionは、［ 位置決め／整列 ］~prop【宣言】たち （当の~boxの既存の~styleから生成されるもの／ `position-try$at 規則~内に指定されたもの） が成す集合を与える。 各~optionは、 順に 1 つずつ当の~boxに適用され，［ その結果，要素が自身の`包含塊$を~overflowしない最初のもの ］が~~採用されることになる。 ◎ To ameliorate this, an absolutely positioned box can use the position-try-fallbacks property to refer to several variant sets of positioning/alignment properties (generated from the box’s existing styles, or specified in @position-try rules) that the UA can try if the box overflows its initial position. Each is applied to the box, one by one, and the first that doesn’t cause the box to overflow its containing block is taken as the winner.
`position-try-order$p は、［ 何らかの宣言された順序に厳密に従うよりも， 当の~box用の空間をアリな限り広くとる方が重要な場合 ］に，追加的に［ それが定義する可用な空間に基づいて，~optionたちを~sortする ］ことを許容する。 ◎ position-try-order allows these options to additional be sorted by the available space they define, if it’s more important for the box to have as much space as possible rather than strictly follow some declared order.
6.1. ~fallback~optionの与え方： `position-try-fallbacks^p ~prop
この~propは、 `位置~option~list@ を供する — それは、［ `絶対的に位置され$た~boxが その`~insetで改変された包含塊$を~overflowするときに試行する代替-位置決め~style ］たちからなり， 初期~時は空とする。 ◎ This property provides a list of alternate positioning styles to try when the absolutely positioned box overflows its inset-modified containing block. This position options list is initially empty.
当の~listを成す（~commaで分離された）各~itemは、 別々な~optionを次に挙げるいずれかとして与える： ◎ Each comma-separated entry in the list is a separate option: either＼
- ある `position-try$at ~blockの名前 ◎ the name of a @position-try block,＼
- ある `try-tactic$t — それは、 当の~boxの既存の算出d~styleに対する自動的な変形nを表現する ◎ or a <try-tactic> representing an automatic transformation of the box’s existing computed style.
各種 値の意味は： ◎ Values have the following meanings:
- `none@vOp
- この~propによる効果は無い。 当の~boxの`位置~option~list$は空になる。 ◎ The property has no effect; the box’s position options list is empty.
- `dashed-ident$t
- 所与の名前を伴う `position-try$at 規則が在る場合、 それに結付けられた`位置~option$が`位置~option~list$に追加される。 ◎ If there is a @position-try rule with the given name, its associated position option is added to the position options list.
- そのような規則は無い場合、 この値による効果は無い。 ◎ Otherwise, this value has no effect.
- `try-tactic$t
-
当の~boxの算出d~styleから`位置~option$を自動的に作成する — ［ 指定された~keywordに則って，当の~boxの`~styleを入替える$ ］ことにより構築された`位置~option$を［ 当の~boxの`位置~option~list$に追加する ］ことにより。 【！and adds it ...重複】 ◎ Automatically creates a position option from the box’s computed style, by swapping due to a try-tactic according to the specified keyword, and adding the constructed position option to the box’s position options list. and adds it to the position options list.
`try-tactic@t = flip-block || flip-inline || flip-start
- `flip-block@vOp
- `塊-軸$に関する~propたち （例： `margin-block-start$p と `margin-block-end$p ） の値どうしを入替える — 本質的に，`行内-軸$を挟んで鏡写しになるよう。 ◎ swaps the values in the block axis (between, for example, margin-block-start and margin-block-end), essentially mirroring across an inline-axis line.
- `flip-inline@vOp
- `行内-軸$に関する~propたちの値どうしを入替える — 本質的に，`塊-軸$を挟んで鏡写しになるよう。 ◎ swaps the values in the inline axis, essentially mirroring across a block-axis line.
- `flip-start@vOp
- ［ `始端$に関する~prop, `終端$に関する~prop ］ （例： `margin-block-start$p と `margin-inline-start$p ） の値どうしを入替える — 本質的に，［ `塊-始端$, `行内-始端$ ］にある隅から［ `塊-終端$, `行内-終端$ ］にある隅へ描かれる対角線を挟んで鏡写しになるよう。 ◎ swaps the values of the start properties with each other, and the end properties with each other (between, for example, margin-block-start and margin-inline-start), essentially mirroring across a diagonal drawn from the start-start corner to the end-end corner.
- 複数個の~keywordが与えられた場合、 それらによる変形nは，単独の`位置~option$を生産するよう構成される。 ◎ If multiple keywords are given, the transformations are composed in order to produce a single position option.
- `dashed-ident$t || `try-tactic$t
- 所与の `dashed-ident^t を名前に伴う `position-try$at 規則は在る場合 ⇒ ［ 当の規則の`位置~option$を当の~boxの基底~styleに適用した結果 ］を［ 指定された `try-tactic$t に則って変形した結果 ］を当の~boxの`位置~option~list$に追加する。 ◎ Combines the effects of the previous two options:＼ • if there is a @position-try rule with the given name, applies its position option to the base style, then transforms it according to the specified <try-tactic> and adds the result to the box’s position options list.
- 他の場合、 何もしない。 ◎ • Otherwise, does nothing.
- `position-area$t
- もっぱら，所与の値を伴う `position-area$p ~propで構成される`位置~option$を自動的に作成する。 ◎ Automatically creates a position option composed solely of a position-area property with the given value.
`~styleを入替える@ ~algoは、 所与の ⇒＃ 【！~box’s 】要素 %要素, `try-tactic$t が指示する 2 個の（上下左右）方向 %二つの方向 ◎終 に対し，［ %二つの方向 に対応する %要素 の “同類” な~propどうしの値 ］を適切に入替えて得られる~styleたちが成す集合を返す： ◎ To swap due to a try-tactic the styles of a box’s element el between two directions directions, returning a set of styles:
- %反対-向きか ~LET ~IS［ %二つの方向 は同じ軸に沿って反対-向きである ］ 【すなわち，`try-tactic$t は `flip-block$vOp か `flip-inline$vOp 】 ◎ If directions are opposites along the same axis, they are “opposing”. Otherwise (when they are specifying different axises), they are “perpendicular”.
- %~style群 ~LET %要素 の各`受容される~prop$の指定d値を決定した結果 ◎ Determine the specified values of the accepted @position-try properties on el, and let styles be the result.
-
%~style群 を成す各~propに対し ⇒ その値~内の`任意-代入~関数たちへ代入する$ 【！／`代入する＠~CSSENV#substitute-an-env$】 ◎ Substitute variables, env() functions, and similar arbitrary substitution functions in styles.
`任意-代入~関数$が `env$f 関数であって，それが参照する`環境~変数$には ある［ 方向／軸 ］が結付けられている場合には （ `safe-area-inset-top＠~CSSENV#valdef-env-safe-area-inset-top$v など）， 当の環境~変数を %二つの方向 【を成す当の［方向／軸］ではない方？】に対応するものへ切替える。 ◎ For env() functions, if the referenced environment variable is associated with a direction or axis (such as safe-area-inset-top), switch the referenced environment variable corresponding to directions.
例えば、 `top: env(safe-area-inset-top)$p が指定されていて， %二つの方向 は { 上, 左 } ならば、 `env$f は［ 代わりに `env(safe-area-inset-left)^v が指定された ］かのように解決されることになる （それから、 次~段において，実際に `left$p ~propと入替えることになる）。 ◎ For example, if top: env(safe-area-inset-top); is specified, and directions are up and left, the env() will resolve as if env(safe-area-inset-left) had been specified instead. (And then, in the next step, will actually swap into the left property.)
-
%~style群 を成す［ %二つの方向 に対応する “同類” な~prop ］どうしで値を入替える。 ◎ Swap the values of the styles between the associated properties corresponding to directions.
例えば，［ 上端, 左端 ］が入替えらている場合、［ `margin-top$p, `margin-left$p ］どうし, ［ `width$p, `height$p ］どうし, 等々で，互いの値を入替える。 ◎ For example, if "top" and "left" are being swapped, then the values of margin-top and margin-left are swapped, width and height are swapped, etc.
注記： 一部の~prop（`width$p や `align-self$p など）は、 %反対-向きか ~EQ ~T の下では，入替えられない — それ自身が， %二つの方向 に対応する互いに “同類” な~propを成すので。 それでも、 それらの値は，次の段により変更され得る。 ◎ Note: If the directions are opposites along the same axis, some properties (like width or align-self) wont' swap, since they’re associated with themselves across the two directions, but their values might be changed by the next step.
-
前~段にて入替えられた各~propの値を以下に従って改変する — ~propに応じて： ◎ Modify the values of the properties as they swap to match the new directions, as follows:
- `~inset~prop$： ◎ For inset properties,＼
-
各~値に利用された `anchor$f 関数~内に指定された側を変更する — 新たな方向においても，変更-前における相対的な関係性を保守するよう ◎ change the specified side in anchor() functions to maintain the same relative relationship to the new direction that they had to the old.
例えば，［ 上端, 左端 ］が入替えられている場合、 `margin-top:anchor(bottom)$p は， `margin-left:anchor(right)$p になる。 ◎ ↓
-
%反対-向きか ~EQ ~T の場合 ⇒ 各~値に利用された `percentage$t を ( `100%^v ~MINUS 元の百分率 ) に変更する ◎ If a <percentage> is used, and directions are opposing, change it to 100% minus the original percentage.
例えば，［ 上端, 下端 ］が入替えられている場合、 `margin-top:anchor(20%)$p は， `margin-bottom:anchor(80%)$p になる。 ◎ ↑ For example, if "top" and "left" are being swapped, then margin-top: anchor(bottom) will become margin-left: anchor(right). ◎ If "top" and "bottom" are being swapped, then margin-top: anchor(20%) will become margin-bottom: anchor(80%).
- `~sizing~prop$： ◎ For sizing properties,＼
-
各~値に利用された `anchor$f 関数~内に指定された軸を変更する — 新たな方向においても，変更-前における相対的な関係性を保守するよう ◎ change the specified axis in anchor-size() functions to maintain the same relative relationship to the new direction that they had to the old.
例えば，［ 上端, 左端 ］が入替えられている場合、 `width:anchor-size(width)$p は， `height:anchor-size(height)$p になる。 ◎ For example, if "top" and "left" are being swapped, then width: anchor-size(width) will become height: anchor-size(height).
- `自己-整列~prop$： ◎ For the self-alignment properties,＼
-
%反対-向きか ~EQ ~T の場合 ⇒ 指定された値が［ `self-position$t ／ `left^v ／ `right^v ］ならば、 それを変更する — 新たな方向においても，変更-前における相対的な関係性を保守するよう ◎ if directions are opposing, change the specified <self-position> (or left/right keywords), if any, to maintain the same relative relationship to the new direction that they had to the old.
例えば，［ 上端, 下端 ］が入替えられている場合、 `align-self:start$p は， `align-self:end$p になる。 ◎ For example, if "top" and "bottom" are being swapped, then align-self: start will become align-self: end.
しかしながら、 `align-self:center$p は，そのままであり続けることになる — どちらの方向も関係性は前と同じなので。 ◎ However, align-self: center will remain unchanged, as it has the same relationship to both directions.
類似に， `align-self:first$p は、 `self-position$t ではなく `baseline-position$t なので，そのままであり続ける。 ◎ Similarly, align-self: first baseline will remain unchanged, as it’s a <baseline-position> rather than a <self-position>.
- `position-area$p ~prop： ◎ For position-area,＼
-
値を変更する — 新たな方向においても，変更-前における 【！`位置~区画~用の格子$を成す選定された】 `位置~区画$を成す［ ~rowたち, ~colたち ］の相対的な関係性を保守するよう ◎ change the value so that the selected rows/columns of the position-area grid maintain the same relative relationship to the new direction that they had to the old.
例えば，［ 上端, 左端 ］が入替えられた場合、 `position-area:left span-bottom$p は， `position-area:top span-right^p になる。 ◎ For example, if "top" and "left" are being swapped, then position-area: left span-bottom will become position-area: top span-right.
- ~RET %~style群 ◎ Return styles.
6.2. ~fallback順序の決定-法： `position-try-order^p ~prop
この~propは、 `位置~option~list$を成す`位置~option$たちが試行されることになる順序を指定する。 ◎ This property specifies the order in which the position options list will be tried.
`try-size@t = most-width | most-height | most-block-size | most-inline-size
- `normal@vOd
- `position-try-fallbacks$p により指定された順序で`位置~option$を試行する。 ◎ Try the position options in the order specified by position-try-fallbacks.
- `most-width@vOd
- `most-height@vOd
- `most-block-size@vOd
- `most-inline-size@vOd
- まず、 `位置~option~list$を成す各`位置~option$に対し， 当の~boxに その`位置~optionを適用する$ — その結果を成す~style群により指定される`~insetで改変された包含塊$の~sizeを見出す。 次に、 `位置~option~list$を これらの~size†に則って — 最~大なものが最初に来るよう — 安定に††~sortする。 ◎ For each entry in the position options list, apply that position option to the box, and find the specified inset-modified containing block size that results from those styles. Stably sort the position options list according to this size, with the largest coming first.
- 【† 縦横どちらの寸法かは、 当の~keywordの名前により指示される — `most-width^v なら横幅, 等々。 】【†† すなわち，~sizeが同じものどうしは元の順序に従う。 】
例えば，次の~styleは、 初期~時は， ~popup~list【 `.list^css 】を その~anchor先【 `.anchor^css 】の下に位置させるが、 ~overflowする場合には，［ どの~optionが最も空間を与えるかに依存して， 当の~popup~listを~anchorの下に保つか上へ移動するか裁定する ］ことになる。 ◎ For example, the following styles will initially position the popup list below its anchoring button, but if that overflows, will decide whether to keep the popup list below the anchor or move it above, depending on which option gives it the most space.
.anchor { anchor-name: --foo; }
.list {
position: fixed;
position-anchor: --foo;
position-area: block-end span-inline-end;
align-self: start;
position-try-fallbacks: --bottom-scrollable, flip-block, --top-scrollable;
position-try-order: most-height;
}
@position-try --bottom-scrollable {
align-self: stretch;
}
@position-try --top-scrollable {
position-area: block-start span-inline-end;
align-self: stretch;
}
【 `position-try-fallbacks$p に指定された各~optionのうち】［ `flip-block$vOp （これは，【`位置~option$を】自動-生成する）, `--top-scrollable^v ］は、 常に，同じ可用な縦幅を見出すことになる — どちらも包含塊の上端~辺から~anchorの上端へ縦方向に伸張するので。 なので、 それらは，指定された順序を維持することになる 【 `--bottom-scrollable^v は、それらより後になる】。 【初期~時の~styleが~overflowする場合，】 これは、 まず，当の~boxを — その生来な縦幅を~~保ったまま — ~anchorに対し整列するよう【 `flip-block^v を】試行させるが （基底~style【 `align-self:start^p 】から自動-反転された `align-self: end$p を利用して）、 それも~overflowする場合には，代わりに［ 空間を埋めるだけになり， ~scroll可能になる【各 `*-scrollable^v を試行する】よう~fall-backする ］ことになる。 ◎ The flip-block auto-generated option and the --top-scrollable option will always find the same available height, since both of them stretch vertically from the top edge of the containing block to the top of the anchor, so they’ll retain their specified order. This causes the box to first try to align against the anchor at its natural height (using align-self: end, auto-reversed from the base styles), but if that also causes overflow, it’ll fall back to just filling the space and being scrollable instead.
6.3. `position-try^p 略式~prop
この略式~propは、 その下位prop［ `position-try-fallbacks$p, `position-try-order$p ］を設定する。 `position-try-order$tp が省略された場合、 `position-try-fallbacks$p ~propは，その初期~値に設定される。 ◎ This shorthand sets both position-try-fallbacks and position-try-order. If <'position-try-order'> is omitted, it’s set to the property’s initial value.
6.4. `position-try^at 規則
`position-try@at 規則は、 所与の名前を伴う `位置~option@ を定義する。 各`位置~option$は、 ある［ 位置決め~prop【の ( 名前, 値 ) が成す組】たちが成す集合 ］を指定する。 `位置~option$たちは、 `position-try-fallbacks$p を介して~boxに適用できる。 ◎ The @position-try rule defines a position option with a given name, specifying one or more sets of positioning properties that can be applied to a box via position-try-fallbacks,
`position-try$at 規則の構文は： ◎ The syntax of the @position-try rule is:
@position-try `dashed-ident$t {
`declaration-list$t
}
導入部にて指定された `dashed-ident$t が，当の規則の名前になる。 同じ名前を伴う複数個の `position-try$at 規則が宣言された場合、 `keyframes$at【！keyframe】 規則たちに対するときと同じに`~cascade$する。 ◎ The <dashed-ident> specified in the prelude is the rule’s name. If multiple @position-try rules are declared with the same name, they cascade the same as @keyframe rules do.
`position-try$at 規則に `受容される~prop@ は、 次に挙げる`~prop$に限られる： ◎ The @position-try rule only accepts the following properties:
- `~inset~prop$ ◎ inset properties
- `~margin~prop$ ◎ margin properties
- `~sizing~prop$ ◎ sizing properties
- `自己-整列~prop$ ◎ self-alignment properties
- `position-anchor$p
- `position-area$p
`declaration-list$t 内の~propに `!important^css を利用することは、 妥当でない。 その場合、 それを利用した~propは無効になるが， `property-try^at 規則をまるごと無効~化することはない。 ◎ It is invalid to use !important on the properties in the <declaration-list>. Doing so causes the property it is used on to become invalid, but does not invalidate the @property-try rule as a whole.
`position-try$at 内の~propすべては、 `位置~fallback出自$の一部を成すものとして当の~boxに適用される。 `位置~fallback出自@ は、 `作者~出自$と`~animation出自$の合間にある， この仕様にて新たに定義される【！新たな】`出自$である。 ◎ All of the properties in a @position-try are applied to the box as part of the Position Fallback Origin, a new cascade origin that lies between the Author Origin and the Animation Origin.
値 `revert$v が利用された場合、 `~animation出自$と類似に，［ 当の~propは`作者~出自$の一部を成していた ］かのように動作する （`利用者~出自$へ~~巻戻すようになる）。 （しかしながら、 `revert-layer$v には，特別な挙動は無い — それは、 `~animation出自$と同じく，指定されたとおりに動作する。） ◎ Similar to the Animation Origin, use of the revert value acts as if the property was part of the Author Origin, so that it instead reverts back to the User Origin. (As with the Animation Origin, however, revert-layer has no special behavior and acts as specified.)
注記： `position-try^at に`受容される~prop$は、［ ~boxの~sizeと位置だけに影響し，それ以外は~boxの内容や~style付けを変更しない~prop ］たちが成す最~小な~groupを成す。 これは、 位置~fallbackの実装を有意に単純~化する一方で， 基礎的な必要 — ~anchorに基づいて位置された~boxを可用な空間に呼応して移動すること — に取組む。 `position-try^at 【！these】規則は，`作者~出自$内の通常の宣言を上書きするので、 これは，［ `position-try$at 宣言 ］と［ 他の~propの通常の~cascade法と継承 ］の相互作用による悪さも制限する。 `容器~query$に対する将来の拡張は、［ 要素を［ それが利用している位置~fallback ］に基づいて~queryする ］ことを許容して，［ この制約された~listでは許容されない，条件付きな~style付けに類するもの ］を可能化することが期待される。 ◎ Note: The accepted @position-try properties are the smallest group of properties that affect just the size and position of the box itself, without otherwise changing its contents or styling. This significantly simplifies the implementation of position fallback while addressing the fundamental need to move an anchor-positioned box in response to available space. Since these rules override normal declarations in the Author Origin, this also limits the poor interactions of @position-try declarations with the normal cascading and inheritance of other properties. It is expected that a future extension to container queries will allow querying an element based on the position fallback it’s using, enabling the sort of conditional styling not allowed by this restricted list.
注記： 異なる~anchorを利用している複数の~boxが，［ 各自の~anchor要素に，同じ相対的な~fallback位置決めを利用する ］よう求めるなら、 `anchor$f 内の `anchor-name$t を省略して， 代わりに `position-anchor$p により各~box用の~anchorを指定すること。 ◎ Note: If multiple boxes using different anchors want to use the same fallback positioning, just relative to their own anchor elements, omit the <anchor-name> in anchor() and specify each box’s anchor in position-anchor instead.
注記： 最も共通的な~fallback位置決め （有位置な~boxを通常は~anchorの一方の側に置くが，必要なら反対-側へ移転する） は、 `position-try-fallbacks$p 内の~keywordを利用して — `position-try$at をまったく利用することなく — 自動的に行える。 ◎ Note: The most common types of fallback positioning (putting the positioned box on one side of the anchor normally, but flipping to the opposite side if needed) can be done automatically with keywords in position-try-fallbacks, without using @position-try at all.
6.5. 位置~fallbackの適用-法
（自身の`~scrollに対する既定のズレ$によりズラされた） 有位置な~boxは、［ 自身の`~insetで改変された包含塊$を~overflowする ］かつ［ その`位置~option~list$は空でない ］ときは，［ `位置~fallback~style群を決定する$ ］ことにより［ ~overflowを避ける~optionを見出す ］よう試みる。 ◎ When a positioned box (shifted by its default scroll shift) overflows its inset-modified containing block, and has a non-empty position options list, it determines position fallback styles to attempt to find an option that avoids overflow.
これらの改変された~style群は，`~styleと~layoutの差挟み$を介して要素に適用されるので、 ~layoutや`使用~値$に依存するとしても，`算出d値$に影響する （その結果，遷移, 等々を誘発し得る）。 ◎ These modified styles are applied to the element via interleaving, so they affect computed values (and can trigger transitions/etc) even though they depend on layout and used values.
もっと紛らわしくなく かつ正しくなるよう，この節を書き直す。 `12818$issue, `12890$issue を見よ。 ◎ Rewrite this section to be less confusing and more correct. See Issue 12818, Issue 12890.
各~要素は、 `最後の成功裡な位置~option@ を有する — それは、［ ある`位置~option$ ／ ε ］であり，初期~時は ε とする。 【この段落は、この訳による補完。】 ◎ ↑
`位置~optionを適用する@ ~algoは、 所与の ( 【！box’s】 要素 %要素, `位置~option$ %新たな~style群 ) に対し： ◎ To apply a position option to a box’s element el, given a position option new styles:
-
%新たな~style群 を~cascadeの中へ — `位置~fallback出自$内に — 挿入する下で~cascadeを解決する — その結果を利用して，［ %要素 の各~styleの`使用~値$を決定するに十分な~layout ］を遂行する ◎ With new styles inserted into the cascade in the position fallback origin, resolve the cascade, and perform enough layout to determine el’s used styles.
これらの~styleを計算する目的においては、 `仮の^em `~anchor再~計算$が行われる — 結果の仮の`記憶した~scroll~offset$は、 %要素 の~style群を決定するために利用される。 ◎ For the purpose of calculating these styles, a hypothetical anchor recalculation point is calculated, and the resulting hypothetical remembered scroll offsets are used to determine el’s styles.
- ~RET %要素 の［ `使用~値$を伴う~style群 ］ ◎ Return el’s used styles.
要素 %要素【！abspos】 用の `位置~fallback~style群を決定する@ ~algoは： ◎ To determine position fallback styles for an element abspos:
- %現在の~style群 ~LET %要素 にて利用されている現在の~style群 （それは、 それまでの~fallbackの結果かもしれない。） ◎ Let current styles be the current used styles of abspos (which might be the result of earlier fallback).
-
%要素 の`位置~option~list$を成す ~EACH( %~option ) に対し： ◎ For each option in the position options list:
- ~IF［ %~option ~EQ %要素 の`最後の成功裡な位置~option$ 【この比較が何に基づくのかは、定義されていない】 ］ ⇒ ~CONTINUE ◎ If option is currently abspos’s last successful position option, continue.
- %調整-済み~style群 ~LET `位置~optionを適用する$( %要素, %~option ) ◎ Let adjusted styles be the result of applying a position option option to abspos.
- %要素~矩形 ~LET ~sizeと位置が次に一致する矩形 ⇒ %調整-済み~style群 で~lay-outしたとするときの %要素 の`~margin~box$ ◎ Let el rect be the size and position of abspos’s margin box,＼
- %包含塊~矩形 ~LET ~sizeと位置が次に一致する矩形 ⇒ %調整-済み~style群 で~lay-outしたとするときの %要素 の`~insetで改変された包含塊$ ◎ and cb rect be the size and position of abspos’s inset-modified containing block, when laid out with adjusted styles.
-
~IF［ どちらかの軸において、 %包含塊~矩形 の~sizeは，負になったため 0 に正された ］ ⇒ ~CONTINUE ◎ If cb rect was negative-size in either axis and corrected into zero-size, continue.
注記： これは、 %要素~矩形 が［ その~sizeが 0 のときでも，~sizeが負な %包含塊~矩形 の “内側にある” ］と見なされ，［ 成功裡な~optionとして選定される ］ようになることを防止する。 ◎ Note: This prevents a zero-size el rect from still being considered "inside" a negative-size cb rect and getting selected as a successful option.
- ~IF［ %要素~矩形 は %包含塊~矩形 の中に全部的に包含されていない ］ ⇒ ~CONTINUE ◎ If el rect is not fully contained within cb rect, continue.
- %調整-済み~style群 に次を結付ける ⇒ それら【 %要素 の各`~anchor候補$】用に仮に計算された`記憶した~scroll~offset$たちが成す集合 ◎ Return adjusted styles, along with the associated set of remembered scroll offsets that were hypothetically calculated for them.
- ~RET %調整-済み~style群 ◎ ↑
- ~Assert： 前~段は~overflowを避ける`位置~option$を見出すことなく完遂した。 ◎ Assert: The previous step finished without finding a position option that avoids overflow.
- ~RET %現在の~style群 ◎ Return current styles.
注記： %要素【！%el】 を~overflowしている子孫は、 この計算【 %要素~矩形 】には影響しない — 影響するものは %要素【！%el】 の`~margin~box$に限られる。 ◎ Note: Descendants overflowing el don’t affect this calculation, only el’s own margin box.
注記： この~algoは，現在~効果がある`位置~option$【`最後の成功裡な位置~option$】を ある目的で飛ばすので、 それ用に`記憶した~scroll~offset$は更新されない — 他の~fallback【 %~option 】には働くものが無く， %現在の~style群 を貫き続ける場合、 `記憶した~scroll~offset$は，すべて同じであり続ける。 ◎ Note: Because we purposely skip the position option currently in effect, it doesn’t get its remembered scroll offsets updated; if none of the other fallbacks work and we stick with the current styles, all the remembered scroll offsets stay the same.
全部的な~layoutを経る間に， ある~boxの~fallback~styleを決定したなら （あるいは、 それを利用しないものと決定したなら）、 この裁定は，~~後続の~boxを~lay-outする際に変更されることはない。 ◎ During a full layout pass, once a box has determined its fallback styles (or determined it’s not using any), laying out later boxes cannot change this decision.
例えば、 2 個の有位置な~box %A, %B があって， %A は %B より前に~lay-outされるとする。 %B が~overflowして， %A の包含塊に~scrollbarを生じさせる結果になったとしても、 %A を~overflowさせない試みを やり直して， %A の~fallback~styleを決定し直す`ことはない^em。 （さもなければ、 ~~最善でも，~layoutの~costは指数関数的になり、 ~~最悪，循環依存になり，~layoutは決して決着しなくなる。） ◎ For example, say you have two positioned boxes, A and B, with A laid out before B. If B overflows and causes A’s containing block to gain scrollbars, this does not cause A to go back and re-determine its fallback styles in an attempt to avoid overflowing. (At best, this can result in exponential layout costs; at worst, it’s cyclic and will never settle.)
言い換えれば、 ~layoutは “後戻りしない” 。 ◎ Layout does not "go backward", in other words.
`ResizeObserver$I ~eventが決定され, 送達された時点で 【当の `ResizeObserver^I が観測している ~EACH( `作動中な~target＠~CSSWG/resize-observer-1/#dom-resizeobserver-activetargets-slot$が表現する要素 %要素 ) に対し，次を遂行するとする】： ◎ At the time that ResizeObserver events are determined and delivered:
-
~IF［ %要素 の`最後の成功裡な位置~option$ ~NEQ ε ］~AND［ ~OR↓ ］… ◎ If el has a last successful position option＼ ↓ remove its last successful position option＼ if any of the following are true:
- %要素 の `position$p の算出d値が変化した ◎ Its computed position value has changed,＼
- %要素 の`包含塊$~associationが変化した ◎ its containing block association has changed,＼
- %要素 は~boxを生成しなくなった ◎ or it no longer generates a box.
- %要素 の `position-try$p のいずれかの`下位prop$の算出d値が変化した ◎ Its computed value for any longhand of position-try has changed.
- %要素 の［ `position-try^at に`受容される~prop$ ］のうち いずれかの算出d値が変化した ◎ Its computed value for any accepted @position-try property has changed.
- %要素 【の `position-try-fallbacks$p 】により参照される `position-try$at 規則として［ 追加された／除去された／変異した ］ものがある ◎ Any of the @position-try rules referenced by it have been added, removed, or mutated.
…ならば： ◎ ↑
- %要素 の`最後の成功裡な位置~option$ ~SET ε ◎ ↑
- %要素 用の`位置~fallback~style群を決定する$() ◎ Then, determine position fallback styles for el＼
- %要素 の`最後の成功裡な位置~option$ ~SET 現在~利用している`受容される~prop$（および, その値）たちが成す集合 ◎ and set its last successful position option to the set of accepted @position-try properties (and values) that it’s now using.
- ~ELIF［ %要素 【！box el】は`絶対的に位置され$ている ］ ⇒ %要素 の`最後の成功裡な位置~option$ ~SET 現在~利用している`受容される~prop$（および, その値）たちが成す集合 ◎ Otherwise, if a box el is absolutely positioned, set its last successful position option to the set of accepted @position-try properties (and values) that it’s currently using.
注記： この【最後の成功裡な位置~optionを】［ 記録する／除去する ］時機は、 意図的に，`最後に記憶した~size$の扱いと一致するようにしてある。 ◎ Note: The timing of this recording/removal is intentionally identical to the treatment of last remembered sizes.
実装は、［ ~layout作業に要求され得る量が過度なとき，それを制限する ］ためとして，［ `位置~option~list$の長さに対し，実装定義な上限を課す ］ことを選んでもヨイ。 この上限は、 5 `以上^emにするモノトスル。 ◎ Implementations may choose to impose an implementation-defined limit on the length of position options lists, to limit the amount of excess layout work that may be required. This limit must be at least five.
例えば，次の~CSSは、 ある “~popover”† を，まずは［ ~buttonの下に位置させ, 左端と~buttonの左端を整列する ］ようと試みるが、 ~screenに収まらない場合には，順に［ 上, 左端 ］, ［ 下, 右端 ］, ［ 上, 右端 ］を試みるよう切替えることになる。 【† 何らかの動作（この例では、~button上の~hoverなど）に呼応して，他のものの上層に表示される様な~UI。】 ◎ For example, the following CSS will first attempt to position a "popover" below the element, but if it doesn’t fit on-screen will switch to being above; it defaults to left-aligning, but will switch to right-aligning if that doesn’t fit.
#myPopover {
position: fixed;
top: anchor(--button bottom);
left: anchor(--button left);
position-try-fallbacks: flip-inline, flip-block, flip-block flip-inline;
/*
~popoverの横幅を~buttonの横幅~以上にする
◎
The popover is at least as wide as the button
*/
min-width: anchor-size(--button width);
/*
~popoverの縦幅を［
~menu~item 2 個分
］以上にする
◎
The popover is at least as tall as 2 menu items
*/
min-height: 6em;
}
6.6. 条件付きで隠す： `position-visibility^p ~prop
`絶対的に位置され$た~boxは、 条件によっては，表示してもイミを成さないかもしれない。 この~propは、 そのような~boxが条件付きで — 何らかの共通的に必要になる~layout条件に依存して — 可視になることを許容する。 ◎ There are some conditions in which it might not make sense to display an absolutely positioned box. This property allows such boxes to be made conditionally visible, depending on some commonly needed layout conditions.
- `always@v
- この~propによる効果は無い （当の~boxは、［ その~anchor先／自身が~overflowするか否か ］を問わず，表示される）。 ◎ This property has no effect. (The box is displayed without regard for its anchors or its overflowing status.)
- `anchors-valid@v
- 次が満たされるならば、 当の~boxの `visibility$p ~propは `force-hidden$v に算出される ⇒ 当の~boxに`要求される~anchor参照$のうち いずれかが`~target~anchor要素$に解決されない ◎ If any of the box’s required anchor references do not resolve to a target anchor element, the box’s visibility property computes to force-hidden.
- `要求される~anchor参照@ とは何か： `anchor$f 関数のうち~fallback値を伴わないものか？ 既定の~anchorも ときには該当するのか？ ここには、 もっと詳細が必要である。 ◎ What is a required anchor reference? anchor() functions that don’t have a fallback value; the default anchor *sometimes*? Need more detail here.
- † “いずれか” に代えて “すべて” とするか？ どちらにも利用事例があり得る。 どちらにするか裁定を為すよう求まれるのか？ あるいは，どうにかそれを制御-可能にするか？ ◎ Any anchors are missing, or all anchors are missing? I can see use-cases for either, potentially. Do we want to make a decision here, or make it controllable somehow?
- `anchors-visible@v
- 次が満たされるならば、 当の~boxの `visibility$p ~propは `force-hidden$v に算出される ⇒ 当の~boxの`既定の~anchor~box$ %~anchor は次を満たす ⇒ ［ %~anchor ~NEQ ε ］~AND［［ %~anchor は`不可視な~box$である ］~OR［ %~anchor は`介在している~boxにより切取られて$いる ］］ ◎ If the box has a default anchor box but that anchor box is invisible or clipped by intervening boxes, the box’s visibility property computes to force-hidden.
- `no-overflow@v
- 次が満たされるならば、 当の~boxの `visibility$p ~propは `force-hidden$v に算出される ⇒ 当の~boxは、 `position-try$p を適用した後においても， 自身の`~insetで改変された包含塊$を~overflowする ◎ If the box overflows its inset-modified containing block even after applying position-try, the box’s visibility property computes to force-hidden.
`~anchor~box$ %~anchor が， それに依拠している`絶対的に位置され$た【！有位置な】~box %~box に相対的に `介在している~boxにより切取られて@ いるとは、 ~AND↓ を満たす~box %先祖 が在ることをいう： ◎ An anchor box anchor is clipped by intervening boxes relative to a positioned box abspos relying on it if＼
【 “依拠している” とは、［ %~box の`~target~anchor要素$の`首要~box$ ~EQ %~anchor ］か［ %~box の`既定の~anchor~box$ ~EQ %~anchor ］のどちらを意味するのか，はっきりしない。 】
- %先祖 は %~anchor の先祖である
- %先祖 は %~box の`包含塊$【を確立した~box】の子孫である
-
%~anchor の`~ink~overflow矩形$は %先祖 により全部的に切取られている
この事例における “切取られている” は、［ `overflow$p その他（`塗り封込め$など）による`~overflow切取n辺$で切取る効果 ］に因るものに限られる。
%~anchor が`介在している~boxにより切取られて$いるか否かは、 `ResizeObserver$I を誘発する直前に決定される。 ◎ Whether or not anchor is clipped by intervening boxes is determined immediately prior to triggering ResizeObservers.
可視性~検査の時機を定義する。 `12732$issue ◎ Define timing of visibility checks. [Issue #12732]
この “切取られている” の定義は、 `~view遷移＠~CSSVT$cite と整合する必要がある — それにも、 類似な概念が求まれる。 ◎ Make sure this definition of clipped is consistent with View Transitions, which wants a similar concept.
注記： これは、 “~anchorが連鎖する” 状況 — ある`絶対的に位置され$た~box %A の~anchor先は別のそれ %B であり， %B にも~anchor先 %C がある状況 — において， %B が（ %C が~scrollされて外へ出たことに因り）この~propに因り隠された場合には、 %A も — 見当外れな所在に浮動させることなく — 隠されるようになることを確保する。 ◎ Note: This ensures that in a “chained anchor” situation, if the first abspos is hidden due to this property (due to its anchor being scrolled off), then another abspos using it as an anchor will also be hidden, rather than also floating in a nonsensical location.
7. ~accessibilityに関する含意
`~anchor位置決め^cite は［ 有位置な~box, その~anchor先 ］の間に［ 意味論上の関係性を自動的に確立するもの ］ではないことに~~留意すること — それは、 多くの異なる仕方で利用されるので。 作者は、 要素どうしを意味論的に一緒に~linkする際に，もっぱら［ 位置決めにより含意される`視覚的^emな接続 ］に依拠してはナラナイ — ~DOMにおける要素どうしの有意義な関係性は， 追加的な助けを伴わずには`得られない^emことが多いので、 それらを~screen~readerの様な視覚的でない~UAにおいて利用することは， 困難になるかアリでなくなる。 ◎ It’s important to remember that Anchor Positioning does not automatically establish any semantic relationship between a positioned box and any of its anchors, because it can be used in many different ways. Authors must not rely solely on a visual connection implied by the positioning to link elements together semantically; without additional help, the elements often have no meaningful DOM relationship, making them difficult or impossible to use in non-visual user agents, like screen readers.
~web~platformの多くの［ 既存の／来たる ］特能は、 そのような接続を［ 視覚的でない~UAでも便益を得られるよう，明示的に確立する ］ことを許容する。 ◎ Many features on the web platform, both existing and upcoming, allow establishing such connections explicitly, so that non-visual user agents can also benefit.
例えば，~HTMLにおける`~popover~API＠~HTMLpopoverl#the-popover-attribute$は、 誘発元【！invoker】~buttonを`~popover要素$へ自動的に~linkする — ~UItab~UIkeyで巡回する順序を自動的に調整することも含めて。 `それはまた^em、 誘発元【！invoker】~buttonを［ 当の~popover用の`暗黙的な~anchor要素$として確立する ］ことにより， `~anchor位置決め^cite にも利用することを容易にする。 ◎ For example, the Popover API in HTML automatically links the invoker button to the popover element, including automatically adjusting tabbing order; it also establishes the invoker button as the implicit anchor element for the popover, making it easy to use Anchor Positioning as well.
~popoverの例を追加する。 ◎ Add a popover example.
より一般な事例においては、 ~anchor要素の［ `aria-details＠~ARIA1#aria-details$a, `aria-describedby＠~ARIA1#aria-describedby$a ］属性などの~ARIA特能が，この情報【関係性】を — 有位置な要素の `role＠~ARIA1#host_general_role$a 属性との~~協同で，少し手動な流儀で — 供せる。 それにより、 視覚的でない~UAは，［ それらの要素どうしの関係性について利用者に伝えれる ］ようになり［ それらの要素~間で自動的に~navigateできる ］ようになる。 ◎ In more general cases, ARIA features such as the aria-details or aria-describedby attributes on an anchor element can provide this information in a slightly more manual fashion; in concert with the role attribute on the positioned element, non-visual user agents can tell their users about the relationship between the elements and let them automatically navigate between them.
8. ~DOM~interface
8.1. `CSSPositionTryRule^I ~interface
`CSSPositionTryRule$I ~interfaceは、 `position-try$at 規則を表現する： ◎ The CSSPositionTryRule interface represents the @position-try rule:
[`Exposed$=Window]
interface `CSSPositionTryRule@I : `CSSRule$I {
readonly attribute `CSSOMString$ `name$m;
[`SameObject$, `PutForwards$=`cssText$m] readonly attribute `CSSPositionTryDescriptors$I `style$m;
};
[`Exposed$=Window]
interface `CSSPositionTryDescriptors@I : `CSSStyleDeclaration$I {
attribute `CSSOMString$ `margin@ptD;
attribute `CSSOMString$ `marginTop@ptD;
attribute `CSSOMString$ `marginRight@ptD;
attribute `CSSOMString$ `marginBottom@ptD;
attribute `CSSOMString$ `marginLeft@ptD;
attribute `CSSOMString$ `marginBlock@ptD;
attribute `CSSOMString$ `marginBlockStart@ptD;
attribute `CSSOMString$ `marginBlockEnd@ptD;
attribute `CSSOMString$ `marginInline@ptD;
attribute `CSSOMString$ `marginInlineStart@ptD;
attribute `CSSOMString$ `marginInlineEnd@ptD;
attribute `CSSOMString$ `margin-top@ptD;
attribute `CSSOMString$ `margin-right@ptD;
attribute `CSSOMString$ `margin-bottom@ptD;
attribute `CSSOMString$ `margin-left@ptD;
attribute `CSSOMString$ `margin-block@ptD;
attribute `CSSOMString$ `margin-block-start@ptD;
attribute `CSSOMString$ `margin-block-end@ptD;
attribute `CSSOMString$ `margin-inline@ptD;
attribute `CSSOMString$ `margin-inline-start@ptD;
attribute `CSSOMString$ `margin-inline-end@ptD;
attribute `CSSOMString$ `inset@ptD;
attribute `CSSOMString$ `insetBlock@ptD;
attribute `CSSOMString$ `insetBlockStart@ptD;
attribute `CSSOMString$ `insetBlockEnd@ptD;
attribute `CSSOMString$ `insetInline@ptD;
attribute `CSSOMString$ `insetInlineStart@ptD;
attribute `CSSOMString$ `insetInlineEnd@ptD;
attribute `CSSOMString$ `top@ptD;
attribute `CSSOMString$ `left@ptD;
attribute `CSSOMString$ `right@ptD;
attribute `CSSOMString$ `bottom@ptD;
attribute `CSSOMString$ `inset-block@ptD;
attribute `CSSOMString$ `inset-block-start@ptD;
attribute `CSSOMString$ `inset-block-end@ptD;
attribute `CSSOMString$ `inset-inline@ptD;
attribute `CSSOMString$ `inset-inline-start@ptD;
attribute `CSSOMString$ `inset-inline-end@ptD;
attribute `CSSOMString$ `width@ptD;
attribute `CSSOMString$ `minWidth@ptD;
attribute `CSSOMString$ `maxWidth@ptD;
attribute `CSSOMString$ `height@ptD;
attribute `CSSOMString$ `minHeight@ptD;
attribute `CSSOMString$ `maxHeight@ptD;
attribute `CSSOMString$ `blockSize@ptD;
attribute `CSSOMString$ `minBlockSize@ptD;
attribute `CSSOMString$ `maxBlockSize@ptD;
attribute `CSSOMString$ `inlineSize@ptD;
attribute `CSSOMString$ `minInlineSize@ptD;
attribute `CSSOMString$ `maxInlineSize@ptD;
attribute `CSSOMString$ `min-width@ptD;
attribute `CSSOMString$ `max-width@ptD;
attribute `CSSOMString$ `min-height@ptD;
attribute `CSSOMString$ `max-height@ptD;
attribute `CSSOMString$ `block-size@ptD;
attribute `CSSOMString$ `min-block-size@ptD;
attribute `CSSOMString$ `max-block-size@ptD;
attribute `CSSOMString$ `inline-size@ptD;
attribute `CSSOMString$ `min-inline-size@ptD;
attribute `CSSOMString$ `max-inline-size@ptD;
attribute `CSSOMString$ `placeSelf@ptD;
attribute `CSSOMString$ `alignSelf@ptD;
attribute `CSSOMString$ `justifySelf@ptD;
attribute `CSSOMString$ `place-self@ptD;
attribute `CSSOMString$ `align-self@ptD;
attribute `CSSOMString$ `justify-self@ptD;
attribute `CSSOMString$ `positionAnchor@ptD;
attribute `CSSOMString$ `position-anchor@ptD;
attribute `CSSOMString$ `positionArea@ptD;
attribute `CSSOMString$ `position-area@ptD;
};
`name@m 属性は、 当の~at-規則の導入部にて宣言された名前を表現する。 ◎ Its name attribute represents the name declared in the rule’s prelude.
`style@m 属性は、 当の~at-規則の本体~内で宣言された~propたちを指定された順序で表現する。 ◎ Its style attribute represents the properties declared in the rule’s body, in the specified order.＼
その取得子~手続きは ⇒ ~RET コレが表現する `position-try$at ~at-規則~用の［ 次を伴う`~CSS宣言~block$ ］を表現する `CSSPositionTryDescriptors$I ~obj ⇒＃ `算出-済みか$dB ~SET ~F, `読専か$dB ~SET ~F, `宣言~群$dB ~SET 当の規則の中で宣言された記述子たちが成す`指定d順序$による~list, `親~CSS規則$dB ~SET コレ, `所有者~node$dB ~SET ~NULL ◎ On getting, it must return a CSSPositionTryDescriptors object for the @position-try at-rule, with the following properties: computed flag • Unset readonly flag • Unset declarations • The declared descriptors in the rule, in specified order. parent CSS rule • The context object owner node • Null
~styleと~layoutの差挟み
`~styleと~layoutの差挟み@ は、 ~layout処理nの間に下位tree上で~style更新が生じ得るようにして， 要素の`算出d値$を遡及的に更新するための技法である。 ◎ Style & layout interleaving is a technique where a style update can occur on a subtree during the layout process, resulting in retroactive updates to elements’ computed styles.
この概念は、 この仕様ではなく，おそらく `CSS-CASCADE-5$r にて定義されるべきだが、 その素描を参照rするために，ここにある。 ◎ This is not the correct spec for this concept, it should probably go in Cascade, but I need a sketch of it to refer to.
注記： `~styleと~layoutの差挟み$は、 すでに［ `容器~query$, `容器~query長さ単位$ ］で利用されている。 `10cqw^v の様な長さは、 `~query容器$の~sizeについての~layout情報を利用して`算出d長さ$へ解決される — したがって、 ~layoutが変化するに伴い当の容器の~sizeが変化するとき，`遷移＠~TRANSITION$を誘発し得る。 ◎ Note: Style & layout interleaving is already used with container queries and container query lengths. A length like 10cqw is resolved into a computed length using layout information about the query container’s size, which can thus trigger transitions when the container changes size between layouts.
`position-try$at に`受容される~prop$も，~fallbackを解決するときに差挟まれる （ `position-try$p を見よ）。 ◎ The accepted @position-try properties are also interleaved when resolving fallback (see position-try).
これは，明らかに もっと詳細を詰める必要があるが、 今の所は， “容器~query用にすでに行われている様に動作する” ことで足りる。 その挙動も未定義だが、 少なくとも，その挙動と（ある程度までは？）相互運用可能である。 ◎ Obviously this needs way more details filled in, but for now "act like you already do for container queries" suffices. That behavior is also undefined, but at least it’s interoperable (to some extent?).
~securityの考慮点
この文書に対し提起された~securityの課題は無い。 ◎ No Security issues have been raised against this document.
~privacyの考慮点
この文書に対し提起された~privacyの課題は無い。 ◎ No Privacy issues have been raised against this document.
変更点
- `2025年 5月 9日 作業草案＠~TR/2025/WD-css-anchor-position-1-20250509/$ からの有意な変更点 ◎ Significant changes since the 9 May October 2025 Working Draft:
- `position-area$p 用の~keyword `x/y-self-start/end^v を `self-x/y-start/end^v に改称した — 順序付けが【 `self-inline-start^v 等々と一貫でないことにより】紛らわしかったので。 （ `12749$issue） ◎ Rename x/y-self-start/end keywords to self-x/y-start/end for position-area due to persistent confusion about the ordering. (Issue 12749)
- `position-area$p は、 当の~boxの`包含塊$が`~scroll容器$であるときは， （新たに定義された）`~scroll可能な包含塊$を利用するようにした。 （ `10861$issue ） ◎ Make position-area use the (newly defined) scrollable containing block when the box’s containing block is a scroll container. (Issue 10861)
- `~inset~prop$【！#propdef-inset】のうち片方だけ `auto$v をとる場合、 既定の `position-area$p 整列は，もう片方の側に整列するようにした。 （ `12512$issue ） ◎ Make default position-area alignment for single-auto inset axes align to the non-auto side. (Issue 12512)
- 変形は`~anchor~box$の幾何に影響するようにした。 （ `8584$issue ） ◎ Make transforms affect the anchor box geometry. (Issue 8584)
- ［ `align-self$p, `justify-self$p ］用の値として `dialog$vS を追加した — ~HTML~popover用の既定の~UA~stylesheet規則における~~不具合を解くため。 （ `10258$issue ） ◎ Add the dialog value to align-self and justify-self to solve regrettable default UA stylesheet rules for HTML popovers. (Issue 10258)
- 断片化が`~anchor~box$の幾何に どう影響するかを明確化した。 （ `12287$issue ） ◎ Clarify how fragmentation affects the anchor box geometry. (Issue 12287)
- `最後の成功裡な位置~option$が~clearされることを明確化した。 （ `12577$issue ） ◎ Clarify whe the last successful position option is cleared. (Issue 12577)
- ~anchor名が`~tree視野な名前$として［ `anchor-scope$p `vs^en `position-anchor$p ］用に どう照合されるかを明確化した。 （ `7916$issue, `9408$issue, `5984$issue ） ◎ Clarify how tree-scoped names anchor are matched for anchor-scope vs position-anchor. (Issues 7916, 9408, and 5984)
- 上端~層と［ `受容-可能な~anchor要素$の見出法 ］が どう相互作用するかを明確化した。 妥当な~anchor用の規則をもっと理解し易くなるよう書き直した。 （ `11602$issue ） ◎ Clarify how top layer interacts with finding the acceptable anchor element and rewrite the rules for valid anchors to be easier to understand. (Issue 11602)
- `position-try-fallbacks$p の文法を=~listから~keyword `none$vI を除外するよう修正した。 （ `12838$issue ） ◎ Fix grammar of position-try-fallbacks to exclude lists of none keywords. (Issue 12838)
- 様々な細かな修正sと明確化。 （ `11028$issue, `11080$issue, `12058$issue, `12636$issue, `12653$issue, `12732$issue ） ◎ Various small fixes and clarifications. (Issue 11028, Issue 11080, Issue 12058, Issue 12636, Issue 12653, Issue 12732)
`以前の変更点＠~TR/2025/WD-css-anchor-position-1-20250509/#changes$も見よ。 ◎ See also Previous Changes.