csswg-drafts/css2/changes.src at 56a62199b755b5250e8add241a7524c56a52b070 · w3c/csswg-drafts · GitHub

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&nbsp;2.1 [[CSS21]]).
The changes between the original CSS2 specification (see
[[CSS2]]) and CSS&nbsp;2.1 can be found in the <a
href="http://www.w3.org/TR/CSS21/changes.html" >Changes section of
CSS&nbsp;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. Also not
listed here are additions of notes that point to relevant sections in
other modules.

<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" >&ldquo;6.2.1 The 'inherit'
    value,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/cascade/inherit-computed-001.html"
     >inherit-computed-001</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/cascade/inherit-computed-002.html"
    >inherit-computed-002</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" >&ldquo;6.1.1 Specified values,&rdquo;</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" >&ldquo;The 'inherit' value&rdquo;</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" >&ldquo;8.3.1 Collapsing
    margins,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/margin-padding-clear/margin-collapse-min-height-002.xht" >margin-collapse-min-height-002</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/margin-padding-clear/margin-collapse-min-height-001.xht" >margin-collapse-min-height-001</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" >&ldquo;10.7 Minimum and maximum
    heights: 'min-height' and 'max-height',&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visudet/height-computed-002.xht" >height-computed-002</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visudet/height-computed-001.xht" >height-computed-001</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" >&ldquo;8.3.1 Collapsing
    margins,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/margin-padding-clear/margin-collapse-min-height-002.xht" >margin-collapse-min-height-002</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/margin-padding-clear/margin-collapse-min-height-001.xht" >margin-collapse-min-height-001</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" >&ldquo;15.3 Font family: the 'font-family' property,&rdquo;</a>
    clarify that using the font name &ldquo;inherit&rdquo; <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 '&lt;family-name&gt;' 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 '&lt;family-name&gt;'
     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 &lt;number&gt;,
    &lt;length&gt; or &lt;percentage&gt;. In <a
    href="syndata.html#numbers" >&ldquo;4.3.1 Integers and real
    numbers,&rdquo;</a> insert &ldquo;immediately&rdquo; 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" >&ldquo;4.1.1
    Tokenization,&rdquo;</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 (&lt;length&gt;) or 4.3.3
    (&lt;percentage&gt;), 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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/syntax/signed-numbers-002.xht" >signed-numbers-002</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/syntax/signed-numbers-001.xht" >signed-numbers-001</a>

    <!-- Status: edited -->


   <li id=s.10.1
75EA
a class=change>
    <p><span class=updated>[2012-08-01]</span> In <a
    href="visudet.html#containing-block-details" >10.1 &ldquo;Definition of
    "containing block,"&rdquo;</a> change:

    <blockquote>
     <ol>
      <li> [&hellip;]

      <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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/positioning/abspos-containing-block-005.xht" >abspos-containing-block-005</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/positioning/abspos-containing-block-006.xht" >abspos-containing-block-006</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/positioning/abspos-containing-block-003.xht" >abspos-containing-block-003</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/positioning/abspos-containing-block-004.xht" >abspos-containing-block-004</a>,
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/positioning/abspos-containing-block-002.xht" >abspos-containing-block-002</a>
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/positioning/abspos-containing-block-001.xht" >abspos-containing-block-001</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 &ldquo;Normal flow,&rdquo;</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&nbsp;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="#block-level">Block-level</a> boxes
     participate in a <a href="#block-formatting">block formatting</a>
     context. <a href="#inline-level">Inline-level boxes</a>
     participate in an <a href="#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 &ldquo;Inline formatting
    contexts,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visuren/inline-formatting-context-001.xht" >inline-formatting-context-001</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 &ldquo;Tables in the visual formatting
    model,&rdquo;</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 &ldquo;Visual layout of table
    contents,&rdquo;</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 &ldquo;Overflow: the 'overflow'
    property,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visufx/overflow-applies-to-001.xht" >overflow-applies-to-001</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 &ldquo;Tokenization,&rdquo;</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>([!#$%&amp;*-\[\]-~]|<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>([!#$%&amp;*-~]|<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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/syntax/escaped-url-001.xht" >syntax/escaped-url-001</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.1">previous errata</a>). In <a
    href="grammar.html#scanner" >G.2 &ldquo;Lexical scanner,&rdquo;</a> change:

    <blockquote>
     <pre>
