부록 C. 변경 사항

이 부록은 정보 제공용이며, 표준 문서는 아닙니다.

아래는 CSS2의 첫 번째 개정판(CSS 2.1)에 대한 변경 사항입니다. CSS2 명세(참조 [CSS2])와 CSS 2.1(참조 [CSS21]) 간의 변경 사항은 CSS 2.1 변경 사항 섹션에서 확인할 수 있습니다.

이 장은 변경 사항의 완전한 목록이 아닙니다. 경미한 편집 변경 사항과 대부분의 예제 변경 사항은 여기에 나열되지 않습니다.

C.1 2011년 6월 7일 권고 이후의 변경 사항

• [2011-10-12] “6.2.1 The 'inherit' value,”에서 다음과 같이 변경:

  각 속성은 'inherit'라는 계단식 값을 가질 수도 있으며, 이는 특정 요소에 대해 그 속성이 부모의 속성과 동일한 지정 값을 지정 값으로 부모 요소의 계산된 값을 갖는다는 것을 의미합니다.

  (CSS WG 회의록 2011-10-12 참조)

• [2011-10-12] “6.1.1 Specified values,”에 다음 설명을 추가:

  1. 계단식 결과가 값으로 결정되면 그 값을 사용한다. 단, 값이 'inherit'인 경우, 지정 값은 아래의 “The 'inherit' value”에서 정의된다.

  (CSS WG 회의록 2011-10-12 참조)

• [2012-04-04] “8.3.1 Collapsing margins,”에 다음과 같이 새 항목을 추가:

  인접한 수직 여백은 축소되지만, 다음은 예외:

  • 루트 요소 상자의 여백은 축소되지 않는다.
  • clearance가 있는 요소의 위쪽과 아래쪽 여백이 인접한 경우, 그 여백은 뒤따르는 형제들의 인접 여백과 축소되지만 그렇게 얻어진 결과 여백은 부모 블록의 아래쪽 여백과는 축소되지 않는다.
  • 계산된 'min-height'가 0이 아니고 계산된 'height'가 'auto'인 상자의 위쪽 여백이 그 상자의 마지막 인플로우 자식의 아래쪽 여백과 축소되는 경우, 자식의 아래쪽 여백은 부모의 아래쪽 여백과 축소되지 않는다.

  (CSS WG 회의록 2012-04-04 참조)

• [2012-04-11] “10.7 Minimum and maximum heights: 'min-height' and 'max-height',”의 주석을 다음과 같이 명확화:

  이 단계들은 위의 속성들에 대한 실제 계산 값에 영향을 주지 않는다. 사용된 'height'의 변경은 "Collapsing margins"(8.3.1)에서 'min-height' 또는 'max-height' 규칙으로 특별히 요구되는 경우를 제외하고 여백 축소에 영향을 미치지 않는다.

  이 단계들은 'height'의 실제 계산 값에 영향을 주지 않는다. 따라서, 예를 들어, 계산 값에 의존하는 여백 축소에도 영향을 주지 않는다.

  (CSS WG 회의록 2012-04-11 참조)

• [2012-04-11] “8.3.1 Collapsing margins,”의 두 번째 주석 중 7번째 항목을 다음과 같이 명확화:

  'height'가 'auto'이고 'min-height'가 0인 인플로우 블록 상자의 아래쪽 여백은, 상자에 아래쪽 패딩과 아래쪽 테두리가 없고 자식의 아래쪽 여백이 clearance가 있는 위쪽 여백과 축소되지 않는다면 마지막 인플로우 블록 수준 자식의 아래쪽 여백과 축소된다.

  'height'가 'auto'인 인플로우 블록 상자의 아래쪽 여백은, 다음의 경우 마지막 인플로우 블록 수준 자식의 아래쪽 여백과 축소된다:

  • 상자에 아래쪽 패딩이 없고,
  • 상자에 아래쪽 테두리가 없으며,
  • 자식의 아래쪽 여백이 clearance가 있는 위쪽 여백과도 축소되지 않고, (상자의 min-height가 0이 아닌 경우) 상자의 위쪽 여백과도 축소되지 않는다.

  (CSS WG 회의록 2012-04-11 참조)

