CSS による封じ込め — CSS Containment Module Level 2

1.1. ~module間の相互作用

この文書は、 以前の仕様には無い新たな特能を定義する。 加えて、 安定的になったときは， `CSS-CONTAIN-1$r を置換して それに取って代わることを目指す。 ◎ This document defines new features not present in earlier specifications. In addition, it aims to replace and supersede [CSS-CONTAIN-1] once stable.

1.2. 値~定義

【 この節の内容は `~CSS日本語訳 共通~page＠~CSScommon#values$に移譲。 】

3.1. ~size封込め

%要素 に対する `~size封込め@ （ `size containment^en ）は、 %要素 の`首要~box$ %~box を `~size封込め~box@ にする — それには、 次に挙げる効果がある： ◎ Giving an element size containment makes its principal box a size containment box and has the following effects:

• %~box の`内在的~size$は、 内容が無かったかのように決定する — `空であるかのように~sizeする$ときと同じ~logicに従って。 ◎ The intrinsic sizes of the size containment box are determined as if the element had no content, following the same logic as when sizing as if empty.

  注記： これは、［ `min-content$v ／ `max-content$v ］~keyword, および［ それらの測定に依存する計算 ］の明示的な呼出nに影響する — ［ 中に駒として %~box が配置される`格子~筋$ ］を~sizeするときや， %~box の親を`内容が収まる~size$で~sizeするときなど。 ◎ Note: This affects explicit invocations of the min-content or max-content keywords, as well as any calculation that depends on these measurement, such as sizing grid tracks into which a size contained item is placed, or if fit-content sizing the containment box’s parent.

• %~box とその内容は、 概念的には，次の 2 ~~段階を経て~lay-outされる： ◎ Laying out a size containment box and its content is conceptually done in two phases:

  `空であるかのように~sizeする@ （ `sizing as if empty^en ） ◎ Sizing as if empty

  %~box の［ `width$p, `height$p ］の`使用~値$は、 次を除いて， %~box に対し通常の~layoutを遂行したかのように決定する ⇒ %~box は内容が無いものとして扱う — ［ `before$pe ／ `after$pe ／ `marker$pe ］などの疑似要素によるものも含め。 ◎ The used width and height of the containment box are determined as if performing a normal layout of the box, except that it is treated as having no content—not even through pseudo elements such as ::before, ::after, or ::marker.

  %要素 が`置換d要素$である場合、［ その［ `生来な横幅$／`生来な縦幅$ ］は 0 に，その`生来な縦横比$は無いものとして ］扱うモノトスル。 ◎ Replaced elements must be treated as having a natural width and height of 0 and no natural aspect ratio.

  注記： `~size封込め$が抑止するのは，［ `生来な縦横比$, `選好d縦横比$ ］のうち前者に限られるので、 `aspect-ratio$p の様な後者に直に影響する~propは，尊守される。 ◎ Note: Size containment only suppresses the natural aspect ratio, so properties like aspect-ratio which affect that preferred aspect ratio directly are honored.

  %~box の~propは、 すべて，~layoutを通常に遂行するときと同じく織り込まれる。 他の仕様は、 特有な免除を為してもヨイ。 ◎ All CSS properties of the size containment box are taken into account as they would be when performing layout normally. Other specifications may make specific exemptions.

  注記： %要素 の`~sizing~prop$が`内在的~size$を指定しているときでも、 これにより， %要素 の~sizeが 0 になるとは限らない — %要素 自身に設定された~propは、 織り込まれ続け， %~box を大きくさせ得る。 ◎ Note: Even when the element’s sizing properties specify an intrinsic size, this does not necessarily make the element zero-sized: properties set on the element itself continue to be taken into account, which can cause it to be larger.

  `~size後に~lay-outする@ （ `laying out in-place^en ） ◎ Laying out in-place

  %~box の内容（疑似要素も含む）を， 今や~sizeが固定的な %~box に通常に~lay-outするモノトスル。 ◎ The containment box's content (including any pseudo-elements) must then be laid out into the now fixed-size containment box normally.

  注記： `~size封込め$は、 基底線~整列を抑止しない。 それ用には、 `~layout封込め$を見よ。 ◎ Note: Size containment does not suppress baseline alignment. See layout containment for that.

• %~box は`単体的$になる（`アリな分断点$を見よ）。 ◎ Size containment boxes are monolithic (See CSS Fragmentation 3 § 4.1 Possible Break Points).

img {
  width: 100px;
  aspect-ratio: 1/1;
  contain: size;
}

<img src="https://www.example.com/300x100.jpg">

しかしながら，要素に対する`~size封込め$の効果は、 次のいずれかに該当する場合には無い： ◎ However, giving an element size containment has no effect if any of the following are true:

• 要素は`首要~box$を生成しない （要素の `display$p 値が［ `contents^v ／ `none^v ］の事例など） ◎ if the element does not generate a principal box (as is the case with display: contents or display: none)
• 要素の`内縁~表示~型$は `table$v ◎ if its inner display type is table
• 要素の`首要~box$は次のいずれかである ⇒＃ `内部~table~box$／ `内部~ruby~box$／ `不可分$でない`行内~level$の~box ◎ if its principal box is an internal table box ◎ if its principal box is an internal ruby box or a non-atomic inline-level box

注記： 内部~table~boxが除外されるのは、 ~table~layout~algoが，［ ~boxが自身の~flow内にある内容より小さくなること ］を許容しないからである。 ~table~cellを内容が空であるかのように~sizeしてから，~sizeを変更することなく~cellの内側に内容を~lay-outすることは、 実質的に定義されない演算である。 ~cellの［ `width$p ／ `height$p ］~propを手動で `0^v に設定しても，その内容より小さくできない。 ~table~caption（これは、内部~table要素ではない）には、 この懸念は適用されない — それには、 内容とまったく独立に~sizeを固定できる能力がある。 ◎ Note: Internal table boxes, which do not include table captions, are excluded, because the table layout algorithm does not allow boxes to become smaller than their inflow content. Sizing a table cell as if it was empty and then laying out its content inside without changing the size is effectively an undefined operation. Manually setting the width or height properties to 0 cannot make it smaller than its content. This concern does not apply to table captions, which are perfectly capable of having a fixed size that is independent of their content.

3.2. 行内-~size封込め

要素に対する `行内-~size封込め@ （ `inline-size containment^en ）を与えることは、 要素の`首要~box$の`行内-軸$の~sizingに`~size封込め$を適用する。 このことは、［ `首要~box$の`行内-軸$`内在的~size$は，要素の内容は無かったかのように決定される ］ことを意味する。 しかしながら、 内容は，当の~boxの`塊-軸$における`内在的~size$には通例通り影響iし続ける — 当の~boxを`塊-軸$において`断片化-$することは、 通常に許容される。 ◎ Giving an element inline-size containment applies size containment to the inline-axis sizing of its principal box. This means the inline-axis intrinsic sizes of the principal box are determined as if the element had no content. However, content continues to impact the box’s block-axis intrinsic sizes as usual, and the box is allowed to fragment normally in the block axis.

要素の行内~sizeと塊~sizeの関係性は、 一般に，予測-不能であり単調ではない — 行内~sizeが変化するに伴い、 塊~sizeを任意に上下へズラす能力がある。 無限な循環は、［ ~layoutが，それまでの（問題になり得ることが既知な）状態へは復帰しない ］ことを — 拘束の素朴な分析が，そのようなものを許容することになる場合でも — 確保することにより防止される。 言い換えれば、 ~layoutは，常に “~~前進する” 。 現在の~CSS~layout仕様は，そのような規則を組入れるものと予見されているが、 そうでない場合，誤りが正されるよう`~CSS~WGへ伝えられたし＠https://github.com/w3c/csswg-drafts/issues$。 ◎ In general, the relationship between an element’s inline size and it’s block size is unpredictable and non-monotonic, with the block size capable of shifting up and down arbitrarily as the inline size is changed. Infinite cycles are prevented by ensuring that layout does not revert to a previous (known-problematic) state, even if a naive analysis of the constraints would allow for such; in other words, layout always “moves forward”. We believe that current CSS layout specifications incorporate such rules, but to the extent that they don’t, please inform the CSSWG so that these errors can be corrected.

<section style="width: 200px; border: solid; display: flow-root;">
  <!-- 
可用な空間に影響iする浮動された要素たち
◎
floated elements that impact the available space
 -->
  <div style="float: left; width: 50px; height: 80px; background: blue;"></div>
  <div style="float: right; width: 50px; height: 80px; background: blue;"></div>
  <div style="float: left; width: 160px; height: 80px; background: navy;"></div>

  <!-- 
文脈を決定している親~layout
◎
parent layout, determining context
 -->
  <article style="border: solid orangered; display: flow-root; min-width: min-content">
    <div style="background: orange; aspect-ratio: 1/1;">
      Article
    </div>
  </article>
</section>

要素が ~OR↓ を満たす場合、 要素に`行内-~size封込め$を与えても，効果は無い： ◎ Giving an element inline-size containment has no effect if any of the following are true:

• 要素は`首要~box$を生成しない （要素の `display$p が［ `contents^v ／ `none^v ］をとる事例など） ◎ if the element does not generate a principal box (as is the case with display: contents or display: none)
• 要素の`内縁~表示~型$は `table$v ◎ if its inner display type is table
• 要素の`首要~box$は、 次に挙げるいずれかである ⇒＃ `内部~table~box$／ `内部~ruby~box$／ `不可分$でない`行内~level$の~box ◎ if its principal box is an internal table box ◎ if its principal box is an internal ruby box or a non-atomic inline-level box

3.3. ~layout封込め

要素に対する `~layout封込め@ （ `layout containment^en ）は、 要素の`首要~box$ %~box を `~layout封込め~box@ にする — それには、 次に挙げる効果がある： ◎ Giving an element layout containment makes its principal box a layout containment box and has the following effects:

• %~box は、 `独立な整形~文脈を確立する$。 ◎ The layout containment box establishes an independent formatting context.

• 所与の`断片化~文脈$ %文脈 において、 %~box が次の条件を満たす最初のものであるならば ⇒ ［ `~layout封込め~box$である ］~AND［ %~box とその子孫が成す集合は、 次を満たす ］ ⇒ ［ %文脈 内のある`断片化~容器$ %A を含む ］~AND［ %文脈 内で %A の次にある`断片化~容器$は含まない ］ ◎ If at least one fragmentation container of a fragmentation context has layout containment, or if at least one fragmentation container of a fragmentation context is a descendant of layout containment box and at least one subsequent fragmentation container of the same fragmentation context is not a descendant of that same element with layout containment, then the first layout containment box which is either a fragmentation container itself or is an ancestor of a fragmentation container＼

  …ならば、 %~box は， %A に後続するすべての`断片化~容器$への`断片~化~flow$を “捕える” モノトスル ⇒ すなわち，`断片化$は、 `~layout封込め$境界を過ぎて継続しないモノトスル ⇒ すなわち，最初の`~layout封込め$境界の中の最後の`断片化~容器$【すなわち %A 】は、 %文脈 内の最後の`断片化~容器$であったかのように扱うモノトスル。 ◎ must “trap” the remainder of the fragmented flow: fragmentation must not continue past the layout containment boundary, and the last fragmentation container within the first layout containment boundary is treated as if it is the last fragmentation container in its fragmentation context.

  `断片化~文脈$において，［ 後続な`断片化~容器$たちは、 `断片~化~flow$内に更なる内容が まだあるときに限り生成される ］場合【すなわち，内容の分量に応じて自動的に生成される場合】、 それらは生成されない。 にも関わらず，それらが存在することになる場合【？】、 それらは %文脈 の一部を成し続けるが、 `断片~化~flow$からは，いかなる内容も受取らない。 ◎ If subsequent fragmentation containers in the fragmentation context are only generated when more content remains in the fragmented flow, then they are not generated. If they would exist regardless, they remain part of the fragmentation context, but do not receive any content from the fragmented flow.

  注記： これを書いている時点では、 この点により影響される安定的な仕様は無い。 懸念される仕様は、［ 一部の（すべてではない）断片化~文脈を成す 一部の断片化~容器が，~layoutを封込めるもの（または ~layoutを封込める要素の子孫）になること ］を可能化するものに限られる。 `CSS-PAGE-3$r ／ `CSS-MULTICOL-1$r は、 これに該当しない。 それでも、 この要件は含まれる。 いくつかの仕組みは，この可能性を考慮したことがあり（例： `CSS-REGIONS-1$r, `nth-fragment()$pe, 複-柱~layoutを成す個々の柱~用に~~提案された選択子, 等々）、 `~layout封込め$が提供しようと意図する保証は，そのような仕組みがこの規則を守らない場合には実現されないので。 `CSS-REGIONS-1^r に，`~layout封込め$が`領域$にどう影響するかの詳細がある。 ◎ Note: At the time of writing, no stable specification is affected by this point. Only specifications that would enable some (but not all) fragmentation containers of a fragmentation context to be layout-contained (or descendants of a layout contained element) are concerned. This is not the case of [CSS-PAGE-3] nor of [CSS-MULTICOL-1]. This requirement is nonetheless included because several mechanisms that would make this a possibility have been considered (e.g.: [CSS-REGIONS-1], ::nth-fragment(), a hypothetical selector for individual columns of a multicol…), and the guarantees that layout containment is intended to offer would not be realized if such mechanisms did not abide by this rule. [CSS-REGIONS-1] has details over how layout containment affects regions.

  <article>Lorem ipsum…</article>
  <div id=a></div>
  <aside>
    <div id=b></div>
    <div id=c></div>
  </aside>
  <aside>
    <div id=d></div>
    <div id=e></div>
  </aside>
  <div id=f></div>
  

  article {flow-into: foo;}
  #a, #b, #c, #d, #e, #f {flow-from: foo;}
  aside {contain: layout}
  

  この `CSS-REGIONS-1$r 例では、 `article^e の内容は `#a^css から `#b^css へ, `#b^css から `#c^css へ~flowし得る。 しかしながら， `#c^css は［ 最初の`~layout封込め~box$ ］内の最後の断片~容器なので、 残りの内容~すべてを捕える — ［ `#d^css ／ `#e^css ／ `#f^css ］の中へは何も~flowされない。 ◎ In this [CSS-REGIONS-1] example, content can flow from #a to #b, from #b to #c. However as #c is the last fragment container in the first layout containment box it traps all the remaining content, and nothing gets flowed into #d, #e, or #f.

• %~box の `overflow$p ~propの算出d値が［ `visible$v, `clip$v, またはこれらの組合n ］である場合、 どの~overflowも`~ink~overflow$として扱うモノトスル。 ◎ If the computed value of the overflow property is either visible or clip or a combination thereof, any overflow must be treated as ink overflow.
• %~box は、［ `絶対~位置決め包含塊$, `固定d位置決め包含塊$ ］を確立する。 ◎ The layout containment box establishes an absolute positioning containing block and a fixed positioning containing block.
• %~box は、 `積層~文脈$を作成する。 ◎ The layout containment box creates a stacking context.

• `強制d分断$は、 %~box の中でも許容されるが，［ `~box間の分断＠~CSSBREAK#break-between$により，親へ伝播する ］ことはない。 ◎ Forced breaks are allowed within layout containment boxes but do not propagate to the parent as otherwise described in CSS Fragmentation 3 § 3.1 Breaks Between Boxes: the break-before and break-after properties.

  注記： これは、 これまで存在しなかった［ `強制d分断$が ~boxとその容器の合間に生じ得る可能性 ］を導入する（`アリな分断点$を見よ）。 ◎ Note: This introduces the previously non-existent possibility that forced breaks may occur between a box and its container (See CSS Fragmentation 3 § 4.1 Possible Break Points).

• `vertical-align$p ~prop, および 他の~propのうち［ その効果は、 %~box の基底線の位置を，子孫~以外の何かに関係させる必要があるもの ］の目的においては、 %~box は基底線を持たないものと扱われる。 ◎ For the purpose of the vertical-align property, or any other property whose effects need to relate the position of the layout containment box's baseline to something other than its descendants, the containment box is treated as having no baseline.

しかしながら，要素に対する`~layout封込め$の効果は、 次のいずれかに該当する場合には無い： ◎ However, giving an element layout containment has no effect if any of the following are true:

• 要素は`首要~box$を生成しない （要素の `display$p 値が［ `contents^v ／ `none^v ］の事例など） ◎ if the element does not generate a principal box (as is the case with display: contents or display: none)
• 要素の`首要~box$は次のいずれかである ⇒＃ `table-cell$v 以外の`内部~table~box$／ `内部~ruby~box$／ `不可分$でない`行内~level$の~box ◎ if its principal box is an internal table box other than table-cell ◎ if its principal box is an internal ruby box or a non-atomic inline-level box

3.4. ~style封込め

要素に対する `~style封込め@ （ `style containment^en ）には、 次に挙げる効果がある： ◎ Giving an element style containment has the following effects:

• ［ `counter-increment$p, `counter-set$p ］は、 要素の【要素を根とする】`下位treeに視野を絞る$こと, および 新たな~counterを作成する【`~counterを~instance化する$】ことが要求される ◎ The counter-increment and counter-set properties must be scoped to the element’s sub-tree and create a new counter.

• `content$p ~prop用の値［ `open-quote^v ／ `close-quote^v ／ `no-open-quote^v ／ `no-close-quote^v ］による効果は、 要素の`下位treeに視野を絞る$ことが要求される ◎ The effects of the content property’s open-quote, close-quote, no-open-quote and no-close-quote must be scoped to the element’s sub-tree.

  注記： これは、 下位tree内での引用符の入子深さは変更しない — したがって引用符は、 その文脈が通常に含意する値から開始される — が、 これらの値による［ 下位treeの内側にある引用符の入子深さに対する変更 ］は［ 下位treeの外側にある引用符の入子深さ ］には影響しないことを含意する。 ◎ Note: This implies that the depth of quote nesting in the subtree is unchanged and starts at the value that its context normally implies, but that changes to the depth of quote nesting by these values inside the subtree do not affect the depth of quote nesting outside the subtree.

• しかしながら，次が満たされる場合には、 要素に`~style封込め$を与えても効果は無い ⇒ 当の要素は`首要~box$を生成しない （ `display$p が［ `contents^v ／ `none^v ］にされたときのように）。 ◎ However, giving an element style containment has no effect if any of the following are true: • if the element does not generate a principal box (as is the case with display: contents or display: none)

注記： `CSS-REGIONS-1$r にも，`~style封込め$が`領域$にどう影響するかについての規範的な要件がある。 ◎ Note: [CSS-REGIONS-1] has normative requirements on how style containment affects regions.

`視野~付き~prop@ （ `scoped property^en ）の視野（効果が及ぶ~~範囲）は、 特定0の［ %要素, または %要素 の下位tree ］に絞られるようになる： ◎ A scoped property has its effects scoped to a particular element or subtree.

• `要素に視野を絞る@ 場合、 その効果を評価する目的においては， %要素 が文書の根であったかのように動作するモノトスル。 すなわち、 %要素 の外側における~propの利用が， %要素 の内側（ %要素 上も含む）における~propの利用に効果を及ぼしたり、 その逆であってはナラナイ。 ◎ If scoped to an element, it must act as if the scoping element was the root of the document for the purpose of evaluating the property’s effects: any uses of the property outside the scoping element must have no effect on the uses of the property on or in the scoping element, and vice versa.

  注記： “要素に視野を絞る” は、 現在は利用されていないが，将来の仕様による拡張~用に定義されている ◎ Note: “Scoping to an element” is currently unused. It is defined as an extension point for future specifications to use.

