Skip to content

Commit b11e256

Browse files
committed
[css-anchor-position][editorial] Switch a few of the examples to explicitly use logical props. w3c#8727
1 parent 9657173 commit b11e256

File tree

1 file changed

+12
-16
lines changed

1 file changed

+12
-16
lines changed

css-anchor-position-1/Overview.bs

+12-16
Original file line numberDiff line numberDiff line change
@@ -916,19 +916,19 @@ as if by an additional ''translate()'' transform.
916916

917917
<div class=example>
918918
For example,
919-
in ''.bar { top: anchor(--foo top); }'',
919+
in ''.bar { inset-block-start: anchor(--foo block-start); }'',
920920
the ''anchor()'' will resolve to the length
921-
that'll line up the <code>.bar</code> element's top edge
922-
with the ''--foo'' anchor's top edge.
921+
that'll line up the <code>.bar</code> element's block-start edge
922+
with the ''--foo'' anchor's block-start edge.
923923

924924
On the other hand,
925-
in ''.bar { bottom: anchor(--foo top); }'',
925+
in ''.bar { inset-block-end: anchor(--foo block-start); }'',
926926
it will instead resolve to the length
927-
that'll line up the <code>.bar</code> element's <em>bottom</em> edge
928-
with the ''--foo'' anchor's top edge.
927+
that'll line up the <code>.bar</code> element's <em>block-end</em> edge
928+
with the ''--foo'' anchor's block-start edge.
929929

930-
Since 'top' and 'bottom' values specify insets from different edges
931-
(the top and bottom of the element's [=containing block=],
930+
Since 'inset-block-start' and 'inset-block-end' values specify insets from different edges
931+
(the block-start and block-end of the element's [=containing block=],
932932
respectively),
933933
the same ''anchor()'' will usually resolve to different lengths in each.
934934
</div>
@@ -1716,8 +1716,7 @@ the [=position options list=] will be tried.
17161716
.list {
17171717
position: fixed;
17181718
position-anchor: --foo;
1719-
top: anchor(bottom);
1720-
left: anchor(left);
1719+
position-area: block-end span-inline-end;
17211720
align-self: start;
17221721
position-try-fallbacks: --bottom-scrollable, flip-block, --top-scrollable;
17231722
position-try-order: most-height;
@@ -1726,18 +1725,15 @@ the [=position options list=] will be tried.
17261725
align-self: stretch;
17271726
}
17281727
@position-try --top-scrollable {
1729-
top: 0;
1730-
bottom: anchor(top);
1728+
position-area: block-start span-inline-end;
17311729
align-self: stretch;
17321730
}
17331731
</pre>
17341732

17351733
The ''flip-block'' auto-generated option and the ''--top-scrollable'' option
17361734
will always find the same available height,
1737-
since both of them stretch vertically from ''top: 0''
1738-
(the top edge of the viewport)
1739-
to ''bottom: anchor(top)''
1740-
(the top of the anchor),
1735+
since both of them stretch vertically from the top edge of the containing block
1736+
to the top of the anchor,
17411737
so they'll retain their specified order.
17421738
This causes the element to first try to align against the anchor
17431739
at its natural height

0 commit comments

Comments
 (0)