baduri1         <del>url</del><ins>{U}{R}{L}</ins>\({w}([!#$%&amp;*-\[\]-~]|{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
    &ldquo;Tokenization,&rdquo;</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>
    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
    &ldquo;Characters and case,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/syntax/characters-0080-009F-001.xht" >characters-0080-009F-001</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 &ldquo;CSS style
    sheet representation,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/syntax/character-encoding-041.xht" >character-encoding-041</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 &ldquo;Overflow: the 'overflow'
    property,&rdquo;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visufx/overflow-applies-to-001.xht"
	>overflow-applies-to-001</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: [[ &lt;family-name> | &lt;generic-family> ] [,
     <ins>[</ins> &lt;family-name>| &lt;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 &lt;number&gt;,
    &lt;length&gt; or &lt;percentage&gt;. In <a
    href="grammar.html#scanner" >&ldquo;G.2 Lexical
    scanner,&rdquo;</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" >&ldquo;G.1
    Grammar,&rdquo;</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" >&ldquo;10.5 Content
    height: the 'height' property,&rdquo;</a> change the
    &ldquo;computed value&rdquo; line as follows:

    <blockquote>
     <table>
       <tr>
	<td><em>Computed&nbsp;value:</em>&nbsp;&nbsp;

	<td>the percentage or 'auto' <del>(see prose under <a
	href="syndata.html#value-def-percentage" class="noxref"><span
	class="value-inst-percentage">&lt;percentage&gt;</span></a>)</del>
	<ins>(as specified)</ins>
     </table>
    </blockquote>

    <p>and in the definition of &lt;percentage&gt;:

    <blockquote>
     <dl>
      <dt><strong>&lt;percentage&gt;</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>)

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visudet/height-percentage-004.xht" >height-percentage-004</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">&ldquo;4.1.1
    Tokenization,&rdquo;</a> make the UNICODE-RANGE token more
    precise:

    <blockquote>
     <table>
       <tr>
	<td>
1540
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., &ldquo;U+A?5&rdquo; previously was a single UNICODE-RANGE
    token (although a semantically meaningless one), now this is two
    tokens: &ldquo;U+A?&rdquo; (meaning the 16-character range
    U+A0-AF) and the number &ldquo;5&rdquo;.

    <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" >&ldquo;9.2 Controlling box
    generation&rdquo;</a> and <a
    href="visuren.html#anonymous-block-level" >&ldquo;9.2.1
    Block-level elements and block boxes&rdquo;</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&nbsp;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> &ndash; those elements of
      the source document that are formatted visually as blocks (e.g.,
      paragraphs) &ndash; 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&nbsp;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
      'inline-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" >&ldquo;9.2.4 The 'display'
    property&rdquo;</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" >&ldquo;17.4 Tables in the visual
    formatting model&rdquo;</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" >&ldquo;4.1.1
    Tokenization&rdquo;</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>

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/syntax/scientific-notation-001.xht" >scientific-notation-001</a>

    <!-- 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 transparent. In the case of
    (X)HTML documents, if the root element has 'background:
    transparent' and the &lt;body&gt; element has 'display: none', the
    background of the canvas is likewise transparent. Change the text in
    <a href="colors.html#background" >&ldquo;14.2 The
    background&rdquo;</a> as follows:

    <blockquote>
     <p>[&hellip;] 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&nbsp;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" >&ldquo;9.9.1 Specifying the stack
    level: the 'z-index' property&rdquo;</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>

    <p class=tests>Relevant tests:
     <a href="https://github.com/w3c/web-platform-tests/tree/master/css/CSS2/visuren/fixed-pos-stacking-001.xht" >fixed-pos-stacking-001</a>

    <!-- 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.