付録 C. 変更点

この付録は参考情報であり、規範的ではない。

以下はCSS2の最初のリビジョン（CSS 2.1）と相対的な変更点である。CSS2仕様（[CSS2]参照）とCSS 2.1（[CSS21]参照）の間の変更点は、CSS 2.1の変更点セクションで見つけることができる。

この章は、変更点の完全なリストではない。マイナーな編集上の変更および例へのほとんどの変更は、ここに記載されない。

C.1 2011年6月7日勧告からの変更点

• [2011-10-12] In “6.2.1 The 'inherit' value,” change

  Each property may also have a cascaded value of 'inherit', which means that, for a given element, the property takes the same specified value as the property for as specified value the computed value of the element's parent.

  (See CSS WG minutes 2011-10-12.)

• [2011-10-12] In “6.1.1 Specified values,” add this clarification:

  1. If the cascade results in a value use it. Except that, if the value is 'inherit', the specified value is defined in “The 'inherit' value” below

  (See CSS WG minutes 2011-10-12.)

• [2012-04-04] In “8.3.1 Collapsing margins,” add a new item as follows:

  隣接する垂直マージンは相殺する。ただし：

  • ルート要素のボックスのマージンは相殺しない。
  • If the top and bottom margins of an element with clearance are adjoining, its margins collapse with the adjoining margins of following siblings but that resulting margin does not collapse with the bottom margin of the parent block.
  • 0でない算出'min-height'および'auto'算出'height'をもつボックスの上マージンがその最後のフロー内の子の下マージンと相殺する場合、子の下マージンは、親の下マージンと相殺しない。

  (See CSS WG minutes 2012-04-04.)

• [2012-04-11] In “10.7 Minimum and maximum heights: 'min-height' and 'max-height',” clarify the note as follows:

  このステップは上記のプロパティの実際の算出値に影響しない。The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).

  These steps do not affect the real computed value of 'height'. したがって、たとえばステップは算出値に依存し、マージンの相殺に影響を与えない。

  (See CSS WG minutes 2012-04-11.)

• [2012-04-11] In “8.3.1 Collapsing margins,” clarify 7th bullet in the 2nd note:

  The bottom margin of an in-flow block box with a 'height' of 'auto' and a 'min-height' of zero collapses with its last in-flow block-level child's bottom margin if the box has no bottom padding and no bottom border and the child's bottom margin does not collapse with a top margin that has clearance.

  'auto'の'height'をもつフロー内のブロックボックスの下マージンは、次の条件を満たす場合、その最後のフロー内のブロックレベルな子の下マージンと相殺する：

  • そのボックスが下パディングを持たず、
  • かつ下ボーダーを持たず、
  • かつ子の下マージンがクリアランスを持つ上マージンと相殺もせず、（ボックスのmin-heightが0でないの場合）そのボックスの上マージンとも相殺しない場合。

  (See CSS WG minutes 2012-04-11.)

• [2012-05-02] In “15.3 Font family: the 'font-family' property,” clarify that using the font name “inherit” without quotes is an error:

  キーワード値（'inherit'、'serif'、'sans-serif'、'monospace'、'fantasy'、'cursive'）と偶然同じになるフォントファミリー名はキーワードとの混乱を防ぐために、引用符で囲まなければならない。キーワード'initial'と'default'は、将来の使用のために予約されており、フォント名として使用する場合も引用符で囲まなければならない。ユーザーエージェントは、'<family-name>'型に一致するものとしてこれらのキーワードを考慮してはならない。

  キーワード値'inherit'、'default'、'initial'、または総称フォントキーワード（'serif'、'sans-serif'、'monospace'、'fantasy'、'cursive'）と偶然同じになる引用符で囲まれないフォントファミリー名は、'<family-name>'型と一致しない。これらの名前は、同じ名前をもつキーワードとの混乱を防ぐために引用符で囲まなければならない。したがって、'font-family: Times, inherit'は無効な宣言であることに注意する。なぜなら、その位置における'inherit'は、妥当なキーワードでも妥当なフォントファミリー名でもないからである。

  (See CSS WG minutes 2012-05-02.)

• [2012-05-02] Spaces and comments are not allowed between the sign and the digits of a <number>, <length> or <percentage>. In “4.3.1 Integers and real numbers,” insert “immediately” as follows:

  Both integers and real numbers may immediately be preceded by a "-" or "+" to indicate the sign.

  In “4.1.1 Tokenization,” allow "+" or "-" at the start of the {num} macro:

  num	[-+]?[0-9]+|[-+]?[0-9]*\.[0-9]+

  (Note that this changes the definition of three tokens, NUMBER, DIMENSION and PERCENTAGE, and thus the tokenization of CSS, but it does not change the language generated by the grammar as a whole.)

  No change is required in 4.3.2 (<length>) or 4.3.3 (<percentage>), because they refer to 4.3.1.

  (See CSS WG minutes 2012-05-02.)

• [2012-08-01] In 10.1 “Definition of "containing block,"” change:

  1. […]
  2. For other elements, if the element's position is 'relative' or 'static', the containing block is formed by the content edge of the nearest ancestor box that is a block container ancestor box or which establishes a formatting context.

  (See CSS WG minutes 2012-08-01.)

• [2012-08-01] In 9.4 “Normal flow,” replace as follows:

  Boxes in the normal flow belong to a formatting context, which in CSS 2 may be table, block or inline, but not both simultaneously. In future levels of CSS, other types of formatting context will be introduced. Block-level boxes participate in a block formatting context. Inline-level boxes participate in an inline formatting context. Table formatting contexts are described in the chapter on tables.

  (See CSS WG minutes 2012-08-01.)

• [2012-08-01] In 9.4.2 “Inline formatting contexts,” add this sentence:

  An inline formatting context is established by a block container box that contains no block-level boxes. In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block.

  (See CSS WG minutes 2012-08-01.)

• [2012-08-01] In 17.4 “Tables in the visual formatting model,” replace as follows:

  テーブルがブロックレベルであれば、テーブルラッパーボックスは'ブロック'ボックスに、テーブルがインラインレベルあれば、'インラインブロック'ボックスとなる。The table wrapper box establishes a block formatting context, and the table box establishes a table formatting context.

  (See CSS WG minutes 2012-08-01.)

• [2012-08-01] In 17.5 “Visual layout of table contents,” replace as follows:

  Internal table elements generate rectangular boxes with which participate in the table formatting context established by the table box. These boxes have content and borders. and cells have padding as well. 内部テーブル要素は、マージンを持たない。

  (See CSS WG minutes 2012-08-01.)

• [2012-08-01] In 11.1.1 “Overflow: the 'overflow' property,” change:

  Applies to: block containers and boxes that establish a formatting context

  (See CSS WG minutes 2012-08-01.)

• [2013-04-29] The letters u, r and l of the URI token may be written as escapes. In 4.1.1 “Tokenization,” change in the first table:

  URI	url{U}{R}{L}\({w}{string}{w}\) |url{U}{R}{L}\({w}([!#$%&*-\[\]-~]|{nonascii}|{escape})*{w}\)

  and in the second table:

  baduri1	url{U}{R}{L}\({w}([!#$%&*-~]|{nonascii}|{escape})*{w}
  baduri2	url{U}{R}{L}\({w}{string}{w}
  baduri3	url{U}{R}{L}\({w}{badstring}

  And add to the second table:

  L	l|\\0{0,4}(4c|6c)(\r\n|[ \t\r\n\f])?|\\l
  R	r|\\0{0,4}(52|72)(\r\n|[ \t\r\n\f])?|\\r
  U	u|\\0{0,4}(55|75)(\r\n|[ \t\r\n\f])?|\\u

  (See CSS WG minutes 2013-01-30.)

• [2013-04-29] The letters u, r and l of the URI token may be written as escapes (see the previous errata). In G.2 “Lexical scanner,” change:

  baduri1         url{U}{R}{L}\({w}([!#$%&*-\[\]-~]|{nonascii}|{escape})*{w}
  baduri2         url{U}{R}{L}\({w}{string}{w}
  baduri3         url{U}{R}{L}\({w}{badstring}

  and

  "url("{U}{R}{L}"("{w}{string}{w}")" {return URI;}
  "url("{U}{R}{L}"("{w}{url}{w}")"    {return URI;}

  (See CSS WG minutes 2013-01-30.)

• [2013-04-29] Unicode control characters between U+0080 and U+009F can be used in identifiers and in URI tokens. (Previously such characters made the style sheet invalid.) In 4.1.1 “Tokenization,” change:

  nonascii

  [^\0-\237\177]

  (See CSS WG minutes 2013-01-30.)

• [2013-04-29] Unicode control characters between U+0080 and U+009F can be used in identifiers and in URI tokens. (Previously such characters made the style sheet invalid.) In 4.1.3 “Characters and case,” change:

  • In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-zA-Z0-9] and ISO 10646 characters U+00A0 U+0080 and higher, plus the hyphen (-) and the underscore (_);

  (See CSS WG minutes 2013-01-30.)

• [2013-05-02] When a CSS file is known to be in a UTF-based character encoding, based on out-of-band information, and the file starts with a BOM, then the BOM determines which of the UTF-based encodings is used, overriding the out-of-band information. In 4.4 “CSS style sheet representation,” insert:

  上記の規則1（HTTP "charset"パラメーターまたは類似のもの）が文字エンコーディングをもたらし、かつUTF-8、UTF-16またはUTF-32のいずれかである場合、もしあれば、ファイルの先頭のBOMは、以下のように文字エンコーディングを上書きする：

  先頭バイト（16進数）	エンコーディングの結果
  00 00 FE FF	UTF-32、ビッグエンディアン
  FF FE 00 00	UTF-32、リトルエンディアン
  FE FF	UTF-16、ビッグエンディアン
  FF FE	UTF-16、リトルエンディアン
  EF BB BF	UTF-8

  規則1がUTF-16BE、UTF-16LE、UTF-32BEまたはUTF-32LEの文字エンコーディングをもたらす場合、ファイルがBOMで開始するならばエラーとなる。CSSユーザーエージェントは、指定された文字エンコーディングを無視し、上記テーブルを使用することによって回復されなければならない。

  Note that the fact that a BOM at the start of a file is an error in UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE is specified by [UNICODE].

  (See CSS WG minutes 2012-10-24.)

• [2013-07-15] In 11.1.1 “Overflow: the 'overflow' property,” change the definition of 'scroll' and 'auto':

  scroll

  この値は、コンテンツが切り抜かれるよう指示する。ユーザーエージェントが画面上で可視のスクロールメカニズム（スクロールバーやパン表示など）を用いる場合、そのメカニズムは、そのコンテンツが切り抜かれたどうかに関わらずボックスを表示されるべきである。これは、動的な環境で現れたり消えたりするスクロールバーの問題を回避する。この値が指定されかつ対象メディアが'print'である場合、はみ出したコンテンツは印刷されてもよい。When used on table boxes, this value has the same meaning as 'visible'.

  auto

  'auto'値の振る舞いはユーザーエージェント依存だが、はみ出したボックスにスクロールメカニズムを提供させるべきである。When used on table boxes, this value has the same meaning as 'visible'.

  (See CSS WG minutes 2012-08-08.)

• [2013-07-15] In 15.3 Font family: the 'font-family' property the grammar is missing a pair of brackets:

  Value: [[ <family-name> | <generic-family> ] [, [ <family-name>| <generic-family> ] ]* ] | inherit

  (See CSS WG minutes 2012-05-03.)

• [2013-07-15] Spaces and comments are not allowed between the sign and the digits of a <number>, <length> or <percentage>. In “G.2 Lexical scanner,” change the {num} macro as follows:

  num		[-+]?[0-9]+|[-+]?[0-9]*"."[0-9]+

  In “G.1 Grammar,” remove unary_operator from the grammar:

  unary_operator
    : '-' | '+'
    ;

  and

  term
    : unary_operator?
      [ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* |
        TIME S* | FREQ S* ]
    | STRING S* | IDENT S* | URI S* | hexcolor | function
    ;

  (See CSS WG minutes 2012-05-02.)

• [2013-07-18] A percentage on 'height', even if not used, can be inherited. In “10.5 Content height: the 'height' property,” change the “computed value” line as follows:

  算出値：	the percentage or 'auto' (see prose under <percentage>) (as specified)

  and in the definition of <percentage>:

  <percentage>

  パーセント高さを指定する。割合は生成ボックスの包含ブロックの高さに対して計算される。If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto' the used height is calculated as if 'auto' was specified.

  (See CSS WG minutes 2013-05-08.)

• [2013-09-09] In “4.1.1 Tokenization,” make the UNICODE-RANGE token more precise:

  UNICODE-RANGE

  u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})? u\+[?]{1,6}| u\+[0-9a-f]{1}[?]{0,5}| u\+[0-9a-f]{2}[?]{0,4}| u\+[0-9a-f]{3}[?]{0,3}| u\+[0-9a-f]{4}[?]{0,2}| u\+[0-9a-f]{5}[?]{0,1}| u\+[0-9a-f]{6}| u\+[0-9a-f]{1,6}-[0-9a-f]{1,6}

  E.g., “U+A?5” previously was a single UNICODE-RANGE token (although a semantically meaningless one), now this is two tokens: “U+A?” (meaning the 16-character range U+A0-AF) and the number “5”.

  (See CSS WG minutes 2013-09-03.)

• [2012-09-19] Modify “9.2 Controlling box generation” and “9.2.1 Block-level elements and block boxes” as follows:

  ボックスの生成を制御する

  以下の節は、CSS 2.1で生成されてもよいボックスの種類について説明する。視覚整形モデルにおいて、部分的にボックスの種類はボックスの動作に影響を与える。The 'display' property, described below, specifies a box's type.

  Certain values of the ''display' property cause an element of the source document to generate a principal box that contains descendant boxes and generated content and is also the box involved in any positioning scheme. 一部の要素（'list-item'要素）は、主要ボックスに加えて追加ボックスを生成してもよい。この追加ボックスは主要ボックスを基準にして配置される。

  9.2.1 ブロックレベル要素とブロックボックス

  Block-level elements are those elements of the source document that are formatted visually as blocks (e.g., paragraphs). The following values of the 'display' property make an element block-level: 'block', 'list-item', and 'table'.

  Block-level elements – those elements of the source document that are formatted visually as blocks (e.g., paragraphs) – are elements which generate a block-level principal box. Values of the 'display' property that make an element block-level include: 'block', 'list-item', and 'table'. Block-level boxes are boxes that participate in a block formatting context.

  Block-level boxes are boxes that participate in a block formatting context. Each block-level element generates a principal block-level box that contains descendant boxes and generated content and is also the box involved in any positioning scheme. 一部のブロックレベル要素（'list-item'要素）は、主ボックスに加えて追加のボックスを生成してもよい。この追加ボックスは主要ボックスを基準にして配置される。

  Except for table boxes, which are described in a later chapter, and replaced elements, In CSS 2, a block-level box is also a block container box unless it is a table box or the principal box of a replaced element. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. An element whose principal box is a block container box is a block container element. Values of the 'display' property which make a non-replaced element generate a block container include 'block', 'list-item' and 'inline-block'. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but are not block-level boxes. Block-level boxes that are also block containers are called block boxes.

  3つの用語"ブロックレベルボックス"、"ブロックコンテナボックス"、"ブロックボックス"は明確である場合に"ブロック"と略される。

• [2012-09-19] Modify “9.2.4 The 'display' property” as follows:

  block

  This value causes an element to generate a principal block box.

  inline-block

  This value causes an element to generate an a principal inline-level block container. (The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box.)

• [2012-09-19] Modify “17.4 Tables in the visual formatting model” as follows:

  In both cases, the table generates a principal block container box called the table wrapper box that contains the table box itself and any caption boxes (in document order). The table box is a block-level box that contains the table's internal table boxes. The caption boxes are principal block-level boxes that retain their own content, padding, margin, and border areas, and are rendered as normal block boxes inside the table wrapper box. 以下で説明するように、キャプションボックスがテーブルボックスの前または後に配置されるかどうかは、'caption-side'プロパティによって決定される。

  The table wrapper box is a 'block' box if the table is block-level block-level for 'display: table', and an 'inline-block' box if the table is inline-level inline-level for 'display: inline-table'. テーブルラッパーボックスは、ブロック整形コンテキストを設置し、そしてテーブルボックスはテーブル整形コンテキストを設置する。'inline-table'に対してベースラインの垂直方向の配置を行う場合、（テーブルラッパーボックスでなく）テーブルボックスが使用される。17.5.2節で説明されるように、テーブルラッパーボックスの幅は、その内部のテーブルボックスのボーダー辺の幅である。テーブルの'width'および'height'のパーセンテージは、テーブルラッパーボックス自身ではなく、テーブルラッパーボックスの包含ブロックを基準にする。

• [2012-09-19] For compatibility with SVG, modify the definition of macro num in “4.1.1 Tokenization” as follows:

  num	[-+]?[0-9]+|[-+]?[0-9]*\.[0-9]+
  num	[+-]?([0-9]+|[0-9]*\.[0-9]+)(e[+-]?[0-9]+)?

• [2014-07-16] The background of the canvas cannot be taken from an element that is suppressed with 'display: none'. On the other hand, if the element is merely invisible ('visibility: hidden'), its background can still be used for the canvas. In other words, if the root element has 'display: none', the background of the canvas is undefined. In the case of (X)HTML documents, if the root element has 'background: transparent' and the <body> element has 'display: none', the background of the canvas is likewise undefined. Change the text in “14.2 The background” as follows:

  […] Such backgrounds must also be anchored at the same point as they would be if they were painted only for the root element.

  しかし、キャンバスの背景に使用される要素の背景に対してどのボックスも生成されない場合、キャンバスの背景は透過である。(in CSS 2, that is the case when the element or an ancestor has 'display: none'.)

  要素が'visibility: hidden'を持つが'display: none'を持たない場合、ボックスは要素に対して生成されかつその要素の背景はキャンバスに対して使用されることに注意する。

• [2015-07-01] An element with 'position: fixed' always establishes a new stacking context. (This is different from 'position: absolute', where 'z-index' determines if the element establishes a stacking context or not.)

  Change the definition of 'auto' in “9.9.1 Specifying the stack level: the 'z-index' property” as follows:

  auto

  現在のスタックコンテキストにおける生成ボックスのスタックレベルは0になる。The box does not establish a new stacking context unless it is the root element. If the box has 'position: fixed' or if it is the root, it also establishes a new stacking context.

• [2015-09-05] Malformed declarations are handled differently when the start of the malformed declaration conforms to the syntax of an at-rule. In that case, parsing resumes not at the next semicolon or at the closing curly brace of the enclosing block, but immediately after that at-rule. This is expressed by adding the at-rule to the core syntax for rulesets, as shown below.

  In “4.1.1 Tokenization”, change the production for ruleset as follows:

  ruleset     : selector?'{' S* declaration?[ ';' S* declaration?]* '}' S*;
  ruleset     : selector?'{' S* declaration-list '}' S*;
  declaration-list: declaration [ ';' S* declaration-list ]?
                | at-rule declaration-list
                | /* empty */;

  In “4.1.7 Rule sets, declaration blocks, and selectors”, change the second paragraph as follows:

  A declaration block starts with a left curly brace ({) and ends with the matching right curly brace (}). In between there must be a list of zero or more semicolon-separated (;) declarations declarations and at-rules. Declarations must end with a semicolon (;) unless they are last in the list.

  注：CSS level 2は、規則セット内に出現してもよい@規則を持たないが、そのような@規則は将来のレベルでで定義されてもよい。

  In “4.2 Rules for handling parsing errors”, change the rule for malformed declarations as follows:

  • 不正な形式の宣言。 ユーザーエージェントは、()、[]、{}、""、''のペア、および正確なエスケープ処理と一致する規則を遵守しつつ、宣言の最後まで読むことで、宣言の解析中に遭遇した予期しないトークンを処理しなければならない。たとえば、不正な形式の宣言は、プロパティ名、コロン（:）またはプロパティ値を見逃してもよい。

    ユーザーエージェントが宣言または@規則（すなわち、IDENTトークンまたはATKEYWORDトークン）の開始を期待するが、代わりに予期しないトークンを検出する場合、そのトークンは不正な形式の宣言の最初のトークンであると考えられる。すなわち、不正な形式の文よりもむしろ不正な形式の宣言のための規則が、そのような場合に無視できるトークンを決定するために使用される。

    次はすべて等価である：

    p { color:green }
    p { @foo { bar: baz } color:green }  /* unknown at-rule */
    p { color:green; color }  /* malformed declaration missing ':', value */
    p { color:red;   color; color:green }  /* same with expected recovery */
    p { color:green; color: } /* malformed declaration missing value */
    p { color:red;   color:; color:green } /* same with expected recovery */
    p { color:green; color{;color:maroon} } /* unexpected tokens { } */
    	 p { color:red;   color{;color:maroon}; color:green } /* same with recovery */

  And, finally, in “13.2 Page boxes: the @page rule”, remove the following text, which is now redundant:

  不正な形式の宣言、不正な形式の文、および@page内の不正な@規則を扱うための規則は、以下に加えて4.2節で定義される。ユーザーエージェントが宣言または@規則の開始（すなわち、IDENTトークンまたはATKEYWORDトークン）を予期するが代わりに予期しないトークンを検出する場合、そのトークンは不正な形式の宣言の最初のトークンであると考えられる。すなわち、不正な形式の文よりもむしろ不正な形式の宣言のための規則が、そのような場合に無視できるトークンを決定するために使用される。