• [2012-05-02] “15.3 Font family: the 'font-family' property,”에서 따옴표 없이 폰트 이름 “inherit”를 사용하는 것은 오류임을 명확화:

  키워드 값('inherit', 'serif', 'sans-serif', 'monospace', 'fantasy', 'cursive')과 같은 이름을 가진 폰트 패밀리 이름은 동일한 이름의 키워드와 혼동을 피하기 위해 반드시 따옴표로 감싸야 한다. 'initial'과 'default' 키워드는 향후 사용을 위해 예약되어 있으며 폰트 이름으로 사용할 때 역시 따옴표로 감싸야 한다. UA는 이러한 키워드들을 '<family-name>' 타입으로 간주해서는 안 된다.

  따옴표 없는 폰트 패밀리 이름이 'inherit', 'default', 'initial' 키워드 값이나 일반 폰트 키워드('serif', 'sans-serif', 'monospace', 'fantasy', 'cursive')와 동일한 경우 '<family-name>' 타입과 일치하지 않는다. 이러한 이름은 동일한 이름의 키워드와의 혼동을 방지하기 위해 반드시 따옴표로 감싸야 한다. 따라서 'font-family: Times, inherit'는 해당 위치의 'inherit'가 유효한 키워드도 유효한 폰트 패밀리 이름도 될 수 없으므로 잘못된 선언이다.

  (CSS WG 회의록 2012-05-02 참조)

• [2012-05-02] <number>, <length>, <percentage>의 부호와 숫자 사이에는 공백과 주석이 허용되지 않는다. “4.3.1 Integers and real numbers,”에서 다음과 같이 “immediately”를 삽입:

  정수와 실수는 부호를 나타내기 위해 "-" 또는 "+"가 즉시 앞에 붙을 수 있다.

  “4.1.1 Tokenization,”에서 {num} 매크로의 시작에 "+" 또는 "-"를 허용:

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

  (이는 NUMBER, DIMENSION, PERCENTAGE의 세 토큰 정의를 변경하여 CSS의 토큰화를 바꾸지만, 전체 문법이 생성하는 언어 자체는 변경되지 않음을 주의.)

  4.3.2(<length>)와 4.3.3(<percentage>)는 4.3.1을 참조하므로 변경 없음.

  (CSS WG 회의록 2012-05-02 참조)

• [2012-08-01] 10.1 “Definition of "containing block,"”에서 다음과 같이 변경:

  1. […]
  2. 다른 요소들의 경우, 요소의 position이 'relative' 또는 'static'이면, 포함 블록은 가장 가까운 block container인 조상 상자의 콘텐츠 에지로 조상 상자 또는 포매팅 컨텍스트를 설정하는 상자에 의해 형성된다.

  (CSS WG 회의록 2012-08-01 참조)

• [2012-08-01] 9.4 “Normal flow,”를 다음과 같이 대체:

  일반 흐름의 상자들은 formatting context에 속하며, CSS 2에서는 table, block 또는 inline일 수 있다, 단 동시에 둘 다일 수는 없다. 향후 CSS 레벨에서는 다른 유형의 포매팅 컨텍스트가 도입될 것이다. Block-level 상자들은 block formatting 컨텍스트에 참여한다. Inline-level 상자들은 inline formatting 컨텍스트에 참여한다. 테이블 포매팅 컨텍스트는 테이블 장에서 설명한다.

  (CSS WG 회의록 2012-08-01 참조)

• [2012-08-01] 9.4.2 “Inline formatting contexts,”에 다음 문장을 추가:

  인라인 포매팅 컨텍스트는 블록 수준 상자를 포함하지 않는 블록 컨테이너 상자에 의해 설정된다. 인라인 포매팅 컨텍스트에서는 상자들이 포함 블록의 위쪽에서 시작하여 가로로 하나씩 배치된다.

  (CSS WG 회의록 2012-08-01 참조)

• [2012-08-01] 17.4 “Tables in the visual formatting model,”을 다음과 같이 대체:

  테이블이 블록 수준이면 테이블 래퍼 상자는 'block' 상자이고, 테이블이 인라인 수준이면 'inline-block' 상자이다. 테이블 래퍼 상자는 블록 포매팅 컨텍스트를 설정하고, 테이블 상자는 테이블 포매팅 컨텍스트를 설정한다.

  (CSS WG 회의록 2012-08-01 참조)

• [2012-08-01] 17.5 “Visual layout of table contents,”을 다음과 같이 대체:

  내부 테이블 요소들은 직사각형 boxes를 생성하며 with 이 상자들은 테이블 상자가 설정한 테이블 포매팅 컨텍스트에 참여한다. 이 상자들은 콘텐츠와 테두리를 가지며. 또한 셀은 패딩도 가진다. 내부 테이블 요소는 여백을 가지지 않는다.

  (CSS WG 회의록 2012-08-01 참조)

