forked from w3c/csswg-drafts
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathchanges.src
More file actions
1039 lines (799 loc) · 37.7 KB
/
changes.src
File metadata and controls
1039 lines (799 loc) · 37.7 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html lang="en">
<!-- $Id: changes.src,v 2.176 2014-01-17 13:48:59 bbos Exp $ -->
<HEAD>
<TITLE>Changes</TITLE>
<!--script src="http://www.w3c-test.org/css/harness/annotate.js#CSS21_DEV" type="text/javascript" defer></script-->
</HEAD>
<BODY>
<H1>Changes</H1>
<P><em>This appendix is informative, not normative.</em></P>
<P>Below are the changes relative to the first revision of CSS2
(CSS 2.1). The changes between the CSS2 specification (see
[[CSS2]]) and CSS 2.1 (see [[CSS21]]) can be found in the <a
href="http://www.w3.org/TR/CSS21/changes.html" >Changes section of
CSS 2.1.</a>
<p>This chapter is not a complete list of changes. Minor editorial
changes and most changes to examples are not listed here.</p>
<H2 id=since-20110607>Changes since the Recommendation of 7 June 2011</H2>
<ul>
<li id=s.6.2.1 class=change>
<p><span class=updated>[2011-10-12]</span> In <a
href="cascade.html#value-def-inherit" >“6.2.1 The 'inherit'
value,”</a> change
<blockquote>
<p>Each property may also have a cascaded value of 'inherit',
which means that, for a given element, the property takes
<del>the same specified value as the property for</del> <ins>as
specified value the computed value of</ins> the element's parent.
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2011Oct/0482.html"
>CSS WG minutes 2011-10-12.</a>)
<!-- Status: edited -->
<li id=s.6.1.1 class=clarification>
<p><span class=updated>[2011-10-12]</span> In <a
href="cascade.html#specified-value" >“6.1.1 Specified values,”</a>
add this clarification:
<blockquote>
<ol>
<li>If the cascade results in a value use it. <ins>Except that,
if the value is 'inherit', the specified value is defined in <a
href="cascade.html#value-def-inherit" >“The 'inherit' value”</a>
below</ins>
</ol>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2011Oct/0482.html"
>CSS WG minutes 2011-10-12.</a>)
<!-- Status: edited -->
<li id=s.8.3.1c class=change>
<p><span class=updated>[2012-04-04]</span> In <a
href="box.html#collapsing-margins" >“8.3.1 Collapsing
margins,”</a> add a new item as follows:
<blockquote>
<p>Adjoining vertical margins collapse, except:
<ul>
<li>Margins of the root element's box do not collapse.
<li>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.
<li><ins>If the top margin of a box with non-zero computed
'min-height' and 'auto' computed 'height' collapses with the
bottom margin of its last in-flow child, then the child's bottom
margin does not collapse with the parent's bottom margin.</ins>
</ul>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Apr/0101.html"
>CSS WG minutes 2012-04-04.</a>)
<!-- Status: edited -->
<li id=s.10.7 class=clarification>
<p><span class=updated>[2012-04-11]</span> In <a
href="visudet.html#min-max-heights" >“10.7 Minimum and maximum
heights: 'min-height' and 'max-height',”</a> clarify the note as
follows:
<blockquote>
<p><del>These steps do not affect the real computed values of the
above properties. 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).</del>
<p><ins>These steps do not affect the real computed value of
'height'. Consequently, for example, they do not affect margin
collapsing, which depends on the computed value.</ins>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Apr/0276.html"
>CSS WG minutes 2012-04-11.</a>)
<!-- Status: edited -->
<li id=s.8.3.1d class=clarification>
<p><span class=updated>[2012-04-11]</span> In <a
href="box.html#collapsing-margins" >“8.3.1 Collapsing
margins,”</a> clarify 7th bullet in the 2nd note:
<blockquote>
<p><del>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.</del>
<p><ins>The bottom margin of an in-flow block box with a 'height' of
'auto' collapses with its last in-flow block-level child's bottom
margin, if:</ins>
<ul>
<li><ins>the box has no bottom padding, and</ins>
<li><ins>the box has no bottom border, and</ins>
<li><ins>the child's bottom margin neither collapses with a top margin
that has clearance, nor (if the box's min-height is non-zero)
with the box's top margin.</ins>
</ul>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Apr/0276.html"
>CSS WG minutes 2012-04-11.</a>)
<!-- Status: edited -->
<li id=s.15.3a class=clarification>
<p><span class=updated>[2012-05-02]</span> In <a
href="fonts.html#font-family-prop" >“15.3 Font family: the 'font-family' property,”</a>
clarify that using the font name “inherit” <em>without</em> quotes is an error:
<blockquote>
<p><del>Font family <em>names</em> that happen to be the same as
a keyword value ('inherit', 'serif', 'sans-serif', 'monospace',
'fantasy', and 'cursive') must be quoted to prevent confusion
with the keywords with the same names. The keywords 'initial' and
'default' are reserved for future use and must also be quoted
when used as font names. UAs must not consider these keywords as
matching the '<family-name>' type.</del>
<p><ins>Unquoted font family <em>names</em> that happen to be the
same as the keyword values 'inherit', 'default' and 'initial' or
the generic font keywords ('serif', 'sans-serif', 'monospace',
'fantasy', and 'cursive') do not match the '<family-name>'
type. These names must be quoted to prevent confusion with the
keywords with the same names. Note that 'font-family: Times,
inherit' is therefore an invalid declaration, because 'inherit'
in that position can neither be a valid keyword nor a valid font
family name.</ins>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012May/0063.html"
>CSS WG minutes 2012-05-02.</a>)
<!-- Status: edited -->
<li id=s.4.3.1 class=change>
<p><span class=updated>[2012-05-02]</span> Spaces and comments are
not allowed between the sign and the digits of a <number>,
<length> or <percentage>. In <a
href="syndata.html#numbers" >“4.3.1 Integers and real
numbers,”</a> insert “immediately” as follows:
<blockquote>
<p>Both integers and real numbers may <ins>immediately</ins> be
preceded by a "-" or "+" to indicate the sign.
</blockquote>
<p>In <a href="syndata.html#tokenization" >“4.1.1
Tokenization,”</a> allow "+" or "-" at the start of the
{num} macro:
<blockquote>
<table>
<tr><td>num
<td><code><ins>[-+]?</ins>[0-9]+|<ins>[-+]?</ins>[0-9]*\.[0-9]+</code>
</table>
</blockquote>
<p>(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.)
<p>No change is required in 4.3.2 (<length>) or 4.3.3
(<percentage>), because they refer to 4.3.1.
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012May/0063.html"
>CSS WG minutes 2012-05-02.</a>)
<!-- Status: edited -->
<li id=s.10.1a class=change>
<p><span class=updated>[2012-08-01]</span> In <a
href="visudet.html#containing-block-details" >10.1 “Definition of
"containing block,"”</a> change:
<blockquote>
<ol>
<li> […]
<li>For other elements, if the element's position is 'relative'
or 'static', the containing block is formed by the content edge
of the nearest <ins>ancestor box that is a</ins> <a
href="visuren.html#block-boxes">block container</a>
<del>ancestor box</del> <ins>or which establishes a formatting
context</ins>.
</ol>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0087.html"
>CSS WG minutes 2012-08-01.</a>)
<!-- Status: edited -->
<li id=s.9.4 class=change>
<p><span class=updated>[2012-08-01]</span> In <a
href="visuren.html#normal-flow" >9.4 “Normal flow,”</a> replace as
follows:
<blockquote>
<p>Boxes in the normal flow belong to a <span class="index-def"
title="formatting context">formatting context</span>, which
<ins>in CSS 2</ins> may be <ins>table,</ins> block or
inline<del>, but not both simultaneously</del>. <ins>In future
levels of CSS, other types of formatting context will be
introduced.</ins> <a href="visuren.html#block-level">Block-level</a> boxes
participate in a <a href="visuren.html#block-formatting">block formatting</a>
context. <a href="visuren.html#inline-level">Inline-level boxes</a>
participate in an <a href="visuren.html#inline-formatting">inline
formatting</a> context. <ins>Table formatting contexts are
described in the <a href="tables.html" >chapter on
tables.</a></ins>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0087.html"
>CSS WG minutes 2012-08-01.</a>)
<!-- Status: edited -->
<li id=s.9.4.2 class=clarification>
<p><span class=updated>[2012-08-01]</span> In <a
href="visuren.html#inline-formatting" >9.4.2 “Inline formatting
contexts,”</a> add this sentence:
<blockquote>
<p><ins>An inline formatting context is established by a block
container box that contains no block-level boxes.</ins> In an
inline formatting context, boxes are laid out horizontally, one
after the other, beginning at the top of a containing block.
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0087.html"
>CSS WG minutes 2012-08-01.</a>)
<!-- Status: edited -->
<li id=s.17.4a class=change>
<p><span class=updated>[2012-08-01]</span> In <a
href="tables.html#model" >17.4 “Tables in the visual formatting
model,”</a> replace as follows:
<blockquote>
<p>The table wrapper box is a 'block' box if the table is
block-level, and an 'inline-block' box if the table is
inline-level. The table wrapper box establishes a block
formatting context<ins>, and the table box establishes a table
formatting context</ins>.
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0087.html"
>CSS WG minutes 2012-08-01.</a>)
<!-- Status: edited -->
<li id=s.17.5 class=change>
<p><span class=updated>[2012-08-01]</span> In <a
href="tables.html#table-layout" >17.5 “Visual layout of table
contents,”</a> replace as follows:
<blockquote>
<p>Internal table elements generate rectangular <a
href="box.html#box-dimensions">boxes</a> <del>with</del>
<ins>which participate in the table formatting context
established by the table box. These boxes have</ins> content and
borders<del>.</del> <ins>and</ins> cells have padding as
well. Internal table elements do not have margins.
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0087.html"
>CSS WG minutes 2012-08-01.</a>)
<!-- Status: edited -->
<li id=s.11.1.1a class=change>
<p><span class=updated>[2012-08-01]</span> In <a
href="visufx.html#overflow" >11.1.1 “Overflow: the 'overflow'
property,”</a> change:
<blockquote>
<p><em>Applies to:</em> block containers <ins>and boxes that
establish a formatting context</ins>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0087.html"
>CSS WG minutes 2012-08-01.</a>)
<!-- Status: edited -->
<li id=s.4.1.1a class=change>
<p><span class=updated>[2013-04-29]</span> The letters u, r and l
of the URI token may be written as escapes. In <a
href="syndata.html#tokenization" >4.1.1 “Tokenization,”</a> change
in the first table:
<blockquote>
<table>
<tr><td>URI<td><code><del>url</del><ins>{U}{R}{L}</ins>\(<var>{w}{string}{w}</var>\)<br>
|<del>url</del><ins>{U}{R}{L}</ins>\(<var>{w}</var>([!#$%&*-\[\]-~]|<var>{nonascii}</var>|<var>{escape}</var>)*<var>{w}</var>\)</code>
</table>
</blockquote>
<p>and in the second table:
<blockquote>
<table>
<tr>
<td>baduri1
<td><code><del>url</del><ins>{U}{R}{L}</ins>\(<var>{w}</var>([!#$%&*-~]|<var>{nonascii}</var>|<var>{escape}</var>)*<var>{w}</var></code>
<tr>
<td>baduri2
<td><code><del>url</del><ins>{U}{R}{L}</ins>\(<var>{w}</var><var>{string}</var><var>{w}</var></code>
<tr>
<td>baduri3
<td><code><del>url</del><ins>{U}{R}{L}</ins>\(<var>{w}</var><var>{badstring}</var></code>
</table>
</blockquote>
<p>And add to the second table:
<blockquote>
<table>
<tr>
<td><ins>L</ins>
<td><ins><code>l|\\0{0,4}(4c|6c)(\r\n|[ \t\r\n\f])?|\\l</code></ins>
<tr>
<td><ins>R</ins>
<td><ins><code>r|\\0{0,4}(52|72)(\r\n|[ \t\r\n\f])?|\\r</code></ins>
<tr>
<td><ins>U</ins>
<td><ins><code>u|\\0{0,4}(55|75)(\r\n|[ \t\r\n\f])?|\\u</code></ins>
</table>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2013Jan/0616.html"
>CSS WG minutes 2013-01-30.</a>)
<!-- Status: edited -->
<li id=s.G.2d class=clarification>
<p><span class=updated>[2013-04-29]</span> The letters u, r and l
of the URI token may be written as escapes (see the <a
href="#s.4.1.1a">previous errata</a>). In <a
href="grammar.html#scanner" >G.2 “Lexical scanner,”</a> change:
<blockquote>
<pre>
baduri1 <del>url</del><ins>{U}{R}{L}</ins>\({w}([!#$%&*-\[\]-~]|{nonascii}|{escape})*{w}
baduri2 <del>url</del><ins>{U}{R}{L}</ins>\({w}{string}{w}
baduri3 <del>url</del><ins>{U}{R}{L}</ins>\({w}{badstring}</pre>
</blockquote>
<p>and
<blockquote>
<pre>
<del>"url("</del><ins>{U}{R}{L}"("</ins>{w}{string}{w}")" {return URI;}
<del>"url("</del><ins>{U}{R}{L}"("</ins>{w}{url}{w}")" {return URI;}</pre>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2013Jan/0616.html"
>CSS WG minutes 2013-01-30.</a>)
<!-- Status: edited -->
<li id=s.4.1.1b class=change>
<p><span class=updated>[2013-04-29]</span> 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 <a href="syndata.html#tokenization" >4.1.1
“Tokenization,”</a> change:
<blockquote>
<table>
<tr><td>nonascii <td>[^\0-<del>\237</del><ins>\177</ins>]
</table>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2013Jan/0616.html"
>CSS WG minutes 2013-01-30.</a>)
<!-- Status: edited -->
<li id=s.4.1.3d class=change>
<p><span class=updated>[2013-04-29]</span> 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 <a href="syndata.html#characters" >4.1.3
“Characters and case,”</a> change:
<blockquote>
<ul>
<li>In CSS, <dfn>identifiers</dfn> (including element names,
classes, and IDs in <a href="selector.html">selectors</a>) can
contain only the characters [a-zA-Z0-9] and ISO 10646
characters <del>U+00A0</del> <ins>U+0080</ins> and higher, plus
the hyphen (-) and the underscore (_);
</ul>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2013Jan/0616.html"
>CSS WG minutes 2013-01-30.</a>)
<!-- Status: edited -->
<li id=s.4.4 class=change>
<p><span class=updated>[2013-05-02]</span> 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 <abbr
title="Byte Order Mark">BOM,</abbr> then the BOM determines which
of the UTF-based encodings is used, overriding the out-of-band
information. In <a href="syndata.html#charset">4.4 “CSS style
sheet representation,”</a> insert:
<blockquote>
<p><ins>If rule 1 above (an HTTP "charset" parameter or similar)
yields a character encoding and it is one of UTF-8, UTF-16 or
UTF-32, then a BOM, if any, at the start of the file overrides
that character encoding, as follows:</ins>
<table>
<thead>
<tr><th><ins>First bytes (hexadecimal)</ins>
<th><ins>Resulting encoding</ins>
<tbody>
<tr><td><ins>00 00 FE FF</ins> <td><ins>UTF-32, big-endian</ins>
<tr><td><ins>FF FE 00 00</ins> <td><ins>UTF-32, little-endian</ins>
<tr><td><ins>FE FF</ins> <td><ins>UTF-16, big-endian</ins>
<tr><td><ins>FF FE</ins> <td><ins>UTF-16, little-endian</ins>
<tr><td><ins>EF BB BF</ins> <td><ins>UTF-8</ins>
</table>
<p><ins>If rule 1 yields a character encoding of UTF-16BE,
UTF-16LE, UTF-32BE or UTF-32LE, then it is an error if the file
starts with a BOM. A CSS UA must recover by ignoring the
specified encoding and using the table above.</ins>
<p class=note><ins>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 <a href="refs.html#ref-UNICODE" rel="biblioentry"
class="noxref"><span class="normref">[UNICODE]</span></a>.</ins>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Oct/0727.html"
>CSS WG minutes 2012-10-24.</a>)
<!-- Status: edited -->
<li id=s.11.1.1b class=change>
<p><span class=updated>[2013-07-15]</span> In <a
href="visufx.html#overflow" >11.1.1 “Overflow: the 'overflow'
property,”</a> change the definition of 'scroll' and 'auto':
<blockquote>
<dl>
<dt><strong>scroll</strong> <dd>This value indicates that the
content is clipped and that if the user agent uses a scrolling
mechanism that is visible on the screen (such as a scroll bar
or a panner), that mechanism should be displayed for a box
whether or not any of its content is clipped. This avoids any
problem with scrollbars appearing and disappearing in a dynamic
environment. When this value is specified and the target
medium is 'print', overflowing content may be printed.
<ins>When used on <a href="tables.html#table-box">table
boxes,</a> this value has the same meaning as 'visible'.</ins>
<dt><strong>auto</strong> <dd>The behavior of the 'auto' value
is user agent-dependent, but should cause a scrolling mechanism
to be provided for overflowing boxes. <ins>When used on <a
href="tables.html#table-box">table boxes,</a> this value has
the same meaning as 'visible'.</ins>
</dl>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012Aug/0298.html"
>CSS WG minutes 2012-08-08.</a>)
<!-- Status: edited -->
<!-- Note: this revises the wording previously decided in
http://lists.w3.org/Archives/Public/www-style/2012Aug/0298.html
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=18497 for the
history of the decision -->
<li id=s.15.3b class=clarification>
<p><span class=updated>[2013-07-15]</span> In <a
href="fonts.html#font-family-prop" >15.3 Font family: the
'font-family' property</a> the grammar is missing a pair of brackets:
<blockquote>
<p>Value: [[ <family-name> | <generic-family> ] [,
<ins>[</ins> <family-name>| <generic-family> ]
<ins>]</ins>* ] | inherit
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012May/0887.html"
>CSS WG minutes 2012-05-03.</a>)
<!-- Status: edited -->
<li id=s.G.1a class=change>
<p><span class=updated>[2013-07-15]</span> Spaces and comments are
not allowed between the sign and the digits of a <number>,
<length> or <percentage>. In <a
href="grammar.html#scanner" >“G.2 Lexical
scanner,”</a> change the {num} macro as follows:
<blockquote>
<pre>num <ins>[-+]?</ins>[0-9]+|<ins>[-+]?</ins>[0-9]*"."[0-9]+</pre>
</blockquote>
<p>In <a href="grammar.html#grammar" >“G.1
Grammar,”</a> remove unary_operator from the grammar:
<blockquote>
<pre>
<del>unary_operator
: '-' | '+'
;</del></pre>
</blockquote>
<p>and
<blockquote>
<pre>
term
: <del>unary_operator?</del>
[ NUMBER S* | PERCENTAGE S* | LENGTH S* | EMS S* | EXS S* | ANGLE S* |
TIME S* | FREQ S* ]
| STRING S* | IDENT S* | URI S* | hexcolor | function
;</pre>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2012May/0063.html"
>CSS WG minutes 2012-05-02.</a>)
<!-- Status: edited -->
<li id=s.10.5a class=change>
<p><span class=updated>[2013-07-18]</span> A percentage on
'height', even if not used, can be inherited. In <a
href="visudet.html#the-height-property" >“10.5 Content
height: the 'height' property,”</a> change the
“computed value” line as follows:
<blockquote>
<table>
<tr>
<td><em>Computed value:</em>
<td>the percentage or 'auto' <del>(see prose under <a
href="syndata.html#value-def-percentage" class="noxref"><span
class="value-inst-percentage"><percentage></span></a>)</del>
<ins>(as specified)</ins>
</table>
</blockquote>
<p>and in the definition of <percentage>:
<blockquote>
<dl>
<dt><strong><percentage></strong>
<dd>Specifies a percentage height. The percentage is calculated
with respect to the height of the generated box's <a
href="visuren.html#containing-block">containing block</a>. 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, <del>the value computes to 'auto'</del>
<ins>the used height is calculated as if 'auto' was
specified</ins>.
</dl>
</blockquote>
<p>(See <a
href="http://lists.w3.org/Archives/Public/www-style/2013May/0201.html"
>CSS WG minutes 2013-05-08.</a>)
<!-- Status: edited -->
<!-- https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392 -->
<li id=s.4.1.1c class=change>
<p><span class=updated>[2013-09-09]</span> In <a
href="syndata.html#tokenization">“4.1.1
Tokenization,”</a> make the UNICODE-RANGE token more
precise:
<blockquote>
<table>
<tr>
<td>UNICODE-RANGE
<td><code><del>u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?</del><br>
<ins>u\+[?]{1,6}|<br>
u\+[0-9a-f]{1}[?]{0,5}|<br>
u\+[0-9a-f]{2}[?]{0,4}|<br>
u\+[0-9a-f]{3}[?]{0,3}|<br>
u\+[0-9a-f]{4}[?]{0,2}|<br>
u\+[0-9a-f]{5}[?]{0,1}|<br>
u\+[0-9a-f]{6}|<br>
u\+[0-9a-f]{1,6}-[0-9a-f]{1,6}</ins></code>
</table>
</blockquote>
<p>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”.
<p>(See <a
href="http://www.w3.org/mid/5227C33B.9010408@inkedblade.net" >CSS
WG minutes 2013-09-03.</a>)
<!-- Status: edited -->
<li id=s.9.2a class=clarification>
<p><span class=updated>[2012-09-19]</span> Modify <a
href="visuren.html#box-gen" >“9.2 Controlling box
generation”</a> and <a
href="visuren.html#anonymous-block-level" >“9.2.1
Block-level elements and block boxes”</a> as follows:
<blockquote>
<p><strong>Controlling box generation</strong>
<p>The following sections describe the types of boxes that may be
generated in CSS 2.1. A box's type affects, in part, its
behavior in the visual formatting model. The 'display' property,
described below, specifies a box's type.
<p><ins>Certain values of the ''display' property cause an
element of the source document to generate a <dfn>principal
box</dfn> that contains descendant boxes and generated content
and is also the box involved in any positioning scheme. Some
elements may generate additional boxes in addition to the
principal box: 'list-item' elements. These additional boxes are
placed with respect to the principal box.</ins>
<p><strong>9.2.1 Block-level elements and block boxes</strong>
<p><del><dfn>Block-level elements</dfn> 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'.</del>
<p><ins><dfn>Block-level elements</dfn> – 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'. <dfn>Block-level boxes</dfn> are boxes that participate
in a block formatting context.</ins>
<p><del><dfn>Block-level boxes</dfn> are boxes that participate
in a block formatting context. Each block-level element
generates a <dfn>principal block-level box</dfn> that contains
descendant boxes and generated content and is also the box
involved in any positioning scheme. Some block-level elements
may generate additional boxes in addition to the principal box:
'list-item' elements. These additional boxes are placed with
respect to the principal box.</del>
<p><del>Except for table boxes, which are described in a later
chapter, and replaced elements,</del> <ins>In
CSS 2,</ins> a block-level box is also a block container
box <ins>unless it is a table box or the principal box of a
replaced element</ins>. A <dfn >block container box</dfn> either
contains only block-level boxes or establishes an inline
formatting context and thus contains only inline-level
boxes. <ins>An element whose principal box is a block container
box is a <dfn >block container element.</dfn></ins> Values of
the 'display' property which make a non-replaced element
generate a block container include 'block', 'list-item' and
'inlin
12C8
e-block'. Not all block container boxes are block-level
boxes: non-replaced inline blocks and non-replaced table cells
are block containers but <ins>are</ins> not block-level
<del>boxes</del>. Block-level boxes that are also block
containers are called <dfn>block boxes</dfn>.
<p>The three terms "block-level box," "block container box," and
"block box" are sometimes abbreviated as "block" where
unambiguous.
</blockquote>
<!-- Status: edited -->
<!-- http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html -->
<li id=s.9.2.4a class=clarification>
<p><span class=updated>[2012-09-19]</span> Modify <a
href="visuren.html#display-prop" >“9.2.4 The 'display'
property”</a> as follows:
<blockquote>
<dl>
<dt><strong>block</strong>
<dd>This value causes an element to generate a
<ins>principal</ins> block box.
<dt><strong>inline-block</strong>
<dd>This value causes an element to generate <del>an</del>
<ins>a principal</ins> inline-level block container.
<ins>(</ins>The inside of an inline-block is formatted as a
block box, and the element itself is formatted as an atomic
inline-level box.<ins>)</ins>
</dl>
</blockquote>
<!-- Status: edited -->
<!-- http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html -->
<li id=s.17.4b class=clarification>
<p><span class=updated>[2012-09-19]</span> Modify <a
href="tables.html#model" >“17.4 Tables in the visual
formatting model”</a> as follows:
<blockquote>
<p>In both cases, the table generates a principal block
<ins>container</ins> box called the <dfn>table wrapper box</dfn>
that contains the table box itself and any caption boxes (in
document order). The <dfn>table box</dfn> is a block-level box
that contains the table's internal table boxes. The caption
boxes are <ins>principal</ins> 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. Whether the caption boxes are placed before or after the
table box is decided by the 'caption-side' property, as
described below.
<p>The table wrapper box is <del>a 'block' box if the table is
block-level</del> <ins>block-level for 'display: table'</ins>,
and <del>an 'inline-block' box if the table is
inline-level</del> <ins>inline-level for 'display:
inline-table'</ins>. The table wrapper box establishes a block
formatting context, and the table box establishes a table
formatting context. The table box (not the table wrapper box) is
used when doing baseline vertical alignment for an
'inline-table'. The width of the table wrapper box is the
border-edge width of the table box inside it, as described by
section 17.5.2. Percentages on 'width' and 'height' on the table
are relative to the table wrapper box's containing block, not
the table wrapper box itself.
</blockquote>
<!-- Status: edited -->
<!-- http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html -->
<li id=s.4.1.1d class=change>
<p><span class=updated>[2012-09-19]</span> For compatibility with
SVG, modify the definition of macro num in <a
href="syndata.html#tokenization" >“4.1.1
Tokenization”</a> as follows:
<blockquote>
<table>
<tr>
<td><del>num</del>
<td><del><code>[-+]?[0-9]+|[-+]?[0-9]*\.[0-9]+</code></del>
<tr>
<td><ins>num</ins>
<td><ins><code>[+-]?([0-9]+|[0-9]*\.[0-9]+)(e[+-]?[0-9]+)?</code></ins>
</table>
</blockquote>
<!-- Status: edited -->
<!-- As decided on 2012-08-15 -->
<li id=s.14.2 class=change>
<p><span class=updated>[2014-07-16]</span> 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
<a href="colors.html#background" >“14.2 The
background”</a> as follows:
<blockquote>
<p>[…] Such backgrounds must also be anchored at the same point
as they would be if they were painted only for the root element.
<p><ins>However, if no boxes are generated for the element whose
background would be used for the background of the canvas, then
the canvas background is transparent. (in CSS 2, that is the
case when the element or an ancestor has 'display: none'.)</ins>
<p><ins>Note that, if the element has 'visibility: hidden' but
not 'display: none', boxes <em>are</em> generated for it and its
background <em>is</em> used for the canvas.</ins>
</blockquote>
<!-- Status: edited, but the WG still needs to validate the text -->
<!-- http://lists.w3.org/Archives/Public/www-style/2014Jul/0162.html -->
<li id=s.9.9.1 class=change>
<p><span class=updated>[2015-07-01]</span> An element with
'position: fixed'
<em>always</em> establishes a new stacking context. (This is
different from 'position: absolute', where 'z-index' determines if
the element establishes a stacking context or not.)
<p>Change the definition of 'auto' in <a
href="visuren.html#z-index" >“9.9.1 Specifying the stack
level: the 'z-index' property”</a> as follows:
<blockquote>
<dl>
<dt><strong>auto</strong> <dd>The stack level of the generated
box in the current stacking context is 0. <del>The box does not
establish a new stacking context unless it is the root
element.</del> <ins>If the box has 'position: fixed' or if it
is the root, it also establishes a new stacking context.</ins>
</dl>
</blockquote>
<!-- Status: edited, but WG still needs to validate the text -->
<!-- https://lists.w3.org/Archives/Public/www-style/2015Jul/0032.html -->
<li id=s.4.1.1e class=change>
<p><span class=updated>[2015-09-05]</span> 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.
<p>In <a href="syndata.html#tokenization" >“4.1.1
Tokenization”,</a> change the production for ruleset as
follows:
<blockquote>
<pre>
<del>ruleset : selector? '{' S* declaration? [ ';' S* declaration? ]* '}' S*;</del>
<ins>ruleset : selector? '{' S* declaration-list '}' S*;
declaration-list: declaration [ ';' S* declaration-list ]?
| at-rule declaration-list
| /* empty */;</ins></pre>
</blockquote>
<p>In <a href="syndata.html#rule-sets" >“4.1.7 Rule sets,
declaration blocks, and selectors”,</a> change the second
paragraph as follows:
<blockquote>
<p>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 <del>semicolon-separated (;)
declarations</del> <ins>declarations and at-rules. Declarations
must end with a semicolon (;) unless they are last in the
list.</ins>
<p class=note><ins>Note: CSS level 2 has no at-rules that
may appear inside rule sets, but such at-rules may be defined in
future levels.</ins>
</blockquote>
<p>In <a href="syndata.html#parsing-errors" >“4.2 Rules for
handling parsing errors”,</a> change the rule for malformed
declarations as follows:
<blockquote>
<ul>
<li>
<p><strong>Malformed declarations.</strong> User agents must
handle unexpected tokens encountered while parsing a
declaration by reading until the end of the declaration, while
observing the rules for matching pairs of (), [], {}, "", and
'', and correctly handling escapes. For example, a malformed
declaration may be missing a property name, colon (:), or
property value.
<p><ins>When the UA expects the start of a declaration or
at-rule (i.e., an IDENT token or an ATKEYWORD token) but finds
an unexpected token instead, that token is considered to be
the first token of a malformed declaration. I.e., the rule for
malformed declarations, rather than malformed statements is
used to determine which tokens to ignore in that case.</ins>
<p>The following are all equivalent: