1. 序論
これは、 `~level 3$ に対する差分~仕様であり、 現時点では探求段階の作業草案である: この仕様の何かを実装しているなら、 ~level 3 を参照として利用されたし。 ~level 3 が勧告候補に達したなら、 その~textは,この草案の中へ併合されることになる。 ◎ This is a diff spec over CSS Sizing Level 3. It is currently an Exploratory Working Draft: if you are implementing anything, please use Level 3 as a reference. We will merge the Level 3 text into this draft once it reaches CR.
1.1. ~module間の相互作用
この~moduleは、 `CSS2$r § 10 / `CSS3COL$r にて定義された,次に挙げる特能を拡張する ⇒# `width$p, `height$p, `min-width$p, `min-height$p, `max-width$p, `max-height$p, `column-width$p ◎ This module extends the width, height, min-width, min-height, max-width, max-height, and column-width features defined in [CSS2] chapter 10 and in [CSS3COL]
1.2. 値~定義
【 この節の内容は `~CSS日本語訳 共通~page@~CSScommon#values$に移譲。 】
2. 各種用語
`~level 3$ `§ 各種用語@~SIZING#terms$ を統合する。 ◎ CSS Sizing 3 § 2 Terminology
3. ~box~sizeの指定-法
`~level 3$ `§ ~box~sizeの指定-法@~SIZING#specifying-sizes$ を統合する。 ◎ CSS Sizing 3 § 3 Specifying Box Sizes
3.1. 各種~sizing~prop
`~level 3$ `§ 各種~sizing~prop@~SIZING#sizing-properties$ を統合する。 ◎ CSS Sizing 3 § 3.1 Sizing Properties
`size$p ~propは、[ `width$p, `height$p ]を単独の宣言で設定する`略式~prop$である。 2 個目の値が省略された場合、 1 個目の値から複製される。 ◎ The size property is a shorthand that sets width and height in a single declaration. If the second value is omitted, it is copied from the first.
`size$p 略式~propは、 `page$at 文脈においては利用できない — `page^at には、 すでに無関係な `size$d 記述子が,~page~sizeの設定~用に有るので。 ◎ The size shorthand cannot be used in @page contexts, as @page already has an unrelated size descriptor for setting the page size.
`size$p ~propは、 互換性の問題と`page$at との競合を避けるため, `選好される略式~propの順序$ `CSSOM-1$r からは省略される必要がある。 ◎ The size property needs to be omitted from the preferred shorthand order in CSSOM, to avoid compat problems and conflicts with @page.
`min-size$p ~propは、[ `min-width$p, `min-height$p ]を単独の宣言で設定する`略式~prop$である。 2 個目の値が省略された場合、 1 個目の値から複製される。 ◎ The min-size property is a shorthand that sets min-width and min-height in a single declaration. If the second value is omitted, it is copied from the first.
`max-size$p ~propは、[ `max-width$p, `max-height$p ]を単独の宣言で設定する`略式~prop$である。 2 個目の値が省略された場合、 1 個目の値から複製される。 ◎ The max-size property is a shorthand that sets max-width and max-height in a single declaration. If the second value is omitted, it is copied from the first.
3.2. 新たな~sizing値: `contain^v, `stretch^f, `fit-content^f, `calc-size^f
`~level 3$ `§ ~sizingを与える値@~SIZING#sizing-values$ を統合する。 ◎ Integrate CSS Sizing 3 § 3.2 Sizing Values: the <length-percentage>, auto | none, stretch, min-content, max-content, and fit-content values
~level 4 は、 `~sizing~prop$において[ `contain$v, `fit-content$f, `calc-size$f ]を利用する能を追加する — したがって、 `box-size$t 生成規則を次のとおり拡げる: ◎ Level 4 adds the ability to use the contain, fit-content(), and calc-size() values in the sizing properties, thus expanding the <box-size> production as follows:
`box-size@t = `length-percentage$t | `stretch$v | `contain$v | `min-content$v | `max-content$v | `fit-content$v | `stretch()$t | `fit-content()$t | `calc-size()$t
- `stretch()@t = stretch(`length-percentage [0,∞]$t)
-
`~margin~box$が引数により指定された~sizeに収まるようにする。 この目的においては、 `auto^v `~margin$を 0 として扱うことに加え,~marginを[ 抑止する/切落とす ]効果 — `~margin相殺$, `margin-trim$p, その他 — を無視する。 ◎ Fit the margin box to the size specified by the argument. For this purpose, treat auto margins as zero, and ignore margin collapsing, margin-trim, and other effects that suppress or truncate the margin.
注記: この~sizeを計算する目的においては,~margin相殺, 等々は無視されるが、 それらの効果は,他においては抑止されることなく通例通り適用される。 ◎ Note: Although margin collapsing, etc. are ignored for the purpose of calculating this size, their effects are not otherwise suppressed, and apply as usual.
- 引数 `length-percentage$t は、 この値に代えて引数~自体が指定されたときと正確に同じに解決される。 ◎ The <length-percentage> argument is resolved exactly as for <length-percentage> values standing alone.
- ここでの~open論点に関する詳細は、 `5715$issue にある。 ◎ Open discussion wrt details here. [Issue #5715]
- `fit-content()@t = fit-content(`length-percentage [0,∞]$t)
- `fit-content$v 用の公式を[ `可用な空間$を指定する引数【すなわち, `stretch$v 】 ]を `stretch$f に置換した上で利用する。 すなわち,次の結果になる ⇒ `min^op( `max-content$v, `max^op( `min-content$v, `stretch( 指定された引数 )^v ) ◎ Use the fit-content formula with the available space replaced by stretch() into the specified argument, i.e. min(max-content, max(min-content, stretch(<length-percentage>)).
- `contain@v
-
当の~boxに`選好d縦横比$が: ◎ ↓
- 有る場合 ⇒ `§ 包含して収まる~sizing@#contain-fit-sizing$ を適用して,アリな限り~boxの`選好d縦横比$を保守しながら~boxの拘束に収まるよう試みる。 ◎ If the box has a preferred aspect ratio, applies contain-fit sizing, attempting to fit into the box’s constraints while maintaining its preferred aspect ratio insofar as possible. See § 6.1 Contain-fit Sizing: stretching while maintaining an aspect ratio.
- 無い場合 ⇒ `伸張して収まる~size$を適用する。 ◎ If the box has no preferred aspect ratio, applies stretch-fit sizing.
- `calc-size()$t
- `§ 内在的~sizeを伴う計算-法@#calc-size$ を見よ。 ◎ See § 7 Calculating With Intrinsic Sizes: the calc-size() function.
- 注記: `calc-size$f の中では、 ~keyword `none$v は利用-可能でない。 ◎ Note: The none keyword is not usable within calc-size().
注記: これらの新たな値は、 `calc-size$f の定義が “当の文脈において許容される” ものとして参照rする値たちが成す集合【すなわち, `size-keyword$t 】に追加される。 ◎ Note: These new values add to the set of values that the definition of <calc-size()> refers to as “allowed in the context”.
4. 縦横比
画像は`生来な縦横比$を有することが多い — ~CSS~layout~algoは、 要素を~sizeし直すとき,それを保全するようと試みる。 ◎ Images often have a natural aspect ratio, which the CSS layout algorithms attempt to preserve as they resize the element.
`aspect-ratio$p ~propは、 次を許容する ⇒# `置換され$ない要素に対し,この挙動を指定する/ `置換され$る要素に対し,実質的な縦横比を改める ◎ The aspect-ratio property allows specifying this behavior for non-replaced elements, and for altering the effective aspect ratio of replaced elements.
この節の詳細は、 依然として作業-中にある。 `選好d縦横比$を伴う`置換され$る要素 ]に対し,ここに指定される挙動が[ `~flow~layout$ `CSS2$r, `~flex~layout$ `CSS-FLEXBOX-2$r, `格子~layout$ `CSS-GRID-2$r ]仕様を組合せた要件による挙動と(この仕様による効果を伴わない下で)異なるならば、 それは誤りであり, ~CSS~WGに`報告される@https://github.com/w3c/csswg-drafts/issues$べきである。 `aspect-ratio^p に関する`~open課題たちが成す~list@https://github.com/w3c/csswg-drafts/issues?q=is%3Aissue%20state%3Aopen%20label%3Acss-sizing-4%20aspect-ratio%20label%3A%22Needs%20Edits%22$もある。 ◎ We are still working through the details of this section. If there is any behavior specified here that would cause replaced elements with a preferred aspect ratio to behave differently than they would under the requirements of the CSS2, Flex Layout, and Grid Layout specs combined (without this specification in effect), this is an error and should be reported to the CSSWG. There is a list of open aspect-ratio issues.
4.1. 選好d縦横比: `aspect-ratio^p ~prop
この~propは、 ~boxの `選好d縦横比@ を設定する。 それは、 `auto$v ~sizeの計算や一部の~layout関数に利用されることになる。 ◎ This property sets a preferred aspect ratio for the box, which will be used in the calculation of auto sizes and some other layout functions.
- `auto@v1
- `生来な縦横比$を伴う`置換され$る要素は、 その縦横比を【~boxの`選好d縦横比$に】利用する。 他の場合、 ~boxの`選好d縦横比$は無い。 この縦横比を孕んでいる~size計算は、 常に`内容~box$の寸法とともに働く~FN。 ◎ Replaced elements with a natural aspect ratio use that aspect ratio; otherwise the box has no preferred aspect ratio. Size calculations involving the aspect ratio work with the content box dimensions always.
- 【~FN `box-sizing$p に `border-box@~CSSBOX#valdef-box-border-box$v が指定された場合でも、 `~border~box$ではなく`内容~box$の縦横比として扱われることになる。 】
- `ratio$t
- ~boxの`選好d縦横比$は、 指定された比率(横幅 ~DIV 縦幅)になる。 この縦横比を孕んでいる~size計算は、 常に, `box-sizing$p が指定する~boxの寸法とともに働く。 ◎ The box’s preferred aspect ratio is the specified ratio of width / height. Size calculations involving the aspect ratio work with the dimensions of the box specified by box-sizing.
- `ratio$t は`退化な比率$である場合、 この~propは,代わりに `auto$v1 として挙動する。 ◎ If the <ratio> is degenerate, the property instead behaves as auto.
- `auto$v1 && `ratio$t
- `auto$v1 と `ratio$t が一緒に指定された場合, `選好d縦横比$は,指定された比率(横幅 ~DIV 縦幅)になるが、 `置換され$る要素である事例では,その`生来な縦横比$が代わりに利用される。 いずれの事例でも,当の縦横比を孕んでいる~size計算は、 常に,`内容~box$の寸法とともに働く。 ◎ If both auto and a <ratio> are specified together, the preferred aspect ratio is the specified ratio of width / height unless it is a replaced element with a natural aspect ratio, in which case that aspect ratio is used instead. In all cases, size calculations involving the aspect ratio work with the content box dimensions always.
- `ratio$t は`退化な比率$である場合、 この~propは,代わりに `auto$v1 として挙動する。 ◎ If the <ratio> is degenerate, the property instead behaves as auto.
注記: `選好d縦横比$を伴わせることは、 ~boxを`置換され$る要素にするものではない。 `置換され$る要素に特有な~layout規則は、 一般に,`選好d縦横比$を伴う~boxには適用されない。 例えば,`置換され$ない, かつ`絶対的に位置され$た~boxは、 `選好d縦横比$を伴う場合でも, `justify-self$p に指定された `normal^v を `start@~CSSALIGN#valdef-self-position-start$v ではなく `stretch@~CSSALIGN#valdef-justify-self-stretch$v として扱う ( `CSS-ALIGN-3$r `§ 絶対的に位置された~box@~CSSALIGN#justify-abspos$ )。 ◎ Note: Having a preferred aspect ratio does not make a box into a replaced element; layout rules specific to replaced elements do not generally apply to non-replaced boxes with a preferred aspect ratio. For example, a non-replaced absolutely-positioned box treats justify-self: normal as stretch, not as start (CSS Box Alignment 3 § 6.1.2 Absolutely-Positioned Boxes), even if it has a preferred aspect ratio
`CSS2$r は、[ 置換される要素と縦横比を伴う要素 ]を明瞭に相違~化していなかった。 不明瞭な特定の事例を — `~level 3$ 仕様か ここか,適切な方で — 洗い出して,定義する必要がある。 ◎ CSS2.1 does not cleanly differentiate between replaced elements vs. elements with an aspect ratio; need to figure out specific cases that are unclear and define them, either in the appropriate Level 3 spec or here.
この例は、 格子~内の各~駒を正方形として描画するよう設定する — 駒の個数, 各~駒の横幅を可用な空間により決定して。 ◎ This example sets each item in the grid to render as a square, determining the number of items and their widths by the available space.
<ul> <li>… <li>… <li>… <li>… </ul>
ul {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(12em, 1fr));
}
li {
aspect-ratio: 1/1;
overflow: auto;
}
この例では、 `iframe$e 要素の `aspect-ratio$p ~propを,その[ `width^a, `height^a ]属性を利用して設定する。 ~iframe_e は この縦横比を利用して~sizeされ、 正確に,縦横比を伴う画像の様に挙動するようになる。 ◎ This example uses the iframe element’s width and height attributes to set the aspect-ratio property, giving the iframe an aspect ratio to use for sizing so that it behaves exactly like an image with that aspect ratio.
<iframe src="https://www.youtube.com/embed/0Gr1XSyxZy0" width=560 height=315>
@supports (aspect-ratio: attr(width number) / 1) {
iframe {
aspect-ratio: attr(width number) / attr(height number);
width: 100%;
height: auto;
}
}
`置換され$る要素が その`生来な寸法$として[ `生来な横幅$, `生来な縦幅$ ]のうち片方しか有さない下で,要素に`選好d縦横比$を与えた場合、[ その片方を`選好d縦横比$を通して転換した結果 ]がもう片方を与える。 ◎ If a replaced element’s only natural dimension is a natural width or a natural height, giving it a preferred aspect ratio also gives it an natural height or width, whichever was missing, by transferring the existing size through the preferred aspect ratio.
4.2. 自動的~sizeに対する選好d縦横比による効果
~boxが`選好d縦横比$を有する場合、 ~boxの`自動的~size$は,[ `生来な縦横比$を有する, かつ その軸において`生来な~size$は無い`置換され$る要素 ]と同じに計算される — 例: `CSS2$r `§ 10@~CSS2J#visudet$, ~flex~layoutの `§ 行f長さの決定@~CSSFLEX#algo-main-item$ を見よ。 `縦横比に依存する軸@ ( `ratio-dependent axis^en )とは、 `選好d~size$の計算が`選好d縦横比$に依存する方の軸を指す — その入力~sizeが`確定的$ならば、 結果の~sizeも`確定的$になる。 他方の軸が, `縦横比に依存しない軸@ ( `ratio-determining axis^en )になる (`縦横比に依存する軸$における~sizeは、 この軸における~sizeに依存する)。 ◎ When a box has a preferred aspect ratio, its automatic sizes are calculated the same as for a replaced element with a natural aspect ratio and no natural size in that axis, see e.g. CSS2 § 10 and CSS Flexible Box Model Level 1 § 9.2. The axis in which the preferred size calculation depends on this aspect ratio is called the ratio-dependent axis, and the resulting size is definite if its input sizes are also definite. The opposite axis (on which the ratio-dependent axis size depends) is the ratio-determining axis.
注記: ~boxの`選好d縦横比$は、 その[ `width$p, `height$p ]のうち どちらかが`自動的~size$である場合に限り, ~boxの【他方の】`選好d~size$に対する効果がある — どちらもそうでない場合、 効果は無い。 ◎ Note: A preferred aspect ratio only ever has an effect if at least one of the box’s sizes is automatic. If neither width nor height is an automatic size, it can have no effect on its preferred sizes.
すべての~sizing情報をここに移動したなら — `, rather than crowbar-ing our way into 2.1^en【?】 — ここでの中核~原則は、 `縦横比に依存しない軸$に対し ([ 最小-/最大- ]拘束を適用する前に) 解決された`選好d~size$は,比率を通して転換するだけになる。 [ 最小-/最大- ]拘束は、 その後に転換され,縦横比を問わず各~軸に独立に適用される。 ◎ When we move all the sizing information here, rather than crowbar-ing our way into 2.1, then the core principle here is just: the resolved preferred size in the ratio-determining axis (before applying min/max) gets transferred thru the ratio. Min/max constraints get transferred afterwards, and then applied to each axis independently without regards to aspect-ratio.
4.2.1. ~marginの相殺-法
`~margin相殺$の目的においては、 `縦横比に依存する軸$が`塊-軸$である場合, `block-size$p の`算出d値$は `auto$v とは見なされない。 ◎ For the purpose of margin collapsing (CSS 2 § 8.3.1 Collapsing margins), if the block axis is the ratio-dependent axis, it is not considered to have a computed block-size of auto.
4.3. 内容に基づく自動的な最小~size
意図的でない~overflowを避けるため、[ `選好d縦横比$を伴う~box %~box の`縦横比に依存する軸$ %軸 における`自動的な最小~size$ ]は,[ %~box は`置換され$る要素でない ]~AND[ %軸 は`~scroll容器$の`~scroll可能な軸$でない ]場合には[ %~box の %軸 における`最小-内容~size$を %~box の %軸 における`最大~size$以下に抑えた結果 ]になる。 ◎ In order to avoid unintentional overflow, the automatic minimum size in the ratio-dependent axis of a box with a preferred aspect ratio that is neither a replaced element, nor a scroll container in that axis, is its min-content size capped by its maximum size.
次の例では、 ~boxの横幅【!wide】は(通例通り)容器のそれと同じになり, ~boxの縦幅は[ ~boxの内容を包含するために必要な分の高さ ]かつ横幅【!wide】~以上になる。 ◎ In the following example, the box is as wide as the container (as usual), and its height is as tall as needed to contain its content but at least as tall as it is wide.
div {
aspect-ratio: 1/1;
/*
`width^p, `height^p どちらも既定では `auto^v
◎
'width' and 'height' both default to 'auto'
*/
}
+----------+ +----------+ +----------+
| ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ |
| ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ |
| ~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ |
| | | ~~~ | | ~~~~~~~~ |
+----------+ +----------+ | ~~~~~~~~ |
| ~~~~~~ |
+----------+
しかしながら, `overflow$p に `auto^v が指定されたときは、 ~boxが超過する内容を伴う場合でも縦横比 1:1 を保守する (代わりに,通例通り~scroll可能になり、 それにより~overflowを取扱う)。 ◎ When overflow: auto is specified, however, even the box with excess content maintains the 1:1 aspect ratio (and handles overflow by becoming scrollable instead, as usual).
div {
overflow: auto;
aspect-ratio: 1/1;
}
+----------+ +----------+ +----------+ | ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~^| | ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ | | | | ~~~ | | ~~~~~~~~v| +----------+ +----------+ +----------+
`min-height$p ~propを上書きしても縦横比 1:1 を保守するが、 他で取扱われない限り,内容は~boxを~overflowすることになる。 ◎ Overriding the min-height property also maintains the 1:1 aspect ratio, but will result in content overflowing the box if it is not otherwise handled.
div {
aspect-ratio: 1/1;
min-height: 0;
}
+----------+ +----------+ +----------+
| ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ |
| ~~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ |
| ~~~~~~~ | | ~~~~~~~~ | | ~~~~~~~~ |
| | | ~~~ | | ~~~~~~~~ |
+----------+ +----------+ +-~~~~~~~~-+
~~~~~~
この自動的な最小は、 どちらの軸にも演算する。 次の例を考える: ◎ This automatic minimum operates in both axes. Consider this example:
<div style="height: 100px; aspect-ratio: 1/1;"> <span style="display: inline-block; width: 50px;"></span> <span style="display: inline-block; width: 150px;"></span> </div>
この容器の `width$p は `auto$v であり,縦横比を通して 100px に解決される。 しかしながら、 その `min-width$p は `auto^v であり, 150px に解決される。 したがって,結果の容器の横幅は、 150px になる。 `min-width$p に `0^v を指定することで、 容器を~sizeするときに内容が無視されるようにできる。 ◎ The width of the container, being auto, resolves through the aspect ratio to 100px. However, its min-width, being auto, resolves to 150px. The resulting width of the container is thus 150px. To ignore the contents when sizing the container, min-width: 0 can be specified.
4.4. 最小-~size/最大-~sizeの転換-法
~boxに対する一方の軸 %元-軸 における~sizingの拘束は、 次に従って`選好d縦横比$を通して転換され,他方の軸 %行先~軸 における`不定$な[ `最小~size$/`最大~size$/`選好d~size$ ]に適用される: ◎ Sizing constraints in either axis (the origin axis) are transferred through the preferred aspect ratio and applied to any indefinite minimum, maximum, or preferred size in the other axis (the destination axis) as follows:
- %元-軸 における`最小~size$は`確定的$ならば,それは ⇒ `選好d縦横比$を通して %行先~軸 における~sizeに変換され、 その結果は ⇒ %行先~軸 における`選好d~size$は`確定的$ならば,それ以下に抑えられ、 さらに ⇒ %行先~軸 における`最大~size$は`確定的$ならば,それ以下に抑えられる。 ◎ First, any definite minimum size is converted and transferred from the origin to destination axis. This transferred minimum is capped by any definite preferred or maximum size in the destination axis.
- %元-軸 における`最大~size$は`確定的$ならば,それは ⇒ `選好d縦横比$を通して %行先~軸 における~sizeに変換され、 その結果は ⇒ %行先~軸 における`選好d~size$は`確定的$ならば,それ以下に抑えられ、 さらに ⇒ %行先~軸 における`最大~size$は`確定的$ならば,それ以下に抑えられる。 ◎ Then, any definite maximum size is converted and transferred from the origin to destination. This transferred maximum is floored by any definite preferred or minimum size in the destination axis as well as by the transferred minimum, if any.
注記: したがって,他方の軸( %行先~軸 )における確定的な~sizeは、 他方の軸へ転換された拘束には,まったく影響されない。 転換された最小~sizeは、 要素を その確定的な[ 選好d~size/最大~size ]を超過させることは決してない/ 転換された最大~sizeは,要素を その[ 選好d~size/最小~size ]に違反させることは決してない。 ◎ Note: Thus, any definite sizes are completely unaffected by a transferred constraint; and a transferred minimum will never cause an element to exceed a definite preferred/maximum size, nor will a transferred maximum cause an element to violate its preferred/minimum size.
注記: [ ~sizingの拘束を縦横比を通して他方の軸へ転換する ]ときの基本的な原則は、 他方の軸に明示的に指定された~sizeに違反しない限り, できるだけ自身の縦横比を保全することにある。 (これが, `CSS2$r `§ 縦横比を伴う~size不定な置換d要素に対する最大, 最小~sizeの適用-法@~CSS2J#min-max-replaced-size$【!~CSS2J#min-max-widths】 の内容から導出される原則である。) ◎ Note: The basic principle is that sizing constraints transfer through the aspect-ratio to the other side to preserve the aspect ratio to the extent that they can without violating any sizes specified explicitly on that affected axis. (This is the principle that drove the contents of the constraint table in CSS2 Section 10.4.)
次の例では: ◎ In the following example:
<div id=container style="height: 100px; float: left;"> <div id=item style="height: 100%; aspect-ratio: 1/1;">content</div> </div>
~item( `#item^css )の縦幅は,~sizeが確定的な容器を~~基準に解決される百分率であり、 ~itemの横幅は,[ その`内在的~size供与$, 最終的な~layout ]どちらにおいても `100px^v に解決されるので、 容器の横幅も `100px^v に~sizeする。 ◎ Since the height of the #item is a percentage that resolves against a definite container, the width of the item resolves to 100px for both its intrinsic size contributions as well as for final layout, so the container also sizes to a width of 100px.
代わって,次の例では: ◎ ↓
<div id=container style="height: auto; float: left;"> <div id=item style="height: 100%; aspect-ratio: 1/1;">content</div> </div>
百分率による~itemの縦幅は、 解決し得ないので,`~autoとして挙動する$ ( `CSS2$r `§ 内容~縦幅@~CSS2J#the-height-property$を見よ)。 今や,どちらの軸も`自動的~size$になるので、 縦~軸【!縦幅】は`縦横比に依存する軸$になる。 ~boxの`内在的~size供与$を計算すると,その内容から導出される横幅を生産する — 縦幅は,結果の横幅と縦横比から計算され、 単語 “content” の横幅に~sizeされた正方形な~box(および容器)が得られる。 ◎ In this next example, the percentage height of the item cannot be resolved and behaves as auto (see CSS 2 § 10.5 Content height: the 'height' property). Since both axes now have an automatic size, the height becomes the ratio-dependent axis. Calculating the intrinsic size contributions of the box produces a width derived from its content, and a height calculated from that width and the aspect ratio, yielding a square box (and a container) sized to the width of the word “content”.
この節は、 正しく書かれてないかもしれない。 [`6071$issue] ◎ This section might not be written correctly. [Issue #6071]
5. 内在的~sizeの決定法
5.1. 内在的~size
`~level 3$ `§ 内在的~size@~SIZING#intrinsic-sizes$ を統合する。 ◎ CSS Sizing 3 § 5.1 Intrinsic Sizes
5.2. 封込まれた内在的~sizeの上書き法:各種 `contain-intrinsic-*^p ~prop
これらの~propは、[ `~size封込め$を伴う要素に 【各~軸において】 `明示的な内在的~内縁~size@ を指定すること ]を許容する。 それにより、 当の~boxは,[ その`~flow内$には、 全体の[ 横幅/縦幅 ]が指定された`明示的な内在的~内縁~size$に合致している内容が在る ]かのように~sizeされる (【既定では,】空であったかのように~sizeされる代わりに)。 ◎ These properties allow elements with size containment to specify an explicit intrinsic inner size, causing the box to size as if its in-flow content totals to a width and height matching the specified explicit intrinsic inner size (rather than sizing as if it were empty).
注記: これは、[ 要素~内には、 指定された`明示的な内在的~内縁~size$を伴う子が 1 個だけ在る ]かのように~lay-outとするときと,常に等価になるとは限らない。 例えば,ある`格子~容器$内に指定された~sizeを伴う子が 1 個だけ在る場合でも、 指定された格子に則って~sizeすることになる — 結果の内容~sizeは、 通例的に,指定された~sizeより大きくなる。 ◎ Note: This is not always equivalent to laying out as if the element had one child of the specified explicit intrinsic inner size. For example, a grid container with one child of the specified size would still size according to the specified grid, usually ending up with a larger content size than specified.
以下の記述における各種~sizeは、 当の~propが対象にする軸 (例: `contain-intrinsic-block-size$p ならば`塊-軸$) における~sizeを指すとする: ◎ ↓
- `none@v1 | `length$t
- 当の要素の`明示的な内在的~内縁~size$は ⇒ それを供している `contain-intrinsic-size$p 値( `auto$v1 など)は他に無いならば ⇒# `none$v1 が指定された場合は無い/ `length$t が指定された場合はそれになる。 ◎ If no other contain-intrinsic-size value (such as auto) is providing an explicit intrinsic inner size, the corresponding axis either doesn’t have an explicit intrinsic inner size (if none is specified) or has an explicit intrinsic inner size of the specified <length>.
- `auto@v1
-
当の要素の`明示的な内在的~内縁~size$は ⇒ 当の要素の`内容は飛ばされて@~CSSCONTAIN#skips-its-contents$いるならば ⇒ 当の要素が`最後に記憶した~size$ ~NEQ ε ならば それになる。 ◎ If auto is specified and the element has a last remembered size and is currently skipping its contents, its explicit intrinsic inner size in the corresponding axis is the last remembered size in that axis.
注記: これは、 例えば,当の要素が次を満たすときに生じる ⇒ [ その `content-visibility$p ~EQ `auto^v ]~AND[ ~screen外にある ] ◎ Note: This occurs, for example, when an element with content-visibility: auto is off-screen.
所与の要素が[ ある軸において`明示的な内在的~内縁~size$を有する ]場合、 当の要素を`~size封込め$用に通常通り~lay-outした後において,[ 当の要素を成す内容の当の軸における~sizeは、 ~layoutにて計算された結果に代えて, `明示的な内在的~内縁~size$になる ]ものと扱われ,必要yなら~layoutを再び遂行する。 (両~軸において`明示的な内在的~内縁~size$を有する場合、 このことは,最初の~layoutを飛ばせることを含意する。) ◎ If an element has an explicit intrinsic inner size in an axis, then after laying out the element as normal for size containment, the size of the contents in that axis are instead treated as being the explicit intrinsic inner size instead of what was calculated in layout, and layout is performed again if necessary. (If it has an explicit intrinsic inner size in both axises, this implies the first layout can be skipped.)
これら 4 種の~propは、 `論理-~prop~group$の一部を成す。 ◎ These four properties are part of a logical property group.
注記: `~size封込め$ `CSS-CONTAIN-1$r を伴う要素は、 内容が無かったかのように~lay-outされ、 要素の`内縁~縦幅$は,多くの事例で 0 に畳まれることになる。 これは,[ 期待される内容を示すよう選ばれた,明示的な `height$p ]で正せるが、 一部の~layout~system — `~flex~layout$/`格子~layout$など — においては,意図されない効果が生じ得る — [ そこでは、 明示的な `height$p は,内容に基づく暗黙的な縦幅より優先される ]ので、[ 要素を~lay-outした結果は、 単純に内容が要素の縦幅まで埋められたときとは,かなり異なる ]かもしれない。 要素に`明示的な内在的~内縁~size$を供することは、[ ~layout用には,要素の内容を無視する ]ことによる処理能の便益は保全しつつ,[ 内容が在ったかのように~sizeする ]ことを許容する。 ◎ Note: An element with size containment is laid out as if it had no contents [CSS-CONTAIN-1], which in many cases this will cause the element to collapse to zero inner height. This can be corrected with an explicit height chosen to show the expected contents, but that can have unintended effects in some layout systems, such as Flex and Grid Layout, which treat an explicit height as a stronger command than an implicit content-based height. The element thus might lay out substantially differently than it would have were it simply filled with content up to that height. Providing an explicit intrinsic inner size for the element preserves the performance benefits of ignoring its contents for layout while still allowing it to size as if it had content.
`contain-intrinsic-size$p は、[ `contain-intrinsic-width$p, `contain-intrinsic-height$p ]~propを設定する略式~propである。 ◎ contain-intrinsic-size is a shorthand property that sets the contain-intrinsic-width and contain-intrinsic-height properties.
[ 1 個目/ 2 個目 ]の値は、[ `contain-intrinsic-width$p / `contain-intrinsic-height$p ]の値を表現する。 値が 1 個だけ与えられた場合、 それが 2 個目の値も与える。 ◎ The first value represents the contain-intrinsic-width value, and the second represents the contain-intrinsic-height value. If only one value is given, it applies to both properties.
5.2.1. 最後に記憶した~size
`~size封込め$は、[[ ある要素の描画が変化した結果として起こり得る~layout作業 ]の視野を制約して,~pageを効率的に描画する ]のを確保するためとして,とても役立つ。 しかしながら,作者にとっても、 要素の~sizeがどうなるか正しく予測するよう要求されるので,制約的である — この推測が少しでも不正な場合、 ~scrollbarが見苦しくなったり,内容が偶発的に隠され得る。 ◎ Size containment is very valuable for ensuring a page can render efficiently, restricting the scope of layout work that can happen as a result of an element changing its rendering. However, it’s also very restrictive for the author, requiring them to correctly predict what the size of the element will be; if this guess is incorrect, even slightly, it can cause unsightly scrollbars or accidentally-hidden content.
`contain-intrinsic-size$p 用の値 `auto$v1 は、 ある妥協点を許容する: 要素は,まだ`~size封込め$を`経ていない^em場合、 この値は、 要素に自身の~size(~layoutにより通常通り計算された~size)を記憶させる。 後で要素が`~size封込め$を伴うようになったとき、 要素は記憶した~sizeを利用することになり、 その内容を`おそらく^em正確aに~sizeしつつ,`~size封込め$による処理能の便益を提供する。 ◎ The auto keyword of contain-intrinsic-size allows a middle-ground: if an element is ever not size-contained, this value causes the element to remember its size (calculated as normal by layout); then, if the element gains size containment later, it will use the remembered size, offering the performance benefits of size containment while probably sizing accurately to its contents.
`最後に記憶した~size$ ~NEQ ε になる要素は、[ `ResizeObserver$I の~targetになる能力があるもの ]に限られる。 ◎ Only elements capable of being ResizeObserver targets can have a last remembered size.
所与の %要素 が`最後に記憶した~size$は、 各[ `ResizeObserver$I ~eventが決定され, 送達された時点 ]において,次に従って決定される: ◎ The last remembered size of an element is determined by:
- ~IF[ %要素 の `contain-intrinsic-size$p 値に `auto$v1 は無い ] ⇒ %要素 が`最後に記憶した~size$ ~SET ε ( “なし” ) ◎ ↓
- ~ELIF[ %要素 は`ResizeObserver$I の~targetになる能力はある ]~AND[ %要素 は`~size封込め$を伴っていない ] ⇒ %要素 が`最後に記憶した~size$ ~SET %要素 の`首要~box$の現在の`内縁~size$【!内縁~寸法】 ◎ At the time that ResizeObserver events are determined and delivered, if an element has a auto keyword in contain-intrinsic-size property, is capable of being a ResizeObserver target, but does not have size containment, record the current inner dimensions of its principal box as its last remembered size. ◎ At the time that ResizeObserver events are determined and delivered, if an element has a last remembered size but does not have auto keyword in contain-intrinsic-size property, remove its last remembered size.
注記: `最後に記憶した~size$は、 %要素 が生成する特定0の~boxではなく, %要素 に付与される状態である。 %要素 が `contain-intrinsic-size$p ~propにおいて `auto$v1 を維持する限り、 %要素 は `display$p が[ `none^v / `none^v 以外 ]への変化を経たとしても, %要素 は自身が`最後に記憶した~size$を記憶する。 ◎ Note: The last remembered size is state attached to the element, not any particular box generated by the element. So long as the element retains auto keyword in contain-intrinsic-size property, it will remember its last remembered size even across changes such as going to/from display: none.
5.2.2. `overflow^p との相互作用
`contain-intrinsic-size$p ~propは、 作者が要素の内容に期待する大きさの見積もりを供する。 この見積もりは、 実際の内容ではなく,利用者に示される必要があるものは何ら表現しない。 したがって,要素の `overflow$p が `auto^v の場合でも、 `contain-intrinsic-size$p の帰結として ~scrollbarは生成しないモノトスル。 ◎ The contain-intrinsic-size property provides an estimate of how large the author expects the content of an element to be, but this estimate is not actual content and does not represent anything that needs to be shown to the user. Therefore, an element with overflow: auto must not generate scrollbars as a consequence of contain-intrinsic-size.
しかしながら, `contain-intrinsic-size$p が当の要素が~scrollbar生成するほど十分~大きい~sizeを指示していて,その~sizeの内容を実際に包含した場合、 要素は[ そのような仮の内容に則って,自身の~scrollbarを(各~軸ごとに)生成した ]かのように,`~sizeされる^emモノトスル。 ◎ However, if contain-intrinsic-size indicates a size large enough that the element would generate scrollbars if it contained actual content of that size, then the element must be sized as if it generated those scrollbar(s) in accordance with such hypothetical content.
次の~code例では: ◎ In the following example code:
div {
width: max-content;
contain-intrinsic-size: 100px 100px;
overflow: auto;
}
要素の幅は `100px^v, 高さは `100px^v になる。 `contain-intrinsic-size$p は,最大-内容[ 横幅, 縦幅 ]どちらも供する。 ◎ The element ends up being 100px wide and 100px tall: contain-intrinsic-size provides the max-content width, and also the height.
要素の内容の高さが `150px^v になった場合、 縦方向~scrollbarを示すすることになる。 ~scrollbarは — ~overlayでないならば — 横幅 `100px^v の一部を占めることになり、 その中に~flowされる内容~用に残す量は小さくなる(概して,概ね `84px^v )( `CSS-OVERFLOW-3$r `§ ~scrollbarと~layout@~CSSOVERFLOW3#scrollbar-layout$ を見よ)。 ◎ If the element then ended up with content that was 150px tall, it would show a vertical scrollbar; if the scrollbar is not overlay, it will take up some of that 100px width, leaving a smaller amount (roughly 84px, typically) for the content to flow into. (See CSS Overflow 3 § 5 Scrollbars and Layout.)
内容に可用な横方向~空間は、 今や `100px^v 未満しかなくても、 `contain-intrinsic-size$p が横幅 `100px^v を指示するだけで横方向~scrollbarを生成することはない — それが起こるのは、 実際の内容に,残りの空間より幅広かつ分断-不能な何かがあるときに限られる。 ◎ Even though there’s now less than 100px of horizontal space available for the content, it will not generate a horizontal scrollbar just because contain-intrinsic-size indicates a 100px width; that would only happen if the actual content had something unbreakable and wider than the remaining space.
対照的に,次の~code例では: ◎ In contrast, in the following example code:
div {
width: max-content;
contain-intrinsic-size: 100px 100px;
height: 50px;
overflow: auto;
}
要素の縦幅は固定的な `50px^v であるが, `contain-intrinsic-size$p は “見積もられた内容~縦幅” として `100px^v を指示する。 したがって,要素は、 実際の内容で埋められるときに縦方向~scrollbarが必要になるものと見做す。 その結果 — `contain-intrinsic-size$p から見積もられた最大-内容~横幅 `100px^v に加えて,縦方向~scrollbar横幅(概して,概ね `16px^v )を収容するため — 最大-内容~横幅は `100px^v を少し超える(概して,概ね `116px^v になる)。 ◎ The element has a fixed 50px height, but contain-intrinsic-size indicates a 100px “estimated content height”. The element thus assumes that it will need a vertical scrollbar when it’s filled with actual content, resulting in a max-content width a little more than 100px (roughly 116px, typically), to accommodate the estimated 100px of max-content width from contain-intrinsic-size, and as well as the vertical scrollbar width (roughly 16px, typically).
しかしながら,要素が — ~scrollbarが必要になる前提の下で — 空間を予約するとしても、 内容が実際に~overflowしない限り,それを実際に生成することはない。 その高さが `50px^v 未満の内容を包含することになる場合、 縦方向~scrollbarは まったく生成されない一方で,要素の幅は依然として `116px^v になる。 ◎ However, even though the element reserves space on the assumption of needing a scrollbar, it will not actually generate one unless the actual content overflows: if it ends up containing content that’s less than 50px tall, no vertical scrollbar will be generated at all, but the element will still be 116px wide.
5.3. 応答可能に~sizeされる~iframe_e: `frame-sizing^p ~prop
`置換され$る要素には、 “通常の” ~flowされる内容を包含し得るものもある — ~HTMLの `iframe$e など。 ~privacyと~securityの理由から、 これらの要素は,既定では[ 自身の内部的な内容の~sizingについての情報 ]を外側~pageには公開しない — 代わりに,静的かつ予め決定-済みな内在的~sizeだけを利用して、 各自の内容を~scroll可能にする。 `frame-sizing$p ~propは、 そのような要素が[ `内部~layout内在的~size@ — その実際の内容~size — を公開すること ]を~opt-inすることを許容する。 ◎ Some replaced elements can contain "normal" flowed content, such as HTML iframes. For privacy and security reasons, these elements do not, by default, expose any information about their internal contents' sizing to the outside page, instead just using a static, predetermined intrinsic size, and making their contents scrollable. The frame-sizing property allows these elements to opt into exposing their actual content size, known as their internal layout intrinsic size.\
各種~値の意味は: ◎ Values have the following meaning:
- `auto@v1
- 当の要素の`内部~layout内在的~size$は、 有っても無視される。 ◎ The element’s internal layout intrinsic size, if any, is ignored.
- `content-width@v1
- `content-height@v1
- `content-block-size@v1
- `content-inline-size@v1
- 当の要素が`内部~layout内在的~size$を有する場合、 その`内在的~size$は,`内部~layout内在的~size$から 当の~keywordに対応する寸法(横幅/縦幅)をとる (他方の寸法は、 通常に決定される)。 ◎ If the element has an internal layout intrinsic size, its intrinsic size takes the corresponding dimension (either width or height) from the internal layout intrinsic size. (The other dimension is determined normally.)
- 論理-方向は、 当の要素の`書字~mode$に基づいて解決される — 埋込まれた文書のそれではなく)。 ◎ Logical directions resolve based on the writing mode of the element. (Not the embedded document.)
[ どの要素が`内部~layout内在的~size$を有し得るか ]および[ それは どう決定されるか ]は、 `文書~言語$により裁定される。 ~HTMLにおいては、 `内部~layout内在的~size$を有し得る要素は, `iframe$e に限られることに加え、 それを有するのは,埋込まれた文書も[ `meta$e 要素のうち, `responsive-embedded-sizing^v を値に伴う `name^a 属性を有するもの ] *`<meta name=responsive-embedded-sizing>^c 要素を介して それを~opt-inしたとき限られる ( *`§ ~HTML~iframe_eの詳細@#iframe-frame-sizing$を見よ)。 ◎ Which elements can have an internal layout intrinsic size, and how it’s determined, are decided by the document language. In HTML, only iframe elements can have an internal layout intrinsic size, and further, only when the contained document has also opted in via a <meta name=responsive-embedded-sizing> element. (See § 5.3.1 HTML iframe Details.)
埋込まれた文書は、 次の~HTMLを有していて: ◎ When the embedded document has the following HTML:
<meta name="responsive-embedded-sizing"> <div style="height: 500px"></div>
埋込んでいる文書は、 次の~CSSを有するとする: ◎ and the embedding document has the following CSS:
iframe {
frame-sizing: content-height;
}
このとき、 `iframe$e の縦幅は, 初期~時は ~iframe_e 縦幅【`既定の~obj~size$】(概して `150px^v )になるが、 ~iframe_e 文書が読込まれたなら, `500px^v へ更新されることになる。 ◎ The height of the iframe will initially be the default iframe height (typically 150px), but will be updated to 500px once the iframe’s document loads.
加えて,埋込まれた文書は、 後で `requestResize()$m を~callして, 自身の`内部~layout内在的~size$を更新できる。 ◎ In addition, the internal document can call window.requestResize() to update its internal layout intrinsic size later.
5.3.1. ~HTML~iframe_eの詳細
~HTMLにおいては、 `内部~layout内在的~size$を有し得る要素は `iframe$e しかないことに加え, それを有するのは `iframe$e 内に埋込まれた文書が それを適切に~opt-inしたときに限られる。 ◎ In HTML, only the iframe element can have an internal layout intrinsic size, and only when the iframe’s embedded document has opted in appropriately.
各~HTML`文書$ %文書 には、 `応答可能な埋込d~sizing~flag@ が結付けられる — それは、[ `未設定^i /ある真偽値 ]をとり,初期~時は `未設定^i とする。 それは、 %文書 を構文解析する間に真偽値に設定され, 次に挙げる 2 つのうち[ 前者が最初に生じたならば ~T / 後者が最初に生じたならば ~F ]に設定される: ◎ An HTML Document object has an responsive embedded sizing flag associated with it, which is initially unset. It is set to true or false during the initial document parse, depending on which of the following first occurs:
- *`<meta name=responsive-embedded-sizing>^c 要素に遭遇した。 ◎ If a <meta name=responsive-embedded-sizing> element is encountered, it is set to true.
- 構文解析器により, `body$e 要素が(明示的か暗黙的に)~openされた 【`~open要素~stack@~HTMLparsing#stack-of-open-elements$に~pushされた】 か %文書 の中へ挿入された。 ◎ If the body element is opened (explicitly or implicitly), or inserted into the document by the parser, it is set to false.
この~flagの値は、 真偽値に設定されて以降は, 当の`文書$の存続期間にわたり再び変更されることはない。 ◎ Once set to either true or false, the flag will not change its value again for the lifetime of the Document.
注記: 現時点では、 ~HTMLにおいて この特能を埋込まれた文書~用に~opt-inするための仕方は, 当の文書の `head$e 要素~内に現れる `meta$e 要素の他にない。 このことは、 `iframe$e 内の~SVG文書は,そうし得ないことを意味する。 ◎ Note: Currently, the HTML meta element appearing in the head of an HTML document is the only way for an embedded document to opt into this feature in HTML. This means that SVG documents in iframe cannot do so.
注記: ~HTML構文解析器の過去互換に因り、 `meta$e 要素は,形上では【すなわち,構文上は】[ `head$e, `body$e ]要素の`合間^emにも現れ得る — それは、 その親が `head$e 要素になるよう`親を違える@~HTMLparsing#foster-parent$ことになる。 それでも、 `body$e 要素は,まだ~openされていないので, *`<meta name=responsive-embedded-sizing>^c 要素~用の妥当な所在になる。 [ ほとんどの~HTML要素は、 `body$e 要素の開始~tagが無い場合でも, 暗黙的に `body$e 要素を~openすることになる 【`参照@~HTMLparsing#the-after-head-insertion-mode$】 ]ことに加え,[ 当の文書が `body$e 要素を完全に欠如する場合【開始~tag, 終了~tagどちらも無い場合】でも、 空なそれが自動的に生成され,挿入される ]ことに注意。 ◎ Note: Due to quirks of the HTML parser, a meta element can technically appear between the head and body elements, and will be reparented into the head. This is still a valid location for the <meta name=responsive-embedded-sizing> element, as the body has not yet been opened. Note that most HTML elements will implicitly open a body element even if the body start tag is not present, and if the document completely lacks such an element, an empty one is automatically generated and inserted.
`内部~layout内在的~size$は、 まず,埋込まれた文書の最初の~layoutによる結果に — 当の文書へ向けて `DOMContentLoaded@~HTMLindex#event-domcontentloaded$et ~eventが発火された後に — 設定され、 `Window$I へ向けて `load@~HTMLindex#event-load$et ~eventが発火されたとき, 再び設定される。 埋込まれた文書の[ 内容/~style付け/~layout ]に対する後続な変更は、 `内部~layout内在的~size$に自動的に影響することはない — が、 `requestResize()$m を見よ。 ◎ The internal layout intrinsic size is first set by the results of the embedded document’s first layout after it fires its DOMContentLoaded event, and again when the load event is fired at the Window. Subsequent changes to content, styling or layout of the embedded document do not automatically affect the internal layout intrinsic size, but see requestResize().
埋込まれた各~文書 %文書 は、 `~lockされた埋込d初期~包含塊~size@ を追加的に有する — それは、[ ~NULL / ( 横幅 ,縦幅 ) が成す~tuple ]であり,初期~時は~NULLとする。 %文書 が~layoutを遂行するとき,[ %文書 の`応答可能な埋込d~sizing~flag$ ~EQ ~T ]~AND[ %文書 の`~lockされた埋込d初期~包含塊~size$ ~EQ ~NULL ]が満たされるならば、 %文書 の`~lockされた埋込d初期~包含塊~size$には, %文書 の現在の`初期~包含塊$の~sizeが記録される。 %文書 は、 後続な~layoutに際し,自身の`~lockされた埋込d初期~包含塊~size$を利用する — 自身の`初期~包含塊$の~sizeを通常に計算する代わりに。 ◎ An embedded document can additionally have a locked embedded ICB size, which is initially null. If the document’s responsive embedded sizing flag is true when it performs a layout, and its locked embedded ICB size is null, it records its current initial containing block size as its locked embedded ICB size. On subsequent layouts, it uses its locked embedded ICB size instead of calculating its initial containing block size normally.
注記: このように初期~包含塊を凍結すれば、 ~layout~loop (ある ~iframe_e 内の文書が自身の初期~包含塊を少し大きく~sizeして, 当の ~iframe_e の~sizeが それに合致するよう変更され, 次回の~layoutが再び初期~包含塊より少し大きく~sizeして, 等々が際限なく続く) の機会cは抑制される。 ◎ Note: This freezing of the ICB reduces the chance of layout loops (an iframe document sizing to slightly larger than its ICB, then the parent iframe changing size to match, and the next layout again making it slightly larger than the ICB, etc to infinity).
~iframe_e に自身の`~lockされた埋込d初期~包含塊~size$を ~NULL にするよう強制するための仕方は求まれるか? `frame-sizing$p を `off^en にしてから再び `on^en に転じる 【初期~値に戻してから他の値に設定したとき,強制するようになる?】 とか。 ◎ Do we want to have a way to force an iframe to forget its locked embedded ICB size? Maybe turning frame-sizing off and on again?
~iframe_e 内に埋込まれた文書が他へ~navigateされると、 その`~lockされた埋込d初期~包含塊~size$は ~NULL になる。 その`内部~layout内在的~size$は、 新たな文書の`応答可能な埋込d~sizing~flag$ ~EQ `未設定^i の間は, ~NULL に ならない。 この~flagが真偽値に設定されたなら, `内部~layout内在的~size$は ~NULL になり、 この~flagが ~T に設定されたなら,どちらも通常通り新規に算出される。 ◎ Navigating the iframe’s document causes it to forget its locked embedded ICB size. It does not forget its internal layout intrinsic size as long as the new document’s responsive embedded sizing flag is unset. Once the flag is set (to true or false), the internal layout intrinsic size is forgotten; if the flag is set to true, both are then freshly computed as normal.
5.3.2. `Window^I ~interfaceに対する拡張
partial interface `Window$I {
`undefined$ `requestResize$m();
};
`requestResize()@m ~method手続きは: ◎ When requestResize() is invoked:
- %~navigable ~LET 次を満たす`~navigable$ ⇒ その`内容~window$【が包装している `Window$I ~obj】 ~EQ コレ ◎ Let navigable be the navigable that has this as its content window.\
- ~IF[ %~navigable は`子~navigable$でない ] ⇒ ~THROW `NotAllowedError$E ◎ If navigable is not a child navigable, throw a NotAllowedError DOMException.
- %~host要素 ~LET %~navigable の`容器$nav ◎
- ~IF[ %~host要素 は ~HTML `iframe$e 要素でない ] ⇒ ~THROW `NotAllowedError$E ◎ Let host element be the navigable container whose content navigable is navigable. If host element is not an HTML iframe element, throw a NotAllowedError DOMException.
- %文書 ~LET %~navigable【!コレ】 にて`作動中な文書$nav ◎ Let document be this’s active document.\
- ~IF[ %文書 の`応答可能な埋込d~sizing~flag$ ~IN { `未設定^i, ~F } ] ⇒ ~THROW `NotAllowedError$E ◎ If document’s responsive embedded sizing flag is unset or false, throw a NotAllowedError DOMException.
- ~IF[ %文書 には処理待ちな[ ~style変更/~layout変更 ]が有る ] ⇒ それらを遂行する ◎ If document has pending style or layout changes, perform them.
- %~host要素 の`内部~layout内在的~size$ ~SET %文書 の表示域【!コレ】の`~scrollされる区画$の ( 横幅, 縦幅 ) ◎ Set the internal layout intrinsic size of host element to the width and height of the scrolling area of this.
5.4. 内在的~size供与
`~level 3$ `§ 内在的~size供与@~SIZING#intrinsic-contribution$ を統合する。 ◎ CSS Sizing 3 § 5.2 Intrinsic Contributions
5.5. 最小-内容~size供与の~zero化: `min-intrinsic-sizing^p ~prop
この~propの名前は、 何らかの `bikeshedding^en が切に必要である。 ◎ This property seriously needs some name bikeshedding.
この~propは、 ある種の状況下で,`置換され$ない~boxの`最小-内容 供与$が “圧縮される” かどうかを定義する。 各種~値の意味は: ◎ This property defines whether the min-content contribution of a non-replaced box is “compressed” under certain circumstances. Values have the following meanings:
- `legacy@v1
- ~boxの`最小-内容 供与$は、 通常通り取扱われる。 ◎ The box’s min-content contribution is handled as normal.
- `zero-if-scroll@v1
- 当の~boxは`~scroll容器$である場合には、 その`最小-内容 供与$は、 `that^en 軸【`~scroll可能な軸$?】において “圧縮される”。 ◎ The box’s min-content contribution is “compressed” if it is a scroll container in that axis.
- `zero-if-extrinsic@v1
- 当の~boxは`外在的$szな[ `選好d~size$/`最大~size$ ]を有するならば、 その`最小-内容 供与$は “圧縮される”。 ◎ The box’s min-content contribution is “compressed” if has an extrinsic preferred or maximum size.
- 注記: これは、 ほとんどの`置換され$る要素に対し既定の挙動を与える。 ◎ Note: This is the default behavior of most replaced elements.
次の規則は、[ すべての`~scroll容器$は、 自身の~size供与を渡しておくときに,本質的に自身の内容を無視する ]ようにする(当の容器に対し,内容に基づく~sizeが特定的に要請されない限り): ◎ The following rule will make all scroll containers essentially ignore their contents when passing up their size contributions (unless they specifically requested a content-based size):
*, ::before, ::after { min-intrinsic-sizing: zero-if-scroll; }
これは、 `~scroll容器$が巨大な~item — ~tableや, 分断-不能な~textが成す長い行lなど — を包含する場合に,その先祖の~sizeを吹き~~飛ばすことを防止する。 その一方,~scroll容器でない~boxは、 先祖の`最小-内容~size$に波及し続けることを許容する。 ◎ This prevents the scroll container from blowing up the size of its ancestors if it contains large items such as a table or long lines of unbreakable text. Meanwhile, it allows boxes that are not scroll containers to continue influencing the min-content size of their ancestors.
注記: `zero-if-scroll$v1 の方が良い既定の挙動になったであろうが、 ~Web互換性に因り,あいにく`初期~値$にはし得ない。 ◎ Note: The behavior of zero-if-scroll would have been a better default, but due to Web-compat, it cannot be the initial value. :(
“圧縮される” `最小-内容 供与$は、 ~boxは空であったかのように計算される — `~sizing~prop$に対する明示的な[ `min-content$v / `max-content$v / `fit-content$v ]値により課される~sizing拘束において `factor^en しているときを除いて。 ◎ The “compressed” min-content contributions is calculated by pretending the box were empty, except when factoring in sizing constraints imposed by explicit min-content, max-content, and fit-content values of the sizing properties.
5.5.1. 百分率で~sizeされた~boxの内在的~供与
ときには、 百分率で~sizeされた~boxの`包含塊$の~sizeが当の~box自身の`内在的~size供与$に依存することもあり, 循環な依存関係を作成する。 これを解決する方法については、 `~level 3$ `§ 百分率で~sizeされた~boxの内在的~供与@~SIZING#cyclic-percentage-contribution$ を見よ。 ◎ Sometimes the size of a percentage-sized box’s containing block depends on the intrinsic size contribution of the box itself, creating a cyclic dependency. See CSS Sizing 3 § 5.2.1 Intrinsic Contributions of Percentage-Sized Boxes for how to resolve these.
`fit-content$f 用には、 【その引数の】 `length-percentage$t 式~自体が当の~propの`初期~値$に解決される場合には, 代わりに: ◎ For fit-content(), if the <length-percentage> expression on its own would resolve to the property’s initial value, then instead:
- `最大~size~prop$用には、 それを `max-content$v【!#valdef-column-width-max-content】 として扱う。 ◎ For a maximum size property, treat it as max-content.
- `最小~size~prop$用には、 それを `min-content$v【!#valdef-column-width-min-content】 として扱う。 ◎ For a minimum size property, treat it as min-content.
- `選好d~size~prop$用には、 それを `fit-content$v【!#valdef-column-width-fit-content】 として扱う。 ◎ For a preferred size property, treat it as fit-content.
5.6. ~col~sizingを与える新たな値
`column-width$p 用の値に利用される新たな~keywordは、 最適とされる~col幅を指定する — 以下における %容器 は、 当の`複-~col容器$を指すとする: ◎ When used as values for column-width, the new keywords specify the optimal column width:
【 “最適( `optimal^en )” の意味は `column-width$p の記述を見よ。 】
- `stretch@v1
- 最適な~col幅を[ %容器 の`伸張して収まる行内~size$ ]として指定する。 ◎ Specifies the optimal column width as the stretch-fit inline size of the multi-column container.
- `min-content@v1
- 最適な~col幅を[ %容器 の【!内容の】`最小-内容 行内~size$ ]として指定する。 ◎ Specifies the optimal column width as the min-content inline size of the multi-column container’s contents.
- `max-content@v1
- 最適な~col幅を[ %容器 の【!内容の】`最大-内容 行内~size$ ]として指定する。 ◎ Specifies the optimal column width as the max-content inline size of the multi-column container’s contents.
- `fit-content@v1
- 最適な~col幅を次の結果として指定する ⇒ `min^op( %容器 の`最大-内容 行内~size$, `max^ops( %容器 の`最小-内容 行内~size$, %容器 の`伸張して収まる行内~size$ ) ) ◎ Specifies the optimal column width as min(max-content inline size, max(min-content inline size, stretch-fit inline size)).
- `fit-content$f
- 最適な~col幅を次の結果として指定する ⇒ `min^op( %容器 の`最大-内容~size$, `max^ops( %容器 の`最小-内容~size$, 引数に与えられた `length-percentage$t ) ) ◎ Specifies the optimal column width as min(max-content size, max(min-content size, <length-percentage>))
注記: ~col幅は、 ~colごとに変わることは決してない。 ~col幅が(上で与えた~keywordにより)`複-~col容器$の内容に基づく場合、 その内容~すべてが考慮され, 計算した結果の幅は【当の容器~内の】すべての~colから共有される。 ◎ Note: The column width never varies by column. When the column width is informed by the multi-column container’s contents (as in the keywords above), all of its contents are taken under consideration and the calculated width is shared by all the columns.
【 この節を成す内容は、 `fit-content$f が追加されたことを除いて, `~level 3$ と`同じ@~SIZING#column-sizing$。 】
6. 外在的~sizeの決定
`~level 3$ `§ 外在的~sizeの決定@~SIZING#extrinsic$ を統合する。 ◎ CSS Sizing 3 § 4 Extrinsic Size Determination
6.1. 包含して収まる~sizing: 縦横比を保守しながら伸張する
包含して収まる~sizingは,本質的には伸張して収まる~sizingを適用するが、 ~boxの`選好d縦横比$を保守するよう,一方の軸における~boxの~sizeを抑制する — [ `object-fit$p / `background-size$p ]~prop用の~keyword `contain^v と類似に。 ◎ Contain-fit sizing essentially applies stretch-fit sizing, but reduces the size of the box in one axis to maintain the box’s preferred aspect ratio, similar to the contain keyword of the object-fit and background-size properties.
まず,~target矩形を以下に従って決定する: ◎ First, a target rectangle is determined:
-
~target矩形【の~size(以下同様)】は、 初期~時は~boxの包含塊の~sizeとする — ここでは、 `不定$な~sizeは無限大と見做す。 どちらの寸法も不定な場合、 初期~target矩形は,[ ~box【`内容~box$】の~sizeが`伸張して収まる~size$~FNであったとするときの~boxの`外縁~辺$ ]に合致するよう設定される。
【~FN ~boxに`可用な空間$が`不定$な場合、 この~sizeは定義されないが,その場合にどうなるのか述べられていない。 】
◎ The initial target rectangle is the size of the box’s containing block, with any indefinite size assumed as infinity. If both dimensions are indefinite, the initial target rectangle is set to match the outer edges of the box were it stretch-fit sized. - ~boxの[ `max-width$p / `max-height$p ]は `none$v でない場合、 ~target矩形を[ 影響される次元において~boxの~margin~boxの “最大~size” 以下になる ]よう切詰める — すなわち、 ~boxが その[ 最大-横幅/最大-縦幅 ]に~sizeされたとするときの~margin~boxの~size。 (通常の【`~flow~layout$における】 `~boxを~sizeする規則@~CSS2J#visuren$ `CSS2$r と整合するよう、 この “最大~size” は,~boxの[ `min-width$p/`min-height$p ]の効果により切り上げられることに注意。) ◎ Next, if the box has a non-none max-width or max-height, the target rectangle is clamped in the affected dimension to less than or equal to the “maximum size” of the box’s margin box, i.e. the size its margin box would be if the box was sized at its max-width/height. (Note that, consistent with normal box-sizing rules, this “maximum size” is floored by the effects of the box’s min-width/min-height.)
- 一方の次元において,~target矩形を抑制する — ~boxの`選好d縦横比$に合致するために必要yな最小な分だけ。 ◎ Last, the target rectangle is reduced in one dimension by the minimum necessary for it to match the box’s preferred aspect ratio.
各~次元における包含して収まる~sizeは、 ~target矩形の中へ収まるよう伸張した結果の【`内容~box$の】~sizeになる。 ◎ The contain-fit size in each dimension is the size that would result from stretch-fitting into the target rectangle.
伸張して収まる~sizingによる`~margin相殺$に関する結果を,何であれ ここに複製する。 ◎ Copy whatever stretch-fit ends up doing wrt margin collapsing.
一方の次元において[ 縦横比が尊守されたとするとき、 ~target矩形を~overflowさせる最小~size ]が在る場合、[ 縦横比を尊守する, 画像を不均等に拡縮する ]どちらにするか? 前者の場合、[ 上の #2 に類似な,関連な最小を適用する段 ]が必要になる。 ◎ If there is a minimum size in one dimension that would cause overflow of the target rectangle if the aspect ratio were honored, do we honor the aspect ratio or skew the image? If the former, we need a step similar to #2 that applies the relevant minimums.
6.2. 百分率~sizing
…
7. 内在的~sizeを伴う計算-法: `calc-size^f 関数
[ 2 個の~sizeの合間で遷移する/ ある~sizeを少し調整する ]ことは、 それらの~sizeが `length-percentage$t として与えられたならば, `calc$f で容易に行えるが (例: `calc(50% + 10px)^v は、[ `100%^v, `20px^v ]の中間点になる)、 それらの~size — 遷移の場合はどちらかの~size — が数量-値でない場合には (例: `auto$v / `fit-content$v / `循環な百分率~size$), もはやアリでなくなる。 `CSS-SIZING-3$r ◎ Transitioning between two <length-percentage> sizes, or slightly adjusting one, can be done easily with calc(): halfway between 100% and 20px is calc(50% + 10px), for example.\ But these operations are no longer possible if the size you want to adjust or transition to/from is a non-numeric value such as auto or fit-content or a cyclic percentage size. [CSS-SIZING-3]
`calc-size@f 関数は、 これらの~sizeに対する[ ~math/遷移/~animation ]が[ 安全かつ きちんと定義された仕方で遂行されるようになること ]を許容する。 その構文は: ◎ The calc-size() function allows math and transition/animation to be performed on these sizes in a safe, well-defined way. Its syntax is as follows:
`calc-size()$t = calc-size( `calc-size-basis$t, `calc-sum$t ) `calc-size-basis@t = `size-keyword$t | `calc-sum$t | `calc-size()$t | `any$v
`calc-size$f 関数 %関数 の:
- 1 個目の引数は、 %関数 の `基底s@cS を与える。 それは、 %関数 が基づいている~sizeを表現する。
- 2 個目の引数は、 %関数 の `計算式@cS を与える。 それは、 %関数 が — その`基底s$cSに基づいて — 実際に解決される~sizeを表現する。
`size-keyword@t は、 当の関数を利用している文脈において許容される[ 任意の~sizing~keyword, それらに関係する~sizing関数 ]を表現する。 例えば, `width$p においては、[ `auto$v, `min-content$v, `stretch$v, 等々 ]に加えて,`fit-content$f 関数 (これは、 `fit-content$v ~keywordの~~変種である) も許容する。 ◎ ↓↓
いくつかの例 【~comment内の `auto^v は、[ `auto^v の使用~値 ]を意味する】: ◎ Some examples:
height: calc-size(auto, 0); /* `height^p の使用~値は `0^v になる ◎ used height is zero */ height: calc-size(auto, 50%); /* 使用~値は当の容器の 50% になる ◎ used height is 50% of the container */ height: calc-size(auto, size / 2); /* 使用~値は `auto^v の 50% になる ◎ used height is 50% of auto */ height: calc-size(auto, size); /* 使用~値は `auto^v になる ◎ used height is auto */ height: calc-size(auto, size + 10px); /* 使用~値は `auto^v ~PLUS `10px^v になる ◎ used height is auto + 10px */ height: calc-size(auto, round(up, size, 20px)); /* 使用~値は `auto^v 以上かつ それに最も近い `20px^v の整数倍へ丸めた結果になる ◎ used height is rounded up to the nearest multiple of 20px */ height: calc-size(any, size / 2); /* この宣言は無効 ◎ declaration is invalid */
`calc-size$f 関数 %関数 の`基底s$cS用の各種 値の意味は: ◎ The calc-size basis values are:
- `size-keyword$t
-
%関数 の~sizeは、 指定された~keyword %~keyword に基づいていることを指示する — すなわち:
- ~sizeを実際に解決すること以外のすべての目的においては、 %関数 は, %~keyword であったかのように動作する。
- %関数 の`計算式$cS内の `size$v ~keywordの値には、 対応している~size【 %関数 を利用している文脈の下で %~keyword を解決した結果】を利用することになる。
- `calc-sum$t
-
%関数 の~sizeは、 指定された`計算式$ %計算式 に基づいていることを指示する — すなわち:
- ~sizeを実際に解決すること以外のすべての目的においては (例えば、 %関数 が表現する~sizeが[ `確定的$, `不定$ ]どちらになるかも含めて)、 %関数 は, `calc$f 内に包装された %計算式 であったかのように動作する。
- %関数 の`計算式$cS内の `size$v ~keywordの値には、 対応している~size【 %関数 を利用している文脈の下で %計算式 を解決した結果】を利用することになる。
- `calc-size()$t
-
%関数 の~sizeは、 指定された %~calc-size_f に基づいていて, %~calc-size_f と同じ挙動を共有するようになることを指示する — すなわち:
- 【 ~sizeを実際に解決すること以外のすべての目的においては、[ %関数 の`基底s$cSに %~calc-size_f の`基底s$cSが指定された場合 ]と同じに動作する — それも `calc-size()$t であったなら、 再帰的に。 】
- %関数 の`計算式$cS内の `size$v ~keywordの値には、 %~calc-size_f を解決した結果【!の~size】を利用することになる。 【!不要:The size keyword is allowed...】
-
例えば, %関数 が `calc-size(calc-size(min-content, size / 2), size + 10%)^v であったなら、 %関数 は: ◎ For example, in calc-size(calc-size(min-content, size / 2), size + 10%),\
- %関数 の`基底s$cSは `min-content$v であったかのように動作する。 ◎ the outer calc-size() acts as if its calc-size basis was min-content,\
- %関数 の`計算式$cS内の `size$v に %~calc-size_f を解決した結果を利用して, その~sizeを計算することになる — `calc-size(min-content, size / 2 + 10%)^v と等価になるよう。 ◎ and will calculate its own size using the result of the inner calc-size(), equivalent to calc-size(min-content, size / 2 + 10%).
-
`calc-size$f は,なぜ入子にできるか? ◎ Why can calc-size() be nested?
`calc-size-basis$t 引数として `calc-size$f を許容することは、 作者は,基底sとして変数【 `var$f 】を利用できることを意味する ( `calc-size(var(--foo), size + 20px)^v の様に) — それは、 当の変数【 `var^f が参照する`~custom~prop$の値】が[ 元々,当の~prop用の値として妥当である場合 ]に限り,`常に働く^emことになる。 ◎ Allowing calc-size() as the basis argument means that authors can use a variable as the basis (like calc-size(var(--foo), size + 20px)) and it will always work as long as the variable was originally valid for the property.
同じことを `calc$f だけで行っても働かない — 例えば, `--foo^p の値に `calc-size(min-content, size + 20px)^v を指定した場合 (あるいは `min-content^v だけを指定した場合でも)、 `calc( (var(--foo)) + 20px )^v は失敗する。 ◎ Doing the same with just calc() doesn’t work - for example, if you have --foo: calc-size(min-content, size + 20px), or even just --foo: min-content, then calc( (var(--foo)) + 20px ) fails.
入子ngは[ 補間に先立って【!の間】/使用~値の時点 ]に単純~化され,消え去るので、 当の基底sは — 補間や他の効果が生じる時点に先立って — 常に,単純な値になる — `§ ~calc-size_fの単純~化-法@#simplifying-calc-size$ を見よ。 ◎ The nesting is simplified away during interpolation, and at used-value time, so the basis always ends up as a simple value by the time interpolation and other effects occur; see § 7.2.1 Simplifying calc-size().
- `any@v
- %関数 は追加的な情報には依存しないこと 【すなわち, %関数 が表現する~sizeは %関数 の`基底s$cSには依存しないこと】 — したがって,他の`どの~size^emとも補間できるようになること — を指示する。 %関数 は`確定的$な~sizeを表現する。 ◎ Indicates that the calc-size() does not depend on any additional information, and thus can be interpolated with any other size. The calc-size() function represents a definite size.
- %関数 の`計算式$cSは、 `size$v ~keywordを利用し得ない — 利用した場合、 構文~errorになる。 ◎ The calc-size calculation cannot use the size keyword; it is a syntax error for size to appear in the calc-size calculation.
- 注記: `calc-size(any, ...)^v は, `calc(...)^v と ほとんど一致するが、 `interpolate-size$p の値に関わらず, 他の~sizing~keywordと自動的に補間-可能になる。 (加えて、 包含塊の~sizeが`確定的$でない場合,百分率の扱いは少し異なる。) ◎ Note: calc-size(any, ...) is mostly identical to calc(...), but it is automatically interpolatable with other sizing keywords, regardless of the interpolate-size value. (It does treat percentages slightly differently, if the containing block’s size is not definite.)
-
~sizeを実際に解決すること以外のすべての目的(`内在的~size供与$も含む)においては、 %関数 は,その`計算式$cSの結果に解決される。
【 この記述は,原文では この~listの外(直後)に置かれているが、 だとすると `any$v 以外の値の定義と矛盾するので, ここに含められるべきであろう (おそらく,~markupの誤り)。 】
◎ For the purpose of sizing (including for intrinsic size contributions), calc-size() resolves to the result of its calc-size calculation.
どちらの引数も, `calc-sum$t が与えられた場合には: ◎ For either argument, if a <calc-sum> is given,\
- その`型$は `length-percentage$t に`合致して$いなければナラナイ。 ◎ its type must match <length-percentage>,\
- それを `length$t 値に解決するモノトスル。 `CSS-VALUES-4$r `§ 型の検査-法@~CSSVAL#calc-type-checking$ を見よ。 ◎ and it must resolve to a <length>. See CSS Values 4 § 10.9 Type Checking.\
- それは、 `calc$f の様に,当の【 `calc-size$f 関数を利用した】~propの`計算~文脈$を継承する。 ◎ Like calc(), it inherits the property’s calculation context.\
しかしながら, `calc-size$f は、 特定的に `length$t `ではない^em — `calc-size^f を受容するよう求まれる箇所は,どこであれ、 その文法~内にそれを明示的に含めなければナラナイ。 ◎ However, a <calc-size()> is specifically not a <length>; any place that wants to accept calc-size() must explicitly include it in its grammar.
`calc-size$f 関数の`計算式$cSの中の `size@v ~keywordは、 `length$t 型の `calc-keyword$t である【ものと定義される】 — それは、 `使用~値$の時点で上で指定した~sizeへ解決される。 ◎ Within the calc-size calculation, the size is a <calc-keyword> which is a <length>, and resolves at used value time to the size specified above.
なぜ `calc$f 内に内在的~size~keyword【`内在的~size$を表現する~keyword】を許容するだけは済まないのか? ◎ Why not just allow intrinsic keywords in calc()?
理論~上は、 `calc-size$f を導入することなく — 補間が通常通り働くことを許容するために — `calc(auto * .5)^v が妥当になるよう定義することもできた。 ◎ In theory, rather than introducing calc-size(), we could have defined calc(auto * .5) to be valid, allowing interpolation to work as normal.
が、 これには,明白とは言えない小さな課題 — 複数の~keywordを併用することは、 依然として許容されないこと — がある (すなわち、 `calc((min-content + max-content)/2)^v は適理に見えるが,許容されない)。 ◎ This has the minor issue that mixing keywords still wouldn’t be allowed, but it wouldn’t be as obvious (that is, calc((min-content + max-content)/2) looks reasonable, but would be disallowed).
より大きな課題は、 これが百分率を滑らかに遷移することを許容しないことにある。 `calc(50%)^v は、 当の文脈において百分率が`確定的$になるときは, `calc(100%)^v が成す~sizeの半分になるが、 そうでない場合には,通例的に `calc(100%)^v と同じ~sizeになる (当の文脈に依存して, `0px^v になるか `auto$v で~sizeされる)。 ◎ The larger issue, though, is that this wouldn’t allow us to smoothly transition percentages. calc(50%) is only half the size of calc(100%) when percentages are definite in the context; if they’re not, the two values will usually be the same size (depending on the context, either 0px or auto-sized).
新たな関数として[ 計算-対象の~sizeを計算式~自体から明示的に分離するもの ]を利用すれば、 `すべての事例^emで,滑らかな補間が得られるようになる。 ◎ Using a new function that explicitly separates the size you’re calculating against from the calculation itself lets us get smooth interpolation in all cases.
追加的な考慮として、[ ある要素が内在的に~sizeされるか`確定的$な~sizeになるかに依存して,~sizeが変わる ]ような効果は,いくつもある (例えば,`~margin相殺$)。 `calc$f を利用することは、 “要素は内在的に~sizeされたか?” という問いに対する答えが, ある遷移の途中と終端で異なることを意味する (【 `min-content^v から `20px^v へ遷移させる事例では、】 途中【進捗~率 0.8 の時点】では `calc(min-content * .2 + 20px * .8))^v になり, “はい” になる一方で、 終端では `calc(20px)^v になり, “いいえ” になる)。 その結果、 他では滑らかな遷移が,終了~時には~layoutが急変する。 ◎ An additional consideration is that there are many effects, some small and some large, that depend on whether an element is intrinsically sized or definite. Consider, for example, margin collapsing. Using calc() would mean that the answer to the question “is the element intrinsically-sized” can have one answer in the middle of a transition (“yes”, for calc(min-content * .2 + 20px * .8))), but a different answer at the end of the transition (“no”, for calc(20px)), causing the layout to jump at the end of an otherwise-smooth transition.
この課題は、 `opacity$p を `1^v から `0^v へ~animateするときに生じ得る積層~層の変化に類似する ( `1^v 以外の値は積層~文脈を強制するが, `1^v はそうしない) — この事例では、 `opacity$p を `.999^v (視覚的に `1^v と判別-不能でありつつ積層~文脈を強制する値)から `0^v 【!1 から .999 】へ~animateすることにより対処できるが。 それでも、[ `内在的~size$であるか否かを維持することを確保する ]ために[ `calc(auto * .0001)^v へ~animateするよう人々に依頼すること ]は,適理とは言えない。 ◎ (This issue is similar to the stacking-layer changes that can occur when animating from opacity:1 to opacity: 0: any non-1 value forces a stacking context, but 1 does not. With opacity you can get around this by animating to .999, which is visually indistinguishable from 1 but forces a stacking context. It’s not as reasonable to ask people to animate to calc(auto * .0001) to ensure it retains its intrinsic-ness.)
`calc-size(auto, 20px)^v の様に,[ 自身が名目上は`内在的~size$であるもの ]として識別される新たな関数を利用することは、[ 実際の~sizeが確定的な長さであるとき ]でも[ ~layoutの挙動が時間~全体にわたり安定になるよう保守できる ]ことを意味する。 ◎ Using a new function that identifies itself as nominally being a keyword size, like calc-size(auto, 20px), means we can maintain stable layout behaviors the entire time, even when the actual size is a definite length.
7.1. `calc-size^f の解決-法
`calc-size$f 関数は、 `使用~値$の時点より前に解決される【!or simplified】ことはない ( `§ ~calc-size_fの補間-法@#interpolate-calc-size$ を見よ)。 ◎ Before used value time, calc-size() functions are not resolved or simplified. (But see § 7.2 Interpolating calc-size().)
`calc-size$f 関数の`計算式$cSは、 `calc$f 式の値と同様に, `使用~値$の時点で解決される — 当の計算式~内の `size$v ~keywordへ当の関数の`基底s$cSの使用~値を代入して, 各~百分率を [ それが`確定的$であるならば 通常に/ 他の場合は `0px^v を~~基準に ]評価することにより。 ◎ At used value time, the calc-size calculation is resolved just like the value of a calc() expression, by substituting in the used value of the calc-size basis for the size keyword in the calc-size calculation, and evaluating any percentages normally (if they are definite) or against 0px (if they are not).
注記: `calc-size^f の`基底s$cS内の百分率は, 通常通り解決されるので、 常に,`どの~size^emへも — その値や挙動に関わらず — 滑らかに遷移させれる。 例えば, `calc-size(100%, size)^v と `calc-size(100%, 0px)^v を滑らかに補間することは、 保証され, `calc-size(100%, size * .5)^v の様な中間的な値を生産する。 `calc-size$f を伴わない下では、 `100%^v から `0px^v への補間が期待されるとおりに働くのは, 当の百分率が`確定的$になる場合に限られる — 他の場合、 `calc(50%)^v の様な中間的な値は,すべて`~autoとして挙動する$かもしれず、 そうなる場合,~sizeは まったく変化しなくなる。 ◎ Percentages in the calc-size basis resolve as normal so you can always smoothly transition to any size, regardless of its value or behavior. For example, calc-size(100%, size) is guaranteed to interpolate smoothly with calc-size(100%, 0px), producing intermediate values like calc-size(100%, size * .5). Without calc-size(), interpolation from 100% to 0px only works as expected if the percentage is definite; otherwise, the intermediate values like calc(50%) might all behave as auto and not change size at all.
他方, `calc-size$f の`計算式$cS内の百分率は、[ 当の関数が 2 つの異なる仕方で動作するようになり得ること ]を避けるため, 他では`不定$になるときには `0px^v に解決される。 例えば,[ `min-content$v ~size, `100%^v ~size ]による~layout効果は異なる結果になる事例もあり、 そこでの `calc-size^f は,どちらか一方の挙動を~commitする必要がある。 ◎ Percentages in the calc-size calculation, on the other hand, are resolved to 0px when they would otherwise be indefinite, to avoid making the calc-size() potentially act in two different ways. There are some cases where a min-content size, for example, will cause different layout effects than a 100% size, and so a calc-size() has to commit to one behavior or the other.
7.2. `calc-size^f の補間-法
2 個の `calc-size$f 関数 %A, %B を補間する~algoは、[ `失敗^i (補間できないことを意味する)/ ある `calc-size$f (補間した結果) ]を返す:
- %A ~SET `~calc-size_fを補間~用に準備する$( %A )
- %B ~SET `~calc-size_fを補間~用に準備する$( %B )
- ~IF[ %A ~EQ `失敗^i ]~OR[ %B ~EQ `失敗^i ] ⇒ ~RET `失敗^i
- %基底s ~LET %A の`基底s$cS
-
~IF[ %基底s ~NEQ %B の`基底s$cS ]:
- ~IF[ %基底s ~EQ `any$v ] ⇒ %基底s ~SET %B の`基底s$cS
- ~ELIF[ %B の`基底s$cS ~NEQ `any$v ] ⇒ ~RET `失敗^i
注記: この段は、[ `calc-size$f が,同時に 2 つの異なる仕方で動作するよう試行しない ]ことを確保する。 例えば,[ `min-content$v, `max-content$v ]が~layoutに対し異なる挙動を生産する事例もあるので、 `calc-size^f は,どちらか一方として装う必要がある。 あいにく,このことは、 `auto$v から `min-content^v へ行く様な~keywordどうしでは遷移し得ないことを意味する。
- %計算式 ~LET %A, %B の`計算式$cSを補間した結果
- ~RET 新たな `calc-size$f 関数 — その ⇒# `基底s$cS ~SET %基底s, `計算式$cS ~SET %計算式
`calc-size$f 関数は、[ `length-percentage$t / `size-keyword$t ] %値 とも補間し得る。 [ これらの値を補間できるかどうか, できる場合の補間の挙動 ]を決定するときは、 %値 を次に与える `calc-size^f として扱う下で,上の~algo【!規則】を適用する: ◎ Some calc-size() values can also be interpolated with a <length-percentage> or an <size-keyword>. To determine whether the values can interpolate and what the interpolation behavior is, treat the non-calc-size() value as\
-
%値 は `calc-sum$t として与えられた場合
⇒
calc-size(`any$v, %値 )◎ calc-size(any, value ) if the value is a <calc-sum>\ -
他の場合
⇒
calc-size( %値, `size$v)◎ or as calc-size( value , size) otherwise, and apply the rules above.
例えば、 `height$p においては, `calc-size$f と `auto^v の補間は許容される: ◎ For example, calc-size() allows interpolation to/from height: auto:
details {
transition: height 1s;
}
details::details-content {
display: block;
}
details[open]::details-content {
height: auto;
}
details:not([open])::details-content {
height: calc-size(any, 0px);
}
これは、 暗黙的に[ `calc-size(auto, size)^v, `calc-size(any, 0px)^v ]の合間を補間することになる。 `details$e を開いてから 0.5 秒~後には、 `details-content$pe の `height$p は, 開な~sizeの半分 `calc-size(auto, size * .5)^v になり、 その縦幅は,遷移~全体を通して滑らかに~animateすることになる。 ◎ This will implicitly interpolate between calc-size(auto, size) and calc-size(any, 0px). Half a second after opening the details, the ::details-content wrapper’s height will be calc-size(auto, size * .5), half its open size; thruout the transition it’ll smoothly animate its height.
注記:
これらの規則は、
calc-size(any, ある`確定的$な長さ )
と他の何かとの補間が
— 他の何かがどう指定されたかに関わらず —
`常に^em滑らかになることを許容する。
◎
Note: These rules allow calc-size(any, definite length) to always interpolate smoothly, regardless of how the other side of the transition is specified.
注記: 上述した “素な %値 を `calc-size$f へ昇格する” 挙動は、 昇格された `calc-size^f の`計算式$cSの中へ %値【!`length-percentage$t】 を置く。 このことは、 %値 が百分率を伴う場合でも,[ %値 と内在的~size~keywordを補間すること ]を許容するが、[ 百分率が`確定的$でないときには、 当の百分率は 0 へ解決されるようになる ]ことを意味する。 作者は,[ 百分率が当の要素の実際の~sizeを~~基準に解決されるようになる ]ことを求めるなら、 `基底s$cSとして %値 を伴う `calc-size^f を明示的に与えること — `calc-size(50%, size)^v の様に。 ◎ Note: This "upgrade a plain value into a calc-size()" behavior puts <length-percentage> values into the calc-size calculation. This allows values with percentages to interpolate with intrinsic size keywords, but does mean that when a percentage isn’t definite, it’ll resolve to zero. If you want to resolve to the actual size the percentage would make the element, explicitly write a calc-size() with the value in its calc-size basis, like calc-size(50%, size).
7.2.1. `calc-size^f の単純~化-法
`calc-size$f 関数の[ `基底s$cS( `calc-sum$t である場合に限る), `計算式$cS ]は、 `~math関数$と同じく, `指定d値$の時点で`単純~化$され, `算出d値$の時点でさらに`単純~化$される。 ◎ Identically to math functions, the calc-size calculation (and calc-size basis, if it’s a <calc-sum>) of a calc-size() function is simplified at specified value and computed value time.
`calc-size$f 関数どうしは、 `補間$の前に[ 互いの`基底s$cSを比較でき, 互いの`計算式$cSを適正に補間できる ]よう,どちらも`補間~用に準備-@#calc-size-prepare-for-interpolation$される。 この処理nは、 計算式~treeを`単純~化$することより多くのものを孕むので, 失敗することもある。 ◎ Before interpolation, calc-size() functions are prepared for interpolation so their calc-size basises can be compared, and their calc-size calculations can be interpolated properly. This is a more involved process than simplifying a calculation tree, and can potentially fail.
`~calc-size_fを補間~用に準備する@ ~algoは、 所与の ( `calc-size$f 関数 %関数 ) に対し: ◎ To prepare for interpolation a calc-size() function:
- %挿入~値 ~LET ε ◎ ↓
- %基底s ~LET %関数 の`基底s$cS ◎ ↓
-
~IF[ %基底s は `calc-size$f 関数である ]:
- %内縁~関数 ~SET `~calc-size_fを補間~用に準備する$( %基底s )
- ~IF[ %内縁~関数 ~EQ `失敗^i ] ⇒ ~RET `失敗^i
- %挿入~値 ~SET %内縁~関数 の`計算式$cS
- %基底s ~SET %内縁~関数 の`基底s$cS
-
~ELIF[ %基底s は `calc-sum$t である ]:
-
~IF[ %基底s の`型$は `length$t に`合致して$いる ]:
- %挿入~値 ~SET %基底s
- %基底s ~SET `any$v
-
~ELSE( %基底s は百分率を包含している):
- %挿入~値 ~SET `~calc-size_fの計算式を非~百分率~化する$( %基底s )
- %基底s ~SET `100%^v
-
- %計算式 ~LET %関数 の`計算式$cS ◎ ↓
-
~IF[ %挿入~値 ~NEQ ε ]:
- %計算式 ~SET `~calc-size_fの計算式の中へ代入する$( %計算式, %挿入~値 )
- ~IF[ %計算式 ~EQ `失敗^i ] ⇒ ~RET `失敗^i
- %計算式 ~SET %計算式 を `CSS-VALUES-4$r `§ 単純~化@~CSSVAL#calc-simplification$ にて定義されるとおりに単純~化した結果 ◎ Next, simplify the calc-size calculation as defined in CSS Values 4 § 10.10.1 Simplification.
- ~RET 新たな `calc-size$f 関数 — その ⇒# `基底s$cS ~SET %基底s, `計算式$cS ~SET %計算式 ◎ ↑
注記: 結果の `calc-size$f 関数の`基底s$cSは、[ ~keyword/ `100%^v ]になる。 ◎ Note: After simplification, the calc-size basis of a calc-size() function will either be a single keyword or the value 100%.
`~calc-size_fの計算式の中へ代入する@ ~algoは、 所与の ( `calc-sum$t【!`計算式$cS】 %計算式, 値 %挿入~値 ) に対し: ◎ To substitute into a calc-size calculation calc a value insertion value:
- ~IF[ %計算式 内には `size$v ~keywordは無い ] ⇒ ~RET %計算式 ◎ If calc doesn’t have the size keyword in it, do nothing.
- %代入-済み計算式 ~LET %計算式 内の各 `size$v ~keywordを[ 丸括弧で括られた %挿入~値 ]に置換した結果 ◎ Otherwise, replace every instance of the size keyword in calc with insertion value, wrapped in parentheses.
-
~IF[ %代入-済み計算式 は,~UA定義な上限を超える値を生産する ] ⇒ ~RET `失敗^i ◎ If this substitution would produce a value larger than an UA-defined limit, return failure.
注記: これは、[ 変数の代入 ]用に定義される[ 代入に対する攻撃に抗する保護 ]と意図的に一致する — 【!`CSS-VARIABLES-1$r】`§ 長過ぎな代入に対する安全な取扱い@#long-substitution$ を見よ。 しかしながら、 `calc-size$f 値が ごく長くなる利用事例は,`~custom~prop$よりもずっと少ないので、 ~UAは,より低い~size上限を課すよう望むかもしれない。 ◎ Note: This is intentionally identical to the protection against substitution attacks defined for variable substitution; see CSS Variables 1 § 3.3 Safely Handling Overly-Long Variables. However, the use-cases for very long calc-size() values are much less than for long custom properties, so UAs might wish to impose a smaller size limit.
- ~RET %代入-済み計算式 ◎ ↑
`~calc-size_fの計算式を非~百分率~化する@ ~algoは、 所与の ( `calc-sum$t【!`計算式$cS】 %計算式 ) に対し: ◎ To de-percentify a calc-size calculation calc:
-
%計算式 を成す ~EACH( `percentage-token$t %百分率~token ) に対し:
- %N ~LET %百分率~token の.値 ~DIV 100
- %計算式 の中の %百分率~token を `(size * N)^v に置換する
- ~RET %計算式 ◎ Return calc.
注記: 例えば, `50% + 20px^v は、 `(size * .5) + 20px^v になる。 ◎ Note: For example, 50% + 20px becomes (size * .5) + 20px.
百分率は、 なぜ,この仕方で単純~化されるか? ◎ Why are percentages simplified in this way?
この単純~化は、 遷移が線形に働くことを確保する。 ◎ This percentage simplification ensures that transitions work linearly.
例えば, `100%^v は `100px^v に解決されるとする。 ◎ For example, say that 100% resolves to 100px.
`calc-size(100px, size * 2)^v ( `200px^v に解決される) から `calc-size(50%, size - 20px)^v ( `30px^v に解決される) へ[ 両~引数(`基底s$cS, `計算式$cS)とも補間してから、 結果の `calc-size^f の[ 基底s, 計算式 ]に対し,計算式の中へ基底sを代入する ]ことにより遷移させた場合、 中間点では `calc-size(75px, size * 2 * .5 + (size - 20px) * .5)^v ( `102.5px^v へ解決される) になるが, それは `30px^v から `200px^v までの中間点( `115px^v )`ではない^em。 そのように補間すると、 一般に,`二次^emな補間の挙動を与える~FN。 ◎ If you transitioned from calc-size(100px, size * 2) (resolves to 200px) to calc-size(50%, size - 20px) (resolves to 30px) by interpolating both the arguments, then at the halfway point you’d have calc-size(75px, size * 2 * .5 + (size - 20px) * .5) (resolves to 102.5px), which is not halfway between 30 and 200 (that would be 115px). Interpolating one argument, then substituting it into another calculation and interpolating that one too, generally gives quadratic interpolation behavior.
【~FN `size$v ~keywordによる寄与に進捗~率が重ねて乗算され, 結果は進捗~率の二次式になる。 】
代わりに、 まず,【両 `calc-size^f に対し】基底s引数を計算式~引数の中へ代入する — その結果は `calc-size(any, 100px * 2)^v, `calc-size(100%, (size * .5) - 20px)^v になる。 これらを中間点で補間した結果は、 `calc-size(100%, 100px * 2 * .5 + ((size * .5) - 20px) * .5)^v になる — それは、 期待されるとおり,~~実際に `115px^v に解決される。 遷移における他の地点も類似に線形になる。 ◎ Instead, we substitute the basis arg into the calculation arg, so you get calc-size(any, 100px * 2) and calc-size(100%, (size * .5) - 20px), and when interpolated, at the halfway point you get calc-size(100%, 100px * 2 * .5 + ((size * .5) - 20px) * .5), which does indeed resolve to 115px, as expected. Other points in the transition are similarly linear.
7.3. ~sizing~keywordの自動的な補間-法: `interpolate-size^p ~prop
この~propは、 `~sizing~prop$に対し, ~keyword値を `length-percentage$t 値と滑らかに結合することを許容する — そのような事例~用に`離散的$な~animation【! (See Web Animations § 5.2 Animating properties.)】を利用することなく。 ◎ This property allows keywords on the sizing properties to smoothly combine with <length-percentage> values rather than using discrete animation for this case. (See Web Animations § 5.2 Animating properties.)
- `numeric-only@v1
- `size-keyword$t と結合できるものは、 それと互換な `calc-size$f に限られる。 ◎ A <size-keyword> can only be combined with a compatible <calc-size()>.
- `allow-keywords@v1
-
`~sizing~prop$用の値どうしは、[
一方が `size-keyword$t, 他方が `length-percentage$t
]である場合には,結合できる。
これは、
所与の `size-keyword$t %~keyword に対し,[
%~keyword は
calc-size(%~keyword, size)であった ]かのように扱う下で[ `calc-size$f の`補間-法@#interpolate-calc-size$を適用する ]ことにより行われる。 他の事例においては、 `size-keyword$t は,依然として補間できない。 ◎ Sizing values can also be combined if one of them is an <size-keyword> and the other is a <length-percentage>. This is done by treating the <size-keyword> keyword as though it is calc-size(keyword, size) and applying the rules in § 7.2 Interpolating calc-size(). In other cases, a <size-keyword> still cannot be interpolated.
注記: `allow-keywords$v1 に設定することは, `ほとんどの^em ~size値が補間されるようになることを許容するが、 すべてではない — 異なる~keywordどうしは、 依然として,補間-可能にならない。 ~layout~algoは、[ 子孫が精確に どの~sizing~keywordを利用しているか ]に基づいて, それらの挙動を[ 補間の間には表現し得ない仕方 ]で変更し得るので。 ◎ Note: Setting allow-keywords allows most size values to be interpolated, but not all; different keywords are still not interpolable with each other, as layout algorithms can change their behavior based on precisely which sizing keyword a descendant is using, in a way that can’t be represented during interpolation.
注記: `allow-keywords$v1 を設定することは, `calc-size$f を手動で利用する必要を `ほとんど^em 除去するが、 それでも,それを利用することに便益がある事例はある。 例えば,`包含塊$の~sizeが`不定$である場合、 `width$p を `100%^v から `0px^v へ素朴に補間しても, 期待されるとおりには働かない (中間的な値は,`~autoとして挙動する$かもしれず、 その場合,それらの値は `100%^v と同じ~sizeになるので)。 一方で, `width^p に手動で[ `calc-size(100%, size)^v / `calc-size(any, 0px)^v ]を書いたなら、 これらの値の合間で滑らかに補間されるようになる。 ◎ Note: Setting allow-keywords mostly removes the need to use calc-size() manually, but there are still some cases that can benefit from using it. For example, if the containing block size is indefinite, naively interpolating width: 100% to width: 0px won’t work as expected (since the intermediate values might behave as auto, making them the same size as 100%), but manually writing width: calc-size(100%, size); and/or width: calc-size(any, 0px); will, causing the element to smoothly interpolate between the two values.
注記: 過去へ戻れたなら、 この~propは存在しなかった。 `allow-keywords$v1 の挙動は、 既定では どう働くかを変えるだけである。 これが存在するのは、 既存の多くの~stylesheetが[ ~sizing~keyword( `auto$v, `min-content$v, 等々)をまったく補間し得ない ]ものと見做すからであり,[ それらを補間することにした場合,非互換化された挙動を生産することになる ]からである。 この前提との互換性を得るため、 この補間を許容することには,~opt-inが要求される。 この~propは継承されるので、 根~要素の `interpolate-size^p に `allow-keywords$v1 を指定すれば, 新たな挙動を~page全体に許容する。 互換性が課題にならない所では、 そうすることが示唆される。 ◎ Note: If we had a time machine, this property wouldn’t exist; the allow-keywords behavior would just be how things worked by default. It exists because many existing style sheets assume that the sizing keywords (auto, min-content, etc.) cannot interpolate at all, and would produce broken behavior if they started interpolating. For compatibility with this assumption, allowing this interpolation requires an opt-in. Because the property inherits, specifying :root { interpolate-size: allow-keywords; } allows the new behavior for the entire page. We suggest doing this wherever compatibility isn’t an issue.
`interpolate-size$p の値が問われる時点, それを問うものは、 当の要素の【他の~propの】~animationが開始するかもしれない時点における, その`算出d値$である。 ~CSS遷移~用には、 これは,`変化-後~style$における値を意味する。 ~animationは、 その後に `interpolate-size^p が変化しても[ 停止される/開始される ]ことはない。 ◎ The value of interpolate-size that matters is the computed value on the element at the time the animation might start. For CSS transitions, this means the value in the after-change style. An animation is not stopped or started later because interpolate-size changes.
変更点
【 変更箇所の引用は省略する。 】
- `2026年 9月 4日 作業草案@~TR/2026/WD-css-sizing-4-20260904/$ からの有意な変更点 ◎ Changes since 4 September 2026 Working Draft ◎ Significant changes since the 4 September 2026 Working Draft include:
- `stretch$f 関数-記法を追加して、 それを利用するよう, `fit-content$f を定義し直した。 ( `5715$issue ) ◎ Added the stretch() functional notation and redefined fit-content() to use it. (Issue 5715)
- 循環な百分率と `fit-content$f との相互作用を明確化した。 ( `11805$issue ) ◎ Clarified interaction of cyclic percentages and fit-content(). (Issue 11805)
- [ `calc-size$f 関数, `interpolate-size$p ~prop ]を `css-values-5$r から移動した。 ( `14502$issue ) ◎ Transferred the calc-size() function and interpolate-size property from [css-values-5]. (Issue 14502)
- `2021年 5月 5日 作業草案からの@~TR/2021/WD-css-sizing-4-20210520/$ からの有意な変更点 ◎ Changes since 5 May 2021 Working Draft ◎ Significant changes since the 5 May 2021 Working Draft include:
- [ `size$p, `min-size$p, `max-size$p ]`略式~prop$を追加した。 ( `820$issue ) ◎ Added the size, min-size, and max-size shorthand properties. (Issue 820)
- `~sizing~prop$用の値として `calc-size$f 【!~TR/css-sizing-4/#funcdef-width-calc-size】を追加した。 ( `6265$issue ) ◎ Added calc-size() to the sizing properties. (Issue 6265)
- `frame-sizing$p ~propの定義を追加した。 ( `1771$issue ) ◎ Added frame-sizing property definition. (1771)
- `~level 3$ から `fit-content$v の~~発展形 `fit-content$f を~importして, `stretch^v を `~level 3$ へ戻した。 ( `10601$issue ) ◎ Imported fit-content() from Level 3, graduated fit-content and stretch back down to Level 3. (Issue 10601)
- 各種~sizing値を~~統合するため、 `box-size$t 生成規則を導入した。 ( `13478$issue ) ◎ Introduced <box-size> grammar production to consolidate sizing values. (Issue 13478)
- `contain-intrinsic-size$p1 における値たちの並替ngを許容しないようにした。 ( `6391$issue ) ◎ Disallowed re-ordering of values in contain-intrinsic-size. (Issue 6391).
- `最後に記憶した~size$は,幻な~sizeを避けるため、[ 各種 `contain-intrinsic-*^p ~prop用の値 `auto$v1 ]に限り,[ 当の要素が自身の内容を飛ばしているとき ]に限り利用されるようにした。 ( `6308$issue ) ◎ Only used the last remembered size for the auto value of the contain-intrinsic-* properties when the element is skipping its contents to avoid phantom sizes. (Issue 6308).
- どの要素が, いつ`最後に記憶した~size$を取得するかを明確化した。 ( `6220$issue ) ◎ Clarify which elements get a last remembered size and when. (Issue 6220)
- `contain-intrinsic-size$p ~prop用に論理-~prop~groupを追加した。 ( `2822$issue ) ◎ Added logical property group for contain-intrinsic-size properties. (Issue 2822).
- `contain-intrinsic-size$p の構文を もっと柔軟な値たちの組合nを許容するよう変更した。 ( `8407$issue ) ◎ Changed syntax of contain-intrinsic-size to allow for more flexible combinations of values. (Issue 8407).
- 各種 `contain-intrinsic-*^p ~propにおいて,負な長さを許容しないようにした。 ( `11945$issue ) ◎ Disallowed negative lengths in contain-intrinsic-* properties. (Issue 11945).
- `§ 応答可能に~sizeされる~iframe_e@#responsive-iframes$ を追加した。 ( `1771$issue ) ◎ Added responsively-sized iframes via 'contain-intrinsic-size/from-element' value. (Issue 1771).
- ~flex~layoutにおける`伸張して収まる~size$の挙動を — `stretch@~CSSALIGN#valdef-align-self-stretch$v から少し異なるよう — 明確化した。 ( `11784$issue ) ◎ Clarified that Flexbox’s stretch-fit sizing behavior is slightly different from stretch. (Issue 11784).
- `Web Platform Tests coverage^en を追加した。 ◎ Added Web Platform Tests coverage.
- その他の様々な細かな編集上の修正点と改善。 ◎ Various other minor editorial fixes and improvements.
- `2020年 10月 20日 作業草案@~TR/2020/WD-css-sizing-4-20201020/$ からの有意な変更点 ◎ Changes since 20 October 2020 Working Draft ◎ Significant changes since the 20 October 2020 Working Draft include:
- ~scroll容器の最小-内容~供与をより良く制御するため, `min-intrinsic-sizing$p ~propを草案化した。 ( `1865$issue, `4585$issue ) ◎ Drafted min-intrinsic-sizing property, to better control the min-content contributions of scroll containers. (Issue 1865, Issue 4585)
- 各~軸を独立に制御するため, `contain-intrinsic-size$p に下位propを追加した。 ( `5432$issue ) ◎ Added longhands to contain-intrinsic-size for controlling each axis independently. (Issue 5432)
- 以前に計算した~sizeを “記憶しておける” ようにするため、 `contain-intrinsic-size$p 用の値 `auto$v を草案化した。 ( `5668$issue, `5815$issue ) ◎ Drafted auto value to contain-intrinsic-size to allow “remembering” the previously-calculated size. (Issue 5668, Issue 5815)
- `aspect-ratio$p における`退化な比率$の取扱いを定義した。 ( `5557$issue ) ◎ Defined handling of degenerate ratios in aspect-ratio. (Issue 5557)
- `aspect-ratio$p が置換d要素の生来な~sizeにどう影響iするか定義した。 ( `5306$issue ) ◎ Defined how aspect-ratio impacts a replaced element’s natural sizes. (Issue 5306)
- `§ 最小-/最大-~sizeの転換-法@#aspect-ratio-size-transfers$ における誤りを修正して,その挙動を[ `CSS2$r, ~flex~layout, 等々 ]に定義される挙動に競合しないよう揃えた。 ( `6071$issue ) ◎ Fixed some errors in the § 4.4 Min/Max Size Transfers section, aligning the behavior to not conflict with behavior defined by CSS2 / CSS Flex Layout / etc. (Issue 6071)
- `contain-intrinsic-size$p 用の構文に, `auto none^v を追加した。 ◎ Added contain-intrinsic-size: auto none syntax.
- `2020年 5月 26日 最初の公な作業草案@~TR/2020/WD-css-sizing-4-20200526/$ からの有意な変更点 ◎ Significant changes since the 26 May 2020 First Public Working Draft include:
- `縦横比に依存しない軸$を用語として定義した。 ◎ Define ratio-determining axis as a term.
- [ 最小-/最大- ]~sizing拘束は、 縦横比( `aspect-ratio$p )を通して転換されるものと定義した。 ( `5257$issue ) ◎ Define that min/max sizing constraints are transferred across an aspect-ratio, (Issue 5257) ◎ Additionally, sizing constraints in either axis (the origin axis) are transferred through the preferred aspect ratio to the other axis (the destination axis) as follows: • First, any definite minimum size is converted and transferred from the origin to destination axis. This transferred minimum is capped by any definite preferred or maximum size in the destination axis. • Then, any definite maximum size is converted and transferred from the origin to destination. This transferred maximum is floored by any definite preferred or minimum size in the destination axis as well as by the transferred minimum, if any. ◎ Note: The basic principle is that sizing constraints transfer through the aspect-ratio to the other side to preserve the aspect ratio to the extent that they can without violating any sizes specified explicitly on that affected axis.
- `置換され$る要素のうち,`生来な~size$を片方しか伴わないものに対しては、 `aspect-ratio$p が他方の寸法を決定することを明確化した。 ( `5306$issue ) ◎ Clarify that aspect-ratio on a replaced element with only one natural size determines the other dimension. (Issue 5306) ◎ If a replaced element’s only natural dimension is a natural width or a natural height, giving it a preferred aspect ratio also gives it a natural height or width, whichever was missing, by transferring the existing size through the preferred aspect ratio.
- `aspect-ratio$p は~marginの自己-相殺を妨げるものと定義した ( `5328$issue ) ◎ Define that aspect-ratio inhibits margin self-collapsing (Issue 5328) ◎ For the purpose of margin collapsing (CSS 2 § 8.3.1 Collapsing margins), if the block axis is the ratio-dependent axis, it is not considered to have a computed block-size of auto.
- `~level 3$ に対する追加 ◎ Additions Since Level 3
- `~sizing~prop$用に[ `fit-content$f 関数, `contain$v ~keyword ]を追加した。 ◎ Added fit-content() function and contain keyword for sizing properties.
- `aspect-ratio$p ~propを追加した。 ◎ Added aspect-ratio property.
- 次に挙げる~propを追加した ⇒# `contain-intrinsic-width$p, `contain-intrinsic-height$p, `contain-intrinsic-block-size$p, `contain-intrinsic-inline-size$p, `contain-intrinsic-size$p (これらの略式) ◎ Added contain-intrinsic-width, contain-intrinsic-height, contain-intrinsic-block-size, and contain-intrinsic-inline-size properties and their shorthand contain-intrinsic-size.
- `contain-intrinsic-size$p ~propを追加した。 ◎ Added contain-intrinsic-size property.
- `frame-sizing$p ~propを追加した。 ◎ Added frame-sizing property.
謝辞
この~moduleの策定に貢献された `Aaron Gustafson^en, `L. David Baron^en 両氏に。 ◎ Special thanks go to Aaron Gustafson, L. David Baron for their contributions to this module.
~privacyの考慮点
この仕様が導入する新たな~privacyの考慮点は無い。 ◎ This specification introduces no new privacy considerations.
~securityの考慮点
この仕様が導入する新たな~securityの考慮点は無い。 ◎ This specification introduces no new security considerations.