• [2012-08-01] 11.1.1 “Overflow: the 'overflow' property,”에서 다음과 같이 변경:

  Applies to: block containers 및 포매팅 컨텍스트를 설정하는 상자

  (CSS WG 회의록 2012-08-01 참조)

• [2013-04-29] URI 토큰의 u, r, l 글자는 이스케이프로도 작성할 수 있다. 4.1.1 “Tokenization,”의 첫 번째 표에서 다음과 같이 변경:

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

  그리고 두 번째 표에서는:

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

  또한 두 번째 표에 다음을 추가:

  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

  (CSS WG 회의록 2013-01-30 참조)

• [2013-04-29] URI 토큰의 u, r, l 글자는 이스케이프로도 작성할 수 있음(이전 정오표 참조). G.2 “Lexical scanner,”에서 다음과 같이 변경:

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

  그리고:

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

  (CSS WG 회의록 2013-01-30 참조)

• [2013-04-29] U+0080과 U+009F 사이의 유니코드 제어 문자는 식별자와 URI 토큰에서 사용할 수 있다(이전에는 이러한 문자가 스타일시트를 무효로 만들었다). 4.1.1 “Tokenization,”에서 다음과 같이 변경:

  nonascii

  [^\0-\237\177]

  (CSS WG 회의록 2013-01-30 참조)

• [2013-04-29] U+0080과 U+009F 사이의 유니코드 제어 문자는 식별자와 URI 토큰에서 사용할 수 있다(이전에는 이러한 문자가 스타일시트를 무효로 만들었다). 4.1.3 “Characters and case,”에서 다음과 같이 변경:

  • CSS에서 identifiers(selectors의 요소 이름, 클래스, ID 포함)은 [a-zA-Z0-9]와 ISO 10646 문자 U+00A0 U+0080 이상, 그리고 하이픈(-)과 밑줄(_)만 포함할 수 있다;

  (CSS WG 회의록 2013-01-30 참조)

• [2013-05-02] CSS 파일이 외부 정보에 근거하여 UTF 계열 문자 인코딩임이 알려져 있고, 파일이 BOM,으로 시작하는 경우, 해당 BOM이 어떤 UTF 인코딩을 사용할지를 결정하여 외부 정보를 무시한다. 4.4 “CSS style sheet representation,”에 다음을 삽입:

  위의 규칙 1(HTTP "charset" 매개변수 또는 유사한 것)로 문자 인코딩이 결정되고 그것이 UTF-8, UTF-16 또는 UTF-32 중 하나인 경우, 파일 시작의 BOM(있다면)이 다음과 같이 그 문자 인코딩을 재정의한다:

  처음 바이트(16진수)	결과 인코딩
  00 00 FE FF	UTF-32, big-endian
  FF FE 00 00	UTF-32, little-endian
  FE FF	UTF-16, big-endian
  FF FE	UTF-16, little-endian
  EF BB BF	UTF-8

  규칙 1이 문자 인코딩으로 UTF-16BE, UTF-16LE, UTF-32BE 또는 UTF-32LE를 산출할 때, 파일이 BOM으로 시작하면 이는 오류이다. CSS UA는 지정된 인코딩을 무시하고 위 표를 사용하여 복구해야 한다.

  파일 시작의 BOM이 UTF-16BE, UTF-16LE, UTF-32BE 또는 UTF-32LE에서 오류임은 [UNICODE]에 규정되어 있다.

  (CSS WG 회의록 2012-10-24 참조)

• [2013-07-15] 11.1.1 “Overflow: the 'overflow' property,”에서 'scroll'과 'auto'의 정의를 다음과 같이 변경:

  scroll

  이 값은 콘텐츠가 잘리며, 사용자 에이전트가 화면에 표시되는 스크롤 메커니즘(스크롤 바나 패너 등)을 사용하는 경우, 콘텐츠가 잘렸는지 여부와 관계없이 상자에 그 메커니즘을 표시해야 함을 나타낸다. 이는 동적 환경에서 스크롤바가 나타났다 사라지는 문제를 방지한다. 이 값이 지정되고 대상 매체가 'print'인 경우, 넘치는 콘텐츠가 인쇄될 수 있다. table boxes에서 사용될 때, 이 값은 'visible'과 동일한 의미를 갖는다.

  auto

  'auto' 값의 동작은 사용자 에이전트에 따라 다르지만, 넘치는 상자에 대해 스크롤 메커니즘을 제공해야 한다. table boxes에서 사용될 때, 이 값은 'visible'과 동일한 의미를 갖는다.

  (CSS WG 회의록 2012-08-08 참조)

• [2013-07-15] 15.3 Font family: the 'font-family' property의 문법에 대괄호 한 쌍이 누락되어 있어 다음과 같이 수정:

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

  (CSS WG 회의록 2012-05-03 참조)

• [2013-07-15] <number>, <length>, <percentage>의 부호와 숫자 사이에는 공백과 주석이 허용되지 않는다. “G.2 Lexical scanner,”에서 {num} 매크로를 다음과 같이 변경:

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

  “G.1 Grammar,”에서 문법의 unary_operator를 제거:

  unary_operator
    : '-' | '+'
    ;

  그리고 다음과 같이 변경:

  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
    ;

  (CSS WG 회의록 2012-05-02 참조)

• [2013-07-18] 'height'의 백분율 값은 사용되지 않더라도 상속될 수 있다. “10.5 Content height: the 'height' property,”에서 “computed value” 라인을 다음과 같이 변경:

  Computed value:

  the percentage or 'auto' (see prose under <percentage>) (as specified)

  그리고 <percentage>의 정의에서 다음과 같이 변경:

  <percentage>

  백분율 높이를 지정한다. 백분율은 생성된 상자의 containing block의 높이를 기준으로 계산된다. 포함 블록의 높이가 명시적으로 지정되지 않았고 (즉, 콘텐츠 높이에 의존) 이 요소가 절대 위치가 아닌 경우, 값은 'auto'로 계산된다 사용된 높이는 'auto'가 지정된 것처럼 계산된다.

  (CSS WG 회의록 2013-05-08 참조)

• [2013-09-09] “4.1.1 Tokenization,”에서 UNICODE-RANGE 토큰을 보다 정밀하게 변경:

  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}

  예: “U+A?5”는 이전에는 (의미적으로 무의미하더라도) 단일 UNICODE-RANGE 토큰이었으나, 이제는 “U+A?”(16문자 범위 U+A0–AF 의미)와 숫자 “5”의 두 토큰이다.

  (CSS WG 회의록 2013-09-03 참조)

• [2012-09-19] “9.2 Controlling box generation”과 “9.2.1 Block-level elements and block boxes”를 다음과 같이 수정:

  Controlling box generation

  다음 절에서는 CSS 2.1에서 생성될 수 있는 상자의 유형을 설명한다. 상자의 유형은 부분적으로 시각적 포매팅 모델에서의 동작에 영향을 준다. 아래에 설명된 'display' 속성이 상자의 유형을 지정한다.

  'display' 속성의 특정 값은 원본 문서의 요소가 자손 상자와 생성된 콘텐츠를 포함하고 어떤 위치 지정 체계에도 관여하는 principal box를 생성하게 한다. 일부 요소(예: 'list-item')는 주 상자(principal box) 외에 추가 상자를 생성할 수 있으며, 이러한 추가 상자는 주 상자를 기준으로 배치된다.

  9.2.1 Block-level elements and block boxes

  Block-level elements는 (예: 문단)처럼 시각적으로 블록으로 서식화되는 원본 문서의 요소들이다. 'display' 속성의 다음 값들은 요소를 블록 수준으로 만든다: 'block', 'list-item', 'table'.

  Block-level elements – (예: 문단)처럼 시각적으로 블록으로 서식화되는 원본 문서의 요소들 – 은 블록 수준의 주 상자를 생성하는 요소를 말한다. 요소를 블록 수준으로 만드는 'display' 속성 값에는 'block', 'list-item', 'table'이 포함된다. Block-level boxes는 블록 포매팅 컨텍스트에 참여하는 상자들이다.

  Block-level boxes는 블록 포매팅 컨텍스트에 참여하는 상자들이다. 각 블록 수준 요소는 자손 상자와 생성된 콘텐츠를 포함하고 어떤 위치 지정 체계에도 관여하는 principal block-level box를 생성한다. 일부 블록 수준 요소('list-item')는 주 상자 외에 추가 상자를 생성할 수 있으며, 이러한 추가 상자들은 주 상자를 기준으로 배치된다.

  나중 장에서 설명되는 테이블 상자와 대체(replaced) 요소를 제외하고, CSS 2에서, 블록 수준 상자는 또한 블록 컨테이너 상자이지만 테이블 상자이거나 대체 요소의 주 상자인 경우는 예외이다. block container box는 블록 수준 상자만 포함하거나 인라인 포매팅 컨텍스트를 설정하여 인라인 수준 상자만 포함한다. 주 상자가 블록 컨테이너 상자인 요소를 block container element라고 한다. 대체되지 않은 요소가 블록 컨테이너를 생성하도록 하는 'display' 값에는 'block', 'list-item', 'inline-block'이 포함된다. 모든 블록 컨테이너 상자가 블록 수준 상자인 것은 아니다. 대체되지 않은 인라인 블록과 대체되지 않은 테이블 셀은 블록 컨테이너이지만 블록 수준 이 아닌 상자이다. 블록 컨테이너이기도 한 블록 수준 상자를 block boxes라고 한다.

  "block-level box", "block container box", "block box"라는 세 용어는 문맥상 명확할 때 "block"으로 약칭된다.

• [2012-09-19] “9.2.4 The 'display' property”를 다음과 같이 수정:

  block

  이 값은 요소로 하여금 주(principal) 블록 상자를 생성하게 한다.

  inline-block

  이 값은 요소로 하여금 an 주(principal) 인라인 수준 블록 컨테이너를 생성하게 한다. (인라인 블록의 내부는 블록 상자로 서식화되며, 요소 자체는 원자적 인라인 수준 상자로 서식화된다.)

• [2012-09-19] “17.4 Tables in the visual formatting model”을 다음과 같이 수정:

  두 경우 모두, 테이블은 문서 순서로 테이블 상자 자체와 모든 캡션 상자를 포함하는 table wrapper box라는 주 블록 컨테이너 상자를 생성한다. table box는 테이블의 내부 테이블 상자들을 포함하는 블록 수준 상자이다. 캡션 상자들은 자체의 콘텐츠, 패딩, 마진, 테두리 영역을 유지하는 주(principal) 블록 수준 상자이며, 테이블 래퍼 상자 내부에서 일반 블록 상자처럼 렌더링된다. 캡션 상자를 테이블 상자 앞에 둘지 뒤에 둘지는 아래에 설명된 'caption-side' 속성이 결정한다.

  테이블 래퍼 상자는 테이블이 블록 수준이면 'block' 상자 'display: table'에서는 블록 수준이고, 테이블이 인라인 수준이면 'inline-block' 상자 'display: inline-table'에서는 인라인 수준이다. 테이블 래퍼 상자는 블록 포매팅 컨텍스트를 설정하고, 테이블 상자는 테이블 포매팅 컨텍스트를 설정한다. 'inline-table'의 기준선 수직 정렬을 수행할 때 사용되는 것은 테이블 래퍼 상자가 아니라 테이블 상자이다. 테이블 래퍼 상자의 너비는 17.5.2 절에 설명된 대로 내부의 테이블 상자의 경계(edge) 너비이다. 테이블의 'width'와 'height'에 대한 백분율은 테이블 래퍼 상자 자체가 아니라 테이블 래퍼 상자의 포함 블록을 기준으로 한다.

• [2012-09-19] SVG와의 호환성을 위해 “4.1.1 Tokenization”의 num 매크로 정의를 다음과 같이 수정:

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

• [2014-07-16] 캔버스의 배경은 'display: none'으로 억제된 요소에서 가져올 수 없다. 반면 요소가 단지 보이지 않을 뿐('visibility: hidden'), 그 배경은 여전히 캔버스에 사용할 수 있다. 즉, 루트 요소가 'display: none'이면 캔버스의 배경은 정의되지 않는다. (X)HTML 문서의 경우, 루트 요소가 'background: transparent'이고 <body> 요소가 'display: none'이면, 캔버스의 배경 역시 정의되지 않는다. “14.2 The background”의 텍스트를 다음과 같이 변경:

  […] 이러한 배경은 루트 요소에 대해서만 그려졌을 때와 동일한 지점에 고정되어야 한다.

  그러나, 캔버스의 배경으로 사용될 요소에 대해 어떤 상자도 생성되지 않는다면, 캔버스 배경은 투명하다.(CSS 2에서는, 요소 자신 또는 조상이 'display: none'인 경우가 이에 해당한다.)

  요소가 'display: none'이 아닌 'visibility: hidden'인 경우에는 상자가 생성되며 그 배경이 캔버스에 사용된다는 점에 유의하라.

• [2015-07-01] 'position: fixed'인 요소는 항상 새로운 스태킹 컨텍스트를 설정한다. ('position: absolute'는 요소가 스태킹 컨텍스트를 설정하는지 여부를 'z-index'가 결정하는 점에서 다르다.)

  “9.9.1 Specifying the stack level: the 'z-index' property”에서 'auto'의 정의를 다음과 같이 변경:

  auto

  현재 스태킹 컨텍스트에서 생성된 상자의 스택 레벨은 0이다. 상자는 루트 요소가 아닌 한 새로운 스태킹 컨텍스트를 설정하지 않는다. 상자에 'position: fixed'가 지정되어 있거나 루트인 경우, 새로운 스태킹 컨텍스트도 설정한다.

• [2015-09-05] 잘못된 선언이 at-rule의 문법으로 시작되는 경우에는 처리 방식이 달라진다. 이 경우 파싱은 다음 세미콜론이나 둘러싼 블록의 닫는 중괄호에서 재개되는 것이 아니라, 해당 at-rule 바로 다음에서 재개된다. 이는 아래와 같이 룰셋의 코어 문법에 at-rule을 추가함으로써 표현된다.

  “4.1.1 Tokenization”에서 ruleset 생성 규칙을 다음과 같이 변경:

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

  “4.1.7 Rule sets, declaration blocks, and selectors”에서 두 번째 문단을 다음과 같이 변경:

  선언 블록은 왼쪽 중괄호({)로 시작하여 일치하는 오른쪽 중괄호(})로 끝난다. 그 사이에는 0개 이상의 세미콜론(;)으로 구분된 선언 선언과 at-rule 목록이 있어야 한다. 선언은 목록의 마지막이 아닌 한 세미콜론(;)으로 끝나야 한다.

  참고: CSS 레벨 2에는 룰셋 내부에 나타날 수 있는 at-rule이 없지만, 향후 레벨에서 그러한 at-rule이 정의될 수 있다.

  “4.2 Rules for handling parsing errors”에서 잘못된 선언 규칙을 다음과 같이 변경:

  • 잘못된 선언(Malformed declarations). 사용자 에이전트는 선언을 파싱하는 동안 예기치 않은 토큰을 만나면, (), [], {}, "", '' 쌍 맞추기 규칙을 준수하고 이스케이프를 올바르게 처리하면서 선언의 끝까지 읽어 처리해야 한다. 예를 들어, 잘못된 선언은 속성 이름, 콜론(:), 속성 값이 빠져 있을 수 있다.

    UA가 선언이나 at-rule의 시작(즉, IDENT 토큰 또는 ATKEYWORD 토큰)을 기대했는데 대신 예기치 않은 토큰을 발견한 경우, 그 토큰은 잘못된 선언의 첫 토큰으로 간주한다. 즉, 그 경우에는 잘못된 문(statement)이 아니라 잘못된 선언에 대한 규칙을 사용하여 어떤 토큰을 무시할지 결정한다.

    다음은 모두 동등하다:

    p { color:green }
    p { @foo { bar: baz } color:green }  /* 알 수 없는 at-rule */
    p { color:green; color }  /* 잘못된 선언: ':' 또는 값 누락 */
    p { color:red;   color; color:green }  /* 기대되는 복구와 동일 */
    p { color:green; color: } /* 잘못된 선언: 값 누락 */
    p { color:red;   color:; color:green } /* 기대되는 복구와 동일 */
    p { color:green; color{;color:maroon} } /* 예기치 않은 토큰 { } */
    	 p { color:red;   color{;color:maroon}; color:green } /* 복구 후 동일 */

  마지막으로, “13.2 Page boxes: the @page rule&rdquo에서, 이제 중복이 되었으므로 다음 텍스트를 제거:

  @page 내부의 잘못된 선언, 잘못된 문, 잘못된 at-rule 처리 규칙은 section 4.2에 정의된 것과 동일하되, 다음이 추가된다: UA가 선언이나 at-rule의 시작(즉, IDENT 토큰 또는 ATKEYWORD 토큰)을 기대했는데 예기치 않은 토큰을 발견한 경우, 그 토큰은 잘못된 선언의 첫 토큰으로 간주한다. 즉, 그 경우에는 잘못된 문이 아니라 잘못된 선언에 대한 규칙을 사용하여 어떤 토큰을 무시할지 결정한다.