• `下位treeに視野を絞る@ 場合、［ %要素 自身も，文書を成す残りと同様に下位treeの “外側にある” とされ、 ~propによる %要素 に対する効果は影響されない ］ことを除いて，`要素に視野を絞る$ときと同じになる。 （したがって、 視野~付き~propによる［ 下位treeの内側にある要素 ］に対する効果を考慮するときには、 %要素 は文書の根であったかのように扱われる。） ◎ If scoped to a sub-tree, it’s the same, except the scoping element itself is counted as "outside" the tree, like the rest of the document, and the effects of the property on that element are unaffected by scoping. When considering the effects of the scoped property on elements inside the subtree, the element at the base of the subtree is treated as if it was the root of the document.

<div>
  <div style="contain: style;">
    <div></div>
    <div></div>
  </div>
  <div>
    <div></div>
    <div></div>
  </div>
</div>

body {
  counter-reset: foo;
}
div {
  counter-increment: foo;

  /* 
入子ngを適正に観測し易くするための
◎
and to help observe nesting properly
 */
  margin: .2em;
  padding: .2em;
  background: #0001;
}
div::before {
  content: counters(foo, ".");
}

3.5. 塗り封込め

要素に対する `塗り封込め@ （ `paint containment^en ）は、 要素の`首要~box$ %~box を `塗り封込め~box@ （ `paint containment box^en ）にする — それには、 次に挙げる効果がある： ◎ Giving an element paint containment makes its principal box a paint containment box and has the following effects:

• 要素の内容は、 `~ink~overflow$や`~scroll可能な~overflow$も含め， %~box の`~overflow切取n辺$で切取られるモノトスル — `隅における切取り$も織り込んだ上で。 これには、 切取られた内容への~accessや それが在ることを指示する仕組みの作成【~scroll~boxなど】は含まれないことに加え、［ `overflow$p ／ `resize$p ／ `text-overflow$p ］などの他の~propによる，その種の仕組みの作成を妨げるものでもない。 ◎ The contents of the element including any ink or scrollable overflow must be clipped to the overflow clip edge of the paint containment box, taking [[css-backgrounds-3#corner clipping|corner clipping]] into account. This does not include the creation of any mechanism to access or indicate the presence of the clipped content; nor does it inhibit the creation of any such mechanism through other properties, such as overflow, resize, or text-overflow.

  注記： この切取り図形は、 `overflow-clip-margin$p を尊重する — すなわち、 `塗り封込め$を伴う要素であっても， その通常の限界域から少し~overflowすることを許容する。 ◎ Note: This clipping shape respects overflow-clip-margin, allowing an element with paint containment to still slightly overflow its normal bounds.

  注記： この段落にて述べた挙動は、 `overflow-x$p, `overflow-y$p 両~propとも，使用~値の時点で `visible^v から `clip^v へ変更する一方で，他の値は変更しないままにすることに等価になる。 ◎ Note: The behavior is described in this paragraph is equivalent to changing overflow-x: visible into overflow-x: clip and overflow-y: visible into overflow-y: clip at used value time, while leaving other values of overflow-x and overflow-y unchanged.

• %~box は、［ `絶対~位置決め包含塊$, `固定d位置決め包含塊$ ］を確立する。 ◎ The paint containment box establishes an absolute positioning containing block and a fixed positioning containing block.
• %~box は、 `積層~文脈$を作成する。 ◎ The paint containment box creates a stacking context.
• %~box は、 `独立な整形~文脈を確立する$。 ◎ The paint containment box establishes an independent formatting context.

しかしながら，要素に対する`塗り封込め$の効果は、 次のいずれかに該当する場合には無い： ◎ However, giving an element paint containment has no effect if any of the following are true:

• 要素は`首要~box$を生成しない （要素の `display$p 値が［ `contents^v ／ `none^v ］の事例など） ◎ if the element does not generate a principal box (as is the case with display: contents or display: none)
• 要素の`首要~box$は次のいずれかである ⇒＃ `table-cell$v 以外の`内部~table~box$である／ `内部~ruby~box$／ `不可分$でない`行内~level$の~box ◎ if its principal box is an internal table box other than table-cell ◎ if its principal box is an internal ruby box or a non-atomic inline-level box

4.1. `content-visibility^p の~animate法と補間-法

`content-visibility$p ~propの`~animation型$は、 一般には`離散的$になる。 しかしながら， `visibility$p の補間 （ `WEB-ANIMATIONS-1$r § `visibility^p の~animation を見よ） と類似に、 値 `hidden$vC と他の `content-visibility^p 用の値の補間においては，［ 0 ~LT %p ~LT 1 ］を満たす %p 値は `hidden$vC でない方の値に対応付けられる。 ◎ In general, the content-visibility property’s animation type is discrete. However, similar to interpolation of visibility (see Web Animations § Animation of visibility), during interpolation between hidden and any other content-visibility value, p values between 0 and 1 map to the non-hidden value.

4.2. `content-visibility:hidden$p の利用-法

`content-visibility:hidden$p は、 要素に対し~~強力な制約を~~課すので，用心深く利用するベキである。 それはまた、 いくつかの有用な局面を可能化して，既存の技法を改善することが多い — それらのうち少数をここに要旨する： ◎ content-visibility: hidden lays powerful restrictions onto an element, and so should be used with caution. It also enables some very useful scenarios, often improving on existing techniques, a few of which are outlined here.

• ~pageは、 描画されてない要素や~textに対し何かを測定する必要がある場合、 `position$p の様な何かを利用して，測定-対象を~screen外に位置してから， `getBoundingClientRect()$m の様な~APIを~callすることが共通的に行われる。 ◎ If a page needs to take some measurements of elements or text which aren’t themselves going to be rendered, commonly this is done by positioning the stuff-to-be-measured off-screen, using something like position: absolute; left: -100000px;, then calling an API like getBoundingClientRect().

  あいにく、 ~pageが この内容を決して表示しないと意図していようが、 ~UAは — 念のため、 それが~screen上に示されている何かに影響する事例に備えて — 内容~用に全部的な［ ~style付け／~layout／描画 ］を行う必要がある。 作者はまた、 更なる作業を伴わない限り，内容が~screen上に`決して~~現れない^emことは保証できない — （上述の様に） `left$p を大きく負な値にしても，内容によっては十分でないかもしれない。 ◎ Unfortunately, even though the page never intends to display this content, the user agent will still have to do full styling, layout, and rendering for the content, just in case it affects what’s shown on screen. The author also can’t, without further work, guarantee that the content won’t accidentally show up on-screen; even a very negative left value (like above) might not be enough, depending on the content.

  これらの問題は、 内容を `content-visibility:hidden$p にした容器~内に包装すれば，すべて解消する。 ［ 当の容器, その`飛ばされた内容$ ］は、 分量がいくらあろうと — 当の容器の［ ~border, 背景, 等々 ］は除いて — ~screenには決して描画されないことが保証される。 内容は`飛ばされ$るので、 ~UAは，それらを［ ~style／~lay-out ］するのも避けれる — ~scriptが最終的にそうするよう依頼して，絶対的に必要yあるまでは。 ◎ Wrapping this content in a content-visibility: hidden container solves all of these problems. If the wrapper has no border, background, etc, then it and its skipped contents are guaranteed to never render anything to the screen, no matter how big they get. Because the contents are skipped, the user agent can also avoid styling or laying them out until absolutely necessary, when script finally asks for it.

• “単-~page~app” は、何個かの — いっときに，どれか 1 つだけ表示されるような — 独立な［ ~paneまたは “~view” ］からなることが多い。 ◎ A "single-page app" often consists of several independent panes or "views", of which only one is displayed at a time.

  作者は，作動中でない~view用には［ ~style付け／~layout／描画 ］等々の~costを~~支払いたくない場合、 文書からまるごと除去するか，最小で済ますなら `display:none$p を適用できる。 あいにく，これは、 当の~viewが表示される必要が`生じたとき^emには，すべての［ ~style付け／~layout／描画, 等々 ］の作業を一括して行う必要があることを意味する — その結果、 ~viewが実際に~~現れるまでの遅延が目立つまでになりかねない。 ◎ If the author wants to avoid paying styling/layout/rendering/etc cost for the inactive views, they can remove them from the document entirely, or at minimum apply display:none to them. Unfortunately, this means that when the view does need to be displayed, all of the styling/layout/rendering/etc work needs to be done all at once, potentially causing a noticeable delay before the view actually shows up.

  別法として、 単に，~viewを~screen外に位置する~optionもある。 これは，利用する時点で即時に準備済みになることを意味するが、 ~~恒常的に［ ~style付け／~layout／描画 ］の~costを被る — とりわけ、 作動中でない~viewがいくつもあるときには，有意になるかもしれない。 また、 作動中でない~viewであっても，~accessibility~toolからは見えるかもしれず、 ~screen~readerや~find-in-page, 等々の利用者を惑わすかもしれない。 ◎ Alternately, the view can just be positioned off-screen. This means it’ll be immediately ready when it’s time to be used, but it incurs the cost of styling/layout/rendering all the time, which might be significant, especially if there are a number of inactive views. The inactive views also might still show up to accessibility tooling, confusing users of screen-readers, people using Ctrl-F to find-in-page, etc.

  `content-visibility:hidden$p は、 これらの~optionどちらも改善する。 内容は`飛ばされ$るので、 ~UAは，それらが作動中でないときは時間を費やさずに済む。 それらは、［ ~screen~reader, ~find-in-page, その他の~tool ］からも可視にならない。 当の~viewが以前に表示されていたなら、 ~UAは，そのときの［ ~style付け／~layout ］作業をアリなら保全する`ベキ^emなので、 ごく速く描画し直せるであろう。 ◎ content-visibility: hidden improves on both of these options. Because the contents are skipped, the user agent isn’t spending time on them when they’re not active. They’re also not visible to screen readers, find-in-page, and other tools. And because user agents should preserve previous styling/layout work if possible, if the view was displayed before, re-rendering it might be very fast.

• 作者が［ 要素を “不可視” にしつつ，~layout目的に限り~page内に~~現れる ］よう求める場合、 `visibility:hidden$p にする方法もある。 しかしながら，そのような要素の子孫に `visibility:visible^p が設定されれば、 その子孫は~~現れるようになり，常に［ 直感的／期待される ］とは限らない。 ◎ If an author wants to make an element "invisible", but still show up in the page for layout purposes, one option is visibility: hidden. However, descendants of a visibility: hidden element can set visibility: visible and start showing up again, which isn’t always intuitive or expected.

  `content-visibility:hidden$p は，これと よく似た目的を遂行するが、 子孫からは~~上書きできず，先祖が それをオフにするまで “隠され続ける” 点で異なる。 ◎ content-visibility: hidden performs a very similar purpose, but descendants can’t turn it "off" and start displaying; they stay "hidden" until the ancestor turns it off.

  `content-visibility:hidden$p は，容器に多種の`封込め$【！values】も適用するので、 `visibility:hidden$p ほどには常に利用-可能ではないが、 その制約が受容-可能であるなら，要素の内容を隠す仕方として より依拠-可能かつ一貫したものになり得る。 ◎ Because content-visibility: hidden also applies many containment values to the container, it’s not always quite as usable as visibility: hidden would be, but when its restrictions are acceptable, it can be a more reliable, more consistent way to hide an element’s contents.

4.3. `content-visibility:auto$p の利用-法

`content-visibility:auto$p は、 `hidden$vC より複階的な値であり， `display:none$p に類似しない — それは、 要素の内容を，`利用者に関連する$かどうかに順応して［ そうなったなら表示する／ そうならなくなったなら隠す ］。 加えて，~UAは要素の`飛ばされた内容$を隠さないので、 他の~tool — ~screen~reader, ~find-in-page, その他 — は，依然として内容とヤリトリできる。 ◎ content-visibility: auto is a more complex value than hidden; rather than being similar to display: none, it adaptively hides/displays an element’s contents as they become relevant to the user. It also doesn’t hide its skipped contents from the user agent, so screen readers, find-in-page, and other tools can still interact with it.

それは、 `封込め$への`昇格^emと捉えるのが最も良い： 作者は、［ ~screen外になることが多いが，ときには表示される多量な内容（長い~scroll可能な~listなど） ］があって，その内容に~~強力な`封込め$を~~課しても差し支えない場合、［ `content-visibility:auto$p を利用して，各種`封込め$を一括して適用する ］ことを考慮するベキである。 これはまた、［ 文書~内に多量な内容があり、 どのみち，そのほとんどは見えなくなる ］ことの方が重要なので［ 内容に対する作業を飛ばすことは、 受容-可能であること ］を~UAに強く~hintする （飛ばすことは、 場合によっては，それが~screen上に来たときの遅延-を減らすことにもなる）。 ◎ It is best to think of it as an upgrade to containment: if an author has a large amount of content to display that will often be off-screen (such as a long scrollable list), and that content is okay with heavy containment, they should consider using content-visibility: auto to apply all of the containments at once. This also strongly hints to the user agent that it’s acceptable to skip work on the contents (possibly causing a small delay when they do come on-screen) because it’s more important to have a large amount of content in the document and most of it won’t be seen anyway.

注記： したがって `content-visibility:auto$p は、 少なくとも多くの事例で，複雑な “仮想~list” の技法に`代えて^em利用できる。 ◎ Note: content-visibility: auto can thus be used instead of complicated "virtual list" techniques, at least in many cases.

`content-visibility:auto$p は、［ 要素の内容に`利用者に関連する$ものは無いときに限り，`内容を飛ばす$ ］ようにするので，適度な木目細かさで利用するのが最善である。 ◎ Because content-visibility: auto only causes the element to skip its contents when none of it is relevant to the user, it’s best to use at a reasonably fine granularity.

`content-visibility:auto$p は，当の要素の`内容を飛ばす$ときに`~size封込め$を課すので、 要素の~sizeが自身の内容に依存して決定される場合， ~pageの~layoutは（または，少なくとも要素の~scrollbar位置は）［ 要素が~screen外へ出て内容を`飛ばし$始める伴い， 要素~周りで “急にぶれる” ］こともある。 ◎ Because content-visibility: auto imposes size containment when the element skips its contents, if the element depends on its contents to determine its size the layout of the page (or at least, the scrollbar position) can "jump around" as elements go off-screen and start skipping.

4.4. `content-visibility:auto^p における状態~変化の検出-法： `contentvisibilityautostatechange^et ~event

`contentvisibilityautostatechange@et ~eventは、 `content-visibility:auto$p を伴う要素が — その描画~状態が変化して — `利用者に関連する$ように［ なった／ならなくなった ］とき， 当の要素に向けて発火される。 ◎ The contentvisibilityautostatechange event is fired on an element with content-visibility: auto style when the rendering state changes and the element either becomes or stops being relevant to the user.

この~eventは、 状態~変化が生じた時点で~taskを~postする【`~taskを~queueする$？】ことにより配送される。 ◎ This event is dispatched by posting a task at the time when the state change occurs.

[`Exposed$=Window]
interface `ContentVisibilityAutoStateChangeEvent@I : `Event$I {
  `constructor＠dom-contentvisibilityautostatechangeevent-contentvisibilityautostatechangeevent@(`DOMString$ %type, optional `ContentVisibilityAutoStateChangeEventInit$I %eventInitDict = {});
  readonly attribute `boolean$ `skipped$m;
};
dictionary `ContentVisibilityAutoStateChangeEventInit@I : `EventInit$I {
  `boolean$ `skipped＠#dom-contentvisibilityautostatechangeeventinit-skipped@m = false;
};

`ContentVisibilityAutoStateChangeEvent$I の `skipped@m 属性は、 ~targetの状態が［ `内容を飛ばす$ように変化した場合は ~T ／ ~ELSE_ ~F ］に設定される。 ◎ Description of ContentVisibilityAutoStateChangeEvent attributes: ◎ skipped, of type boolean, readonly • Set to true if target changed state to skip its contents, and false otherwise. ◎ Description of ContentVisibilityAutoStateChangeEventInit members: ◎ skipped, of type boolean, defaulting to false • See the description of the skipped attribute.

`content-visibility:auto$p を伴う要素の`内容$（子孫）は、 `内容を飛ばす$ものであっても，意味論的に関連し続けることに注意。 このことは、 この通達を［ `飛ばされ$た`内容$を成す~DOMの更新を不定期に飛ばす ］ために利用することは，不適切であることを意味する。 代わりに、 更新の優先度は下げるが，`内容$は［ 意味論的に関連し続け，適度に最新である ］ことを確保するために利用するべきである。 このことは、 特に，支援技術~用に重要になる — それは、 先祖が`内容を飛ばす$よう設定されたときでも，この内容を消費するので。 ◎ Note that elements in content-visibility: auto subtrees remain semantically relevant even for elements that skip its contents. This means that it is inappropriate to use this signal to indefinitely skip DOM updates in the subtree that is skipped. Instead, it should be used to deprioritize updates, but ensure that the content remains semantically relevant and reasonably up-to-date. This is particularly important for assistive technologies which consume this content even when the ancestor is set to skip its contents.

4.5. 制約と明確化

1. `IntersectionObserver$I （交差~観測器）の視点からは、 要素の`飛ばされた内容$は，要素の`交差~根$に交差することは決してない。 このことは、 根と~target要素どちらも`飛ばされた内容$~内にある場合でも成り立つ。 ◎ From the perspective of an IntersectionObserver, the skipped contents of an element are never intersecting the intersection root. This is true even if both the root and the target elements are in the skipped contents.
2. `ResizeObserver$I （~resize観測器）の視点からは、 要素の`飛ばされた内容$の~sizeは決して変化しない。 要素が後で飛ばされなくなった場合、 ~resize観測nは、［ 新たな~sizeが，最後に利用された~sizeから相違する ］ならば送達され，~resize観測器へ通知することになる。 ◎ From the perspective of a ResizeObserver, the skipped contents of an element never change their size. If these elements become non-skipped later, the resize observation will be delivered if the new size differs from the last size used to notify the resize observer.

3. 要素の内容が`飛ばされ$るか否かが変化するのは、 それによる効果を描画する~frameにおいて `requestAnimationFrame()$m ~callbackを走らせた後に起こる。 特定的には、 そのような変化が効果を発揮するのは， `HTML^r の`描画を更新する手続き$の中の “各~animation~frame~callbackを走らす” 段と “交差~観測nを更新する” 段の合間【！between steps 13 and 14】になる。 ◎ If an element starts or stops skipping its contents, this change happens after the requestAnimationFrame callbacks of the frame that renders the effects of the change have run. Specifically, such changes will take effect between steps 13 and 14 of update the rendering step of the Processing Model (between “run the animation frame callbacks” and “run the update intersection observations steps”).

   注記： 要素と表示域との交差域は， `IntersectionObserver$I が内部的に決定するが、 その観測n結果は，`描画を更新する手続き$の中の交差~観測nを更新する【！step 14】段が配送する【ための~taskを~queueする】ので、 内容が`飛ばされ$るか否か（したがって塗られるか否か）が変化しても， 次回の~frame処理までは利用者には可視にならない。 この理由から、 封込め調整も含め， `飛ばされ$るか否かを更新するのも， 次回の~frameへ先送りされる。 このことは、 ~scriptから — 例えば、 これらの 2 つの~event（交差域の内部的な観測n, `飛ばされ$るか否かの更新）の合間に， 要素の封込め値に — ~accessしても，［ 現在の塗られた状態と整合な値が検索取得され，~layoutは強制されない ］ことを確保する。 ◎ Determining the viewport intersection of the element can be done with an internal version of an IntersectionObserver. However, since the observations from this are dispatched at step 14 of update the rendering, any changes to the skipped (and thus painted) state will not be visible to the user until the next frame’s processing. For this reason, updating the skipped state, including containment adjustments, is deferred to that frame as well. This ensures that script accessing, for example, the containment value of the element between these two events (internal intersection observation and skipped state update) will retrieve values consistent with current painted state and not cause any forced layouts.

4. 各~要素のうち ~AND↓ を満たすものに対しては…

   • `表示域への近接度$ ~EQ `未決定$i
   • `接続されて$いる 【この条件は、この訳による補完】
   • `content-visibility:auto$p を伴う

   …に対しては、 次回の`描画を更新する手続き$において， `表示域への近接度を決定する$モノトスル。 この決定による効果は、 この`描画を更新する手続き$の結果を成す視覚的な更新に反映するモノトスル。 具象的な~algoの記述は、 `~event~loop処理n~model＠~WAPI#_content-visibility-auto$を見よ。

   ◎ Elements with content-visibility: auto that have not determined proximity to the viewport must determine their proximity to the viewport in the next update the rendering cycle. The effect of this determination must be reflected in the visual update which results from this update the rendering cycle. See the event loop process model for the concrete algorithm description.

   注記： 要素が最初に `content-visibility:auto$p になったとき、 要素は，~screen上に位置しているとは限らない。 この状態【すなわち，可視性】の決定 — したがって，この要素は`内容を飛ばす$かどうかの決定 — は、 同じ~frame内に起こるモノトスル。 さもなければ，可視性の検査と`飛ばされ$るか否かの更新は次回の~frameに先送りされ、 その結果，要素が占める所に白紙な内容を生産する可能性があるので。 ◎ When an element first gains content-visibility: auto, it may or may not be positioned on screen. The determination of this state and thus determination of whether this element is skipped must happen in the same frame. If it does not, then there is a possibility of producing blank content in the element’s place since visibility check and skipped state update would be deferred to the next frame.

5. `scrollIntoView()$m などの~scrollする演算の目的においては、［ `content-visibility:auto$p を伴う要素のうち，`内容を飛ばす$もの ］の~sizeと所在は， `~size封込め$が依然として`作動中^emである下で決定される。 ◎ For the purposes of scrolling operations, such as scrollIntoView(), an element with content-visibility: auto that is skipping its contents has its size and location determined with size containment still active.

   注記： 要素は、 ~viewの中に~scrollされた時点で内容は`飛ばされ$なくなるので， `~size封込め$は~~課されなくなるかもしれない — その結果，要素の~sizeが変化した場合、 要素は，表示域において要請されたとおり正確に整列しなくなるかもしれない。 ◎ Note: Once it’s scrolled into view, the element will no longer skip its contents, and so might not have size containment; if this changes the element’s size, it might not align in the viewport exactly as requested.

   要素が~UA特能に可用でない場合 （例えば、 ある先祖が `content-visibility:hidden$p を伴うことに因り，要素は`飛ばされ$た場合）、 ~scrollする演算は，要素へは — 要素には，~layout~boxが無かったかったかのように — まったく~scrollしないモノトスル。 ◎ If an element is not available to user-agent features (for example, if it is skipped due to a content-visibility: hidden ancestor), then scrolling operations must not scroll to it at all, as if it did not have a layout box.

6. `content-visibility:auto$p を伴う要素のうち`内容を飛ばす$もの（または その内容）が~focusされたときは、 そのことに因り~viewの中へ~scrollされる`前^em に，`利用者に関連する$ようになる （したがって、その時点から，内容は`飛ばされ$なくなる）。 ◎ If an element with content-visibility: auto that is skipping its contents is focused (or its contents are), it becomes relevant to the user (and thus stops skipping its contents) before it is scrolled into view due to the focusing.

   注記： したがって、 要素は — 前項と違って — 表示域~内に正しく~sizeされ整列される`ことになる^em。 これは、 `focus()$m ~method手続きにおける順序と整合する。 ◎ Note: Thus, unlike the previous point, the element will be correctly sized and aligned in the viewport. This is consistent with the order of the steps for the focus() method.

7. `iframe$e 要素が［ 自身の`内容を飛ばす$か，他の要素の`飛ばされた内容$の一部を成す ］場合、 ~UAは，アリなら［ 当の `iframe^e 【が入子にしている文書】に対し， `描画を更新する手続き$を まるごと飛ばす ］ベキである。 ◎ If an iframe skips its contents or is part of an element’s skipped contents, the user agent should entirely skip the Update The Rendering step in the iframe’s event loop, if possible.

   注記： `iframe$e が`飛ばされ$るようになったときは、 少なくとも一回は その段を走らせて，塗られた出力を除去する必要がある。 ◎ Note: At the moment the iframe starts being skipped, it needs to run that step at least once to remove the painted output.

8. `飛ばされた内容$は、 `innerText$m の結果には寄与しなくなる。 ◎ Skipped contents do not contribute to the result of innerText.

9. 要素が`飛ばされ$ている間は、 要素における~CSS［ 遷移／~animation ］は更新されない： ◎ While an element is skipped, CSS transitions and animations on the element do not update:

   • ~animationを開始させる~styleが新たに適用されようが、 新たな~animationは作成されない。 ◎ New animations are not created even if newly-applied style would start one.
   • 既存の~animationの`時列線$は、 進行しない。 ◎ Existing animations do not advance in their timeline.
   • 要素~上で稼働している~animationは終止しない。 ◎ Running animations on the element do not end.

   ~scriptが，`飛ばされ$た要素の~styleを~queryした場合 （これは、 `~style変化~event$を生じさせる）、 それに対し，正しい情報を返すためには［ ~animation／遷移 ］の状態を知ることが要求される。 この場合、 当の［ ~animation／遷移 ］は，その`~style変化~event$の時点の~styleに則って標本化される： ◎ If script queries the style of a skipped element (causing a style change event) such that knowing the state of animations or transitions is required to return correct information, animation and transitions are sampled according to the styles at the time of that style change event:

   • ［ `CSS Animations 2^cite `§ ~animation~event＠~CSSANIM2#events$ ／ `CSS Transitions 2^cite `§ 遷移~event＠~TRANSITION2#transition-events$ ］は、［ ~animation／遷移 ］が更新されたとき，［ ~objとして何が作成され，~eventとして何が発火され， ~dataとして何を伴うか ］を定義する。 ◎ CSS Animations 2 § 5 Animation Events and CSS Transitions 2 § 5 Transition Events defines what objects are created and what events are fired, with what data, when an animation or transition is updated,.
   • 要素が`飛ばされ$なくなったとき，その［ ~animation／遷移 ］は、 まず標本化され，その`時列線$の進行を — その地点【飛ばされなかったとするときの地点】から，通常通り — 再開する。 ◎ When an element stops being skipped, animations and transitions are sampled and then resume advancing on their timelines as normal from that point.

   注記： これは総じて、 ~~背後に回されていた~UItabが~~前面へ引き戻されたときの［ 遷移／~animation ］の挙動に類似する。 これは、 不必要な~animation作業をアリな限り飛ばすことを — 再び関連するようになった~animationを妨害し過ぎることなく — ~UAに許容する。 ◎ Note: Overall, this is similar to the behavior of transitions/animations when a background tab is brought back to the foreground, allowing user agents to skip as much unnecessary animation work as possible without overly disrupting the animations when they become relevant again.

10. 要素の内容が`飛ばされ$ている間は、 遷移は開始しないモノトスル — `~style変化~event$が，それに算出される~styleに影響する場合でも。 ◎ While an element is skipped, it must not start any transitions, even if a style change event affects its computed styles.

    要素が`飛ばされ$なくなったときは、［ そのことと, 要素に結付けられた`~style変化~event$ ］の結果として生じる遷移は，開始しないモノトスル。 ◎ When an element stops being skipped, it must not start any transitions as a result of the style change event associated with it no longer being skipped.

    注記： これは、 要素の `display$p が `none^v から他の値に切替わったときと類似する — 当の~styleが`形上では^em， その事例で（初期~値から ~cascadeによる結果の “適正な” 値へ）変化するとしても、 開始される遷移は無い。 ◎ Note: This is similar to an element switching from display:none to a non-none value—even though the styles are technically changing in that case (from their initial values to their "proper" values from the cascade), no transitions are started.

11. 要素には［ `content-visibility:hidden$p を伴う先祖 ］が在って， 要素†は`上端~層$に配置されている場合、 要素†は， `display:none$p であったかのように~boxを生成しない。 ◎ If an element has an ancestor with content-visibility: hidden, and it is placed in the top layer, it does not generate any boxes, as if it were display: none.

    【† 原文の `it^en が要素, 先祖どちらを指すか紛らわしいが、 `課題 #6728 の記述＠~CSSissue/6728$から， 要素を指すと見受けられる。 】

    注記： `content-visibility:auto$p を伴う先祖が在るなど， 他の理由により`飛ばされ$た要素は、 依然として，~boxを通常通り生成することになり、 したがって，`飛ばされ$なくなり得る。 ◎ Note: An element skipped for other reasons, such as having a content-visibility: auto ancestor, will still generate boxes as normal, and might thus become un-skipped.

4.6. ~accessibilityに対する含意

何らかの形の “~accessibility~tree” — ~DOM~treeに似るが，~screen~readerなどの~accessibility利用事例に特化された~tree （したがって、 ~focus可能な要素など， ~accessibility~APIに関連な［ 要素の位置, 等々 ］を供するもの） — を公開する~UAは、 `content-visibility:hidden$p を伴う要素の`飛ばされた内容$を， ~accessibility~treeにおいても類似に "飛ばす" （省略する）モノトスル （ `display:none$p を伴う要素が文書のすべての~viewにおいて省略されるのと類似に）。 ◎ If a user agent exposes some form of "accessibility tree", akin to the DOM tree but specialized for accessibility use-cases such as screen-readers (thus providing the positions/etc of elements relevant to accessibility APIs, such as focusable elements), then the skipped contents of content-visibility: hidden elements must similarly be "skipped" (omitted) in the accessibility tree (similar to how display: none elements are omitted in all views of the document).

`content-visibility:auto$p を伴う要素の`飛ばされた内容$は、 利用者が［ ~screenへの視覚的な描画でなく，~accessibility~tree ］を介して~pageとヤリトリしている事実を公開しないモノトスル。 特に，~UAは、［ ~screen外にある，そのような内容 ］に対し［ ~screenへの表示~用として［ ~layout／塗ng ］作業を行う ］のを避ける場合、 類似に，［ ~accessibility~tree内への表現~用として，その作業を行う ］のも避けるモノトスル。 これがアリでない場合 （例えば、 ~UAによる~accessibility~treeにおいて~focus可能な要素を表現するためには， その正確な位置についての知識が要求されるため、 要素と周囲の内容に対し全部的な~layoutを行うことが要求される場合）、 ~UAは，`飛ばされた内容$を まるごと~accessibility~treeから`省略するモノトスル^em。 ◎ Skipped contents of content-visibility: auto elements must not expose the fact that a user is interacting with the page via the accessibility tree, rather than via rendering visually to the screen. In particular, if a user agent uses content-visibility: auto to avoid doing layout and painting work on off-screen content for displaying to the screen, it must similarly avoid doing that work on off-screen content for representing in the accessibility tree. If this is not possible (for example, if the user agent’s representation of a focusable element in the accessibility tree requires knowledge of its exact position, and thus requires a full layout to be done on it and surrounding contents), then the user agent must omit the skipped contents from the accessibility tree entirely.

注記： この要件は、 ~accessibility~toolを用立てている利用者を［ 計時~channelの観測nなどを介して，識別されたり~profileされること ］から保護するために意図されている。 ~UAが［ 視覚的に具現化する（~~描画する）ときには，有意な量の作業を飛ばせる一方で、 ~accessibility~treeに具現化するときには，すべての作業を行う必要がある ］とした場合、 作者は，［ ~layout演算の計時を観測する ］ことにより［ 利用者が~pageと どうヤリトリしているか ］を調べれることになるので。 ◎ Note: This requirement is intended to protect users utilizing accessibility tooling from being identified and profiled as such via observation of timing channels; if a user agent can skip significant amounts of work when rendering visually, but has to do all of the work when rendering to an accessibility tree, then an author can tell how a user is interacting with the page by observing the timing of layout operations.

4.7. 例

<style>
.sv {
  content-visibility: auto;
  min-height: 50px;
}
</style>

<div class=sv>
  ... 
何らかの内容がここに来る
◎
some content goes here
 ...
</div>

<style>
.sv {
  content-visibility: hidden;
}
</style>

<div class=sv>
  ... 
何らかの内容がここに来る
◎
some content goes here
 ...
</div>

<style>
body {
  margin: 0;
}
.sv {
  content-visibility: hidden;
  position: relative;
  left: 10px;
  top: 20px;
}
#child {
  position: relative;
  left: 1px;
  top: 2px;
  width: 100px;
  height: 200px;
}
</style>

<div id=target class=sv>
  <div id=child></div>
  ... 
何らかの他の内容がここに来る
◎
some other content goes here
 ...
</div>
<script>
  ...
  /* 
次は，~layoutを含む描画~作業を
— ~UAが，それまで それを避けていたなら —
強制することになる。
◎
This will force rendering work, including layout, if the UA previously avoided it.
 */
  target.firstElementChild.getBoundingClientRect();
  ...
</script>