-
Notifications
You must be signed in to change notification settings - Fork 790
Expand file tree
/
Copy pathissues-1
More file actions
4750 lines (4224 loc) · 213 KB
/
issues-1
File metadata and controls
4750 lines (4224 loc) · 213 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
CSS2.1 Last Call: Disposition of Comments
=======================================================================
This issues list covers issues in the Last Call Working Draft
http://www.w3.org/TR/2003/WD-CSS21-20030915/
==> There are open issues. Search for *WG*.
Search for lines starting with one of the following to find issues
that need work:
*Bert* -- Task for Bert to do (3 remaining)
*Ian* -- Task for Ian to do (1 remaining)
"Further communication is required" means we have yet to send an
e-mail reply. "Document to be updated" means we still need to make
changes to the spec based on decisions the group has made. "NOTE:" is
a note by Ian based on what was noticed during issue checking.
When discussing issues, please refer to them by issue number. The
numbers used here are the numbers we will use in the final disposition
of comments (assuming I'm the one who writes that, which would seem
sensible).
When replying to or following up on e-mails mentioned below, please cc
either www-style or w3c-css-wg, and include [CSS21] in the subject
line and the issue number somewhere clearly labelled either in the
subject line or the body. This will significantly aid my ability to
keep track of what issues have been dealt with and which still require
a formal reply from the working group.
========================================================================
Issue 1. "For 'top' and 'bottom', if the height of the containing
block is not specified explicitly (i.e., it depends on content
height), the percentage value is interpreted like 'auto'." in the
definition of <percentage> for top/right/bottom/left is probably
wrong.
Resolution: MacIE, WinIE, Safari, and Mozilla do this proposal. so,
strike the sentence: "For 'top' and 'bottom', if the height of the
containing block is not specified explicitly (i.e., it depends on
content height), the percentage value is interpreted like 'auto'." in
section 9.3.2 near the end under <percentage>.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 2. "If the height of the containing block is not specified
explicitly (i.e., it depends on content height), and this element is
not absolutely positioned, the value is interpreted like 'auto'." in
the definition of <percentage> for height is probably wrong.
Resolution: Issue retracted.
Issue closed.
------------------------------------------------------------------------
Issue 3. [retracted]
Issue closed.
------------------------------------------------------------------------
Issue 4. example at the end of 5.8.1 misspells Laurence Olivier's name
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 5. http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
"In addition, we would like to extend special thanks to fantasai, Ada
Chan, and Boris Zbarsky, who have both contributed significant time to
CSS2.1." should not say "both" in the acknowledgements section.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 6. http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0371.html
(e-mail from Tantek, see note near bottom)
Resolution: Change the titles as follows:
10.6.3 Block-level, non-replaced elements in normal flow when
'overflow' computes to 'visible'
10.6.6 Block-level, non-replaced elements in normal flow when
'overflow' does not compute to 'visible'; 'inline-block',
non-replaced elements; and floating, non-replaced elements.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 7. http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0372.html
[margin collapsing / clear issue]
Resolution: Add this text after the "An element's own margins"
paragraph in 8.3.1:
"When an element's own margins collapse, and that element has had
clearance applied to it, its top margin collapses with the adjoining
margins of subsequent siblings but that resulting margin does not
collapse with the bottom margin of the parent block".
Testcase: http://weblogs.mozillazine.org/hyatt/images/016.html
Safari and MacIE do this as proposed.
WinIE behaviour is inexplicable.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 8. "'float', 'height' (if 'float' is not 'none'), 'width' (if
'float' is not 'none')" are missing from the list of properties that
apply to ':first-letter
Resolution: 'float' should apply, but not 'width' and 'height'.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 9. http://www.w3.org/mid/3F87E607.9030501@escape.com
background-position: The following should be dropped: "The computed
value of background-position for the purpose of inheritance is
undefined, since the allowed values on this property may have
different effects in a child element due to differences in size and
position of their respective boxes." (it's defined now)
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47516.180523.899733@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 10. background-position should apply to inline elements,
although it's exact behaviour should not be defined in 2.1. (as it
says under background-repeat)
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 11. Section 6.1.2. "by the 'Applies To' [add reference] line" -- we
should add the reference.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 12. Acknowledgements: the names "Lars Knoll" and "Peter Sheerin"
are repeated twice.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 13. 9.2.4 The 'display' property: "table, inline-table,
table-row-group, table-column, table-column-group, table-header-group,
table-footer-group, table-row, table-cell, and table-caption": only
table-column is a link.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 14. What is the computed value of:
font-size: x-large; -- is it 'x-large' or a platform-native length value?
font-size: larger; -- is it 'xx-large' or a platform-native length value?
border: thin solid; -- is it 'thin solid' or is it '1px solid'?
Resolution: Issue retracted.
Issue closed.
------------------------------------------------------------------------
Issue 15a. Text of CR exit criteria.
http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0411.html
http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0412.html
[...]
http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0101.html (proposal)
Resolution: Agreed.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 15b. http://lists.w3.org/Archives/Public/www-style/2003Sep/0106.html
Text of CR exit criteria.
[for the last one, propose we say "If we make such changes, we will go
back to last call for a quick review period, then skip CR (since we
will be able to show interoperability straight away)" - ian]
This is due to section 7.4.3 of the process document:
<dbaron> http://www.w3.org/2003/06/Process-20030618/tr.html#cfi
<dbaron> "In the Call for Implementations, the Working Group MAY
identify specific features of the technical report as being "features
at risk." General statements such as "We plan to remove any
unimplemented feature" are not acceptable; the Working Group MUST
precisely identify any features at risk. Thus, in response to a Call
for Implementations, reviewers can indicate whether they would
formally object to the removal of the identified features."
Resolution: Change part 4 of the CREC to read:
4. Features that were not in CSS1 will be dropped (thus reducing the
list of "all" features mentioned above) if two or more
interoperable implementations of those features are not found by
the end of the CR period.
Reply: http://www.w3.org/mid/16423.47436.256257.359604@lanalana.inria.fr
Response: http://www.w3.org/mid/403fab30.584920010@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402101410250.25633@dhalsim.dreamhost.com
Document updated.
Response: http://www.w3.org/mid/40421333.611546407@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC5641E9.3673B%25tantek@cs.stanford.edu
Reply: http://www.w3.org/mid/BC5645EC.3673F%25tantek@cs.stanford.edu
Response: http://www.w3.org/mid/40540e79.349908081@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC565859.36759%25tantek@cs.stanford.edu
Response: http://www.w3.org/mid/405619dc.352823283@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC5677AD.367B5%25tantek@cs.stanford.edu
Response: http://www.w3.org/mid/405b38e7.360770710@smtp.bjoern.hoehrmann.de
Reply: http://www.w3.org/mid/BC5690FE.367D8%25tantek@cs.stanford.edu
Response: http://lists.w3.org/Archives/Public/www-style/2004Feb/0315.html
The working group can no longer work out what the issue is.
Issue remained open.
------------------------------------------------------------------------
Issue 16. http://lists.w3.org/Archives/Member/w3c-css-wg/2003JulSep/0416.html
[overflow:hidden and .scrollTop]
Resolution:
| <Bert> ACTION Tantek: make change proposed by David Baron
| <Bert> "users have no access to hidden content" <-- strike sentence
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 17. Two instances of "color properties" in the selector chapter should
be "color property" as there is only one.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 18a. 'fixed' in section 10.1 (visudet/containing block) is defined as:
# If the element has 'position: fixed', the containing block is
# established by the viewport.
...but in section 9.3.1 (visuren/position) is defined as:
# In the case of the print media type, the box is fixed with respect
# to the page, even if that page is seen through a viewport (in the
# case of a print-preview, for example).
...(without saying that it occurs on every page) and in section 9.6.1
(visuren/fixed positioning) as:
# For paged media, boxes with fixed positions are repeated on every
# page.
These three definitions need to be made consistent.
Resolution: Change 10.1 item 3 to read: "If the element has 'position:
fixed', the containing block is established by the viewport <ins>in
the case of continuous media or the page box in the case of paged
media.</ins>".
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 18b. Also, it needs to be clear whether position:fixed elements
appear on "earlier" pages or not too. (I (ian) think they should. It's
the only logical way of looking at it IMHO. Especially given what we
said about position: absolute.)
Resolution: Retracted.
Issue closed.
------------------------------------------------------------------------
Issue 19. We have no way of positioning something relative to the page
and only render it on one page. Is that a problem? Should we
explicitly say we don't support that?
Resolution: Move to CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 20. If you can relatively position table cells / columns /
column groups / rows / row groups (or give them 'opacity', it doesn't
matter -- anything that either moves them, or makes them generate a
stacking context), then, er, good lord. Can we disallow that? If we
don't, we need to define the stacking context algorithm for that.
Resolution: Add "The effect of a 'position: relative' declaration on
table-row-group, table-header-group, table-footer-group, table-row,
table-column-group, table-column, table-cell, and table-caption
elements is undefined." to 9.3.1 Choosing a positioning scheme:
'position' property.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 21. The diagram at the bottom of 9.5 (before 9.5.1) is wrong now.
Resolution: Assumed agreement.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 22. I think we should explicitly say in the paragraph in 9.5.1
reading "If the element's top border edge has not passed the relevant
floats, then its clearance is set to the amount necessary to place the
border edge of the block even with the bottom outer edge of the lowest
float that must be cleared." that "The collapsing of earlier margins
is affected by this, and indeed the float could move as a result."
See, e.g., http://www.damowmow.com/playground/bugs/204831/001.html
vs. http://www.damowmow.com/playground/bugs/204831/002.html
The float in the first should be lower than in the second.
Note: The proposed text needs a tweak actually. We need to say
that it is the final position of the float that decides where
everything should go. IMHO. - ian
Resolution: Don't change it at all.
Issue closed.
------------------------------------------------------------------------
Issue 23. http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
| Section 1.4.2, "Applies To" paragraph
| This should probably say "elements with display:table" instead of "table
| elements" (since the latter typically means "elements with a tag name of
| 'table'").
Resolution: We don't think it's ambiguous because single quotes mean
CSS keywords by convention. No change.
Reply: http://www.w3.org/mid/16423.47511.546847.222294@lanalana.inria.fr
Alternate resolution suggested by howcome:
http://www.w3.org/mid/200311060755.hA67tTG21906@mail.opera.no
Issue closed.
------------------------------------------------------------------------
Issue 24. http://lists.w3.org/Archives/Public/www-style/2003Sep/0134.html
| Section 1.4.5
| "after" may be better than "to the right". For example, in aural rendering,
| this would be the case....
| I can't check how this actually renders in various UAs because a quick look at
| the section of the specification with the most images (Chapter 9) doesn't show
| any images provided with a long description link as described... (and none have
| a "longdesc" attribute).
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47509.532308.973825@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 25 -- 32. Duplicates of issues 38 -- 45.
------------------------------------------------------------------------
Issue 33. http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#q15
| The new first paragraph in block formatting context is good and makes
| me think i understand the questions i had on floats earlier. However,
| i think an example or two would be helpful to more clearly show for
| instance how an element that generates a new block formatting context
| affects its containing blocks size when the containing block also
| generates a new block formatting context (is this described somewhere
| else? I failed to find it if so). I also think some kind of more
| explicit pointer to this effect should be supplied in the calculating
| widths/heights sections (or is the effect seen more as an implicit
| min-width/min-height?).
Resolution: We don't think an example would necessarily be useful.
This would be more useful in a tutorial than a spec.
Reply: http://www.w3.org/mid/16423.47507.261788.447475@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 34. http://lists.w3.org/Archives/Public/www-style/2003Sep/0096.html
| Something i dont understand is why non-initial overflow needs to
| generate a new block formatting context?
Resolution: Floats don't make sense across scrolling boundaries.
Reply: http://www.w3.org/mid/16423.47504.714489.749441@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 35. http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
| The new paragraph on how the margin box of a block that generates a
| new block formatting context interacts with floats in the same block
| context is helpful, but i think perhaps the effect of a float nested
| inside an element wich generates a new block formatting context along
| with more examples would help even further (eg a float in a table
| cell). The way things in the draft are currently written the example
| under the paragraph probably belongs to the previous paragraph, which
| could be a bit confusing.
Resolution: See the upcoming test suite for some examples.
Reply: http://www.w3.org/mid/16423.47497.565605.768575@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 36. http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
| The paragraph is a little vague on how to handle the conflict between
| a float and another block that generates a new block formatting
| context when they are in the same block formatting context. Why not
| require that the box is cleared? When is it desirable to position it
| adjacent, creating a kind of a "pseudo-float"?
Resolution: Because thats what UAs interoperably do, and the adjacent
position is desirable if there is enough room.
Reply: http://www.w3.org/mid/16423.47500.745841.146514@lanalana.inria.fr
Response: http://www.w3.org/mid/40293751.19528.946EC7@localhost
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402161501270.2210@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 37. http://www.w3.org/mid/3F684CB4.21220.7532AF@localhost
| http://www.w3.org/TR/2003/WD-CSS21-20030915/visuren.html#floats
| As an editorial comment i noticed that the phrase "block formatting
| context" was only occationally linked to its defintion, in case this
| is not intentional.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47519.552017.332738@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 38. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.1.1
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
| Is it intended that '_' be a valid "ident" production? At the moment it is. So is
| '-_', for that matter. Perhaps the "ident" production should be defined as:
| ident [-_]?{nmstart}{nmchar}
| and the "nmstart" definition retained as it was in CSS2
| ([a-zA-Z]|{nonascii}|{escape}) ? No strong feelings either way here, it's just
| that the current proposal seems a bit odd.
Resolution: It's odd but it works and we're happy with it, so, let's keep it.
Reply: http://www.w3.org/mid/16423.47495.436082.810858@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 39. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.1.1
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
| Definition of the "unicode" production does not match Appendix G.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47497.565605.768575@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 40. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.1.1
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#tokenization>
| Is there a reason that CDO and CDC are allowed at all places in the stylesheet
| between rules? This seems to complicate parsing unnecessarily. Is it desired
| that CDO/CDC be allowed in linked stylesheets? They would seem very out of
| place there.... Perhaps I am misunderstanding what this is actually saying; if
| so, perhaps an informative note is in order to clarify the situation?
Resolution: It's odd but it works and we're happy with it, so, let's keep it.
Reply: http://www.w3.org/mid/16423.47479.358400.437258@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D6C6.5000504@mit.edu
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402092217060.9897@dhalsim.dreamhost.com
Response: http://www.w3.org/mid/402811FA.8010105@mit.edu
Issue closed.
------------------------------------------------------------------------
Issue 41. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.3.4
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
| The text:
| Parentheses, commas, whitespace characters, single quotes (') and
| double quotes (") appearing in a URI must be escaped with a
| backslash: '\(', '\)', '\,'.
| is misleading, since they in fact do not have to be escaped if the URI string
| is in quotes. Also, it is not immediately clear to me why commas are included
| in the list. Is there a reason.
Resolution: Add "unquoted" before "URI" in that quoted text. Commas
are escaped for future expansion.
Document updated.
Reply: http://www.w3.org/mid/16423.47493.492358.743155@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 42. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.3.4
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#uri>
| What happens if the URI string is not a syntactically valid URI? For example:
| url(http:/www.example.com/)
| or something along those lines? Does this affect the parsing or style
| computation phase, or is this handled only when the resource actually needs to
| be loaded, thus falling under the "User agents may vary" clause at the end of
| the section?
(Original resolution: Computed <uri>s are the given specified URI,
except if it is a relative URI in which case the computed URI is the
absolute URI. Add to the end of the second paragraph of 6.1.2, "The
computed value for a valid relative URI is its absolute equivalent;
for other URIs, the computed value is as specified.". Invalid URIs are
not CSS syntax errors. We will also add "invalid URIs or" between
"handle" and "URIs" in the "user agents may vary" clause in 4.3.4.)
Resolution: Add "invalid URIs or" between "handle" and "URIs" in the
"user agents may vary" clause in 4.3.4.
Resolution changed due to issue resolution conflict. See:
http://www.w3.org/mid/Pine.LNX.4.58.0401221524260.3387@dhalsim.dreamhost.com
Document updated.
Reply: http://www.w3.org/mid/16423.47491.180111.711062@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 43. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.3.7
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#strings>
| The language
| Double quotes cannot occur inside double quotes, unless escaped (as '\"' or
| as '\22').
| is somewhat misleading, since there are other ways that a quote could be
| escaped (eg using \000022). Perhaps an "e.g.," at the beginning of the
| parenthetical remark is in order? Same for single quotes.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47488.226429.681347@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 44. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.4
| < http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23>
| What about stylesheets that have a BOM but no @charset rule? Should the
| presence of a BOM imply that the sheet is encoded as, eg UTF-8 or UTF-16LE (if
| the appropriate BOM is present), as it does for XML?
Original resolution: We should allow UAs to either ignore BOMs, or
handle BOMs in the absence of other encoding information.
Resolution: Accept the proposed changes but make sure the six (title,
two in 4.4, three in 4.4.1) occurances of "document" that mean "style
sheet" are changed to say "style sheet&quo
8096
t;. Also replace "("big-endian"
or "little-endian")" with "(e.g. "big-endian" or "little-endian")".
Document updated.
Reply: http://www.w3.org/mid/16423.47486.259702.273080@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D14A.6090707@mit.edu
Resolution: Deal as part of issue 45.
Issue closed.
------------------------------------------------------------------------
Issue 45. http://www.w3.org/mid/200309281922.h8SJMG9O014121@nerd-xing.mit.edu
| Section 4.4
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q23>
| Another point is that it's trivial to have a stylesheet for which steps 1, 2, 3
| will give no useful charset value. In fact, the vast majority of stylesheets
| currently on the web fall into this category. Is the behavior UA-dependent in
| that case? If so, this should be explicitly stated, I think. Personally, I
| think it would be worthwhile to specify behavior in that eventuality.
Resolution: It's UA dependent.
Document updated.
Reply: http://www.w3.org/mid/16423.47481.705244.729423@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D1AD.6050502@mit.edu
("please just specify it don't make it UA defined")
Resolution: change those four points to be (using the current text for
the first two rules):
1. HTTP Content-Type,
2. @charset,
3. BOM,
4. <link charset=""> or other metadata from the linking mechanism (if any),
5. charset of referring document (if any),
6. UA-defined.
Reply: http://www.w3.org/mid/16427.61280.674857.670826@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 46. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.5 (Descendant Selectors)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#descendant-selectors>
| This says, in the example:
| "the whitespace is the descendant selector indicating..."
| The whitespace is a combinator which makes the whole selector a descendant
| selector, no? Which is not what that's saying...
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47484.197984.890496@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 47. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.10 (Pseudo-elements and pseudo-classes)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#pseudo-elements>
| Why are "Conforming HTML UAs" exempted from :first-line and :first-letter?
| There seems to be no good reason for this.
Resolution: Remove the exemption.
Document updated.
Reply: http://www.w3.org/mid/16423.47476.811572.917445@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 48. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.11.1 (:first-child pseudo-class)
| <http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#first-child>
| This needs to define what a "first child" is. From what I can tell, the intent
| is to match elements that would match both the "* > *" and "* + *" selectors.
| In particular, the <span> in both examples below would match :first-child:
| <p>This is a <span>test.</span></p>
| <p><!-- Of the emergency --> broadcast system</p>
| Perhaps something like, "The :first-child pseudo-class matches an element node
| that is the first element node in the child node list of some other element
| node"?
Addendum: http://www.w3.org/mid/200309282215.h8SMFaHS029555@nerd-xing.mit.edu
| I meant:
| Match the "* > *" selector but not the "* + *" selector
| of course.
Resolution: Add "element" after "first child" in 5.11.1
Document updated.
Reply: http://www.w3.org/mid/16423.47474.310916.815551@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 49. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.11.3 (The dynamic pseudo-classes: :hover, :active, and :focus)
| <http://www.w3.org/Style/css2-updates/WD-CSS21-20030915-diff/selector.html#dynamic-pseudo-classes>
| If an element is hovered, are its ancestors considered hovered? Is this
| UA-dependent, or should it be specified?
| The example used is somewhat unfortunate because it encourages using selectors
| like "a:hover" which don't do quite what page authors expect based on this
| example (in particular, "a:hover" applies to named anchors, while ":link" and
| ":visited") do not. I'm not sure how one could replace this example while
| still illustrating the order-dependence, though....
Daniel says: Similarly, how about columns.
Resolution: Leaving this undefined for CSS21:
+ say that whether :hover and :active apply to ancestors is undefined
+ add to note at end of 5.11.3 about :active in CSS1 only applying to links.
Reply: http://www.w3.org/mid/16423.47472.101982.551480@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 50. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.12.2 (The :first-letter pseudo-element)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/selector.html#first-letter>
| 'float' is not listed as a propety that applies to :first-letter
| pseudo-elements. An editing error?
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47469.609757.962247@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 51. http://www.w3.org/mid/200309282052.h8SKqWwA020953@nerd-xing.mit.edu
| Section 5.12.2 (The :first-letter pseudo-element)
| The last paragraph of the example with the floated 'T' says:
| Note that the :first-letter pseudo-element tags abut the content (i.e., the
| initial character), while the :first-line pseudo-element start tag is
| inserted right after the start tag of the element to which it is attached.
| I'm not sure what this means, in light of the example for :first-line, in which
| we get the fictional tag sequence: <div><p><div:first-line><p:first-line> ...
| This section should also make it clear that given markup like:
| <div>
| <p>
| Some text
| more text
| </p>
| </div>
| with
318
the linebreak occurring where I show it, the fictional tag sequence is:
| <div><p>
| <div:first-line><p:first-line>
| <div:first-letter><p:first-letter>S</p:first-letter></div:first-letter>omeText
| </div:first-line></p:first-line>
| more text
| </p></div>
| because right now, it only makes clear the interaction of first-letter and
| first-line when both are set on the same element, and does not specify the
| ordering of p:first-line and div:first-letter in the above example.
Resolution: No issue?
Reply: http://www.w3.org/mid/16423.47467.145644.35114@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D4A5.5020303@mit.edu
Resolution: Yes, we will define that with that example.
Reply: http://www.w3.org/mid/16434.31687.655120.182477@lanalana.inria.fr
Response: http://www.w3.org/mid/200402172058.i1HKwk6J018767@no-knife.mit.edu
Reply: http://www.w3.org/mid/16442.20892.588427.737747@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 52. http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
| Section 6.4.3 (Calculating a selector's specificity)
| The spec says:
| li:first-line {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,2 */
| It should say d=2 here.
Resolution: Assumed agreement.
Document updated.
Reply: http://www.w3.org/mid/16423.47464.897110.526868@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 53. http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
| Section 6.4.4 (Precedence of non-CSS presentational hints)
| Why is "dir" not considered a presentational hint?
Resolution: because it is not. ("why are you asking us?")
Reply: http://www.w3.org/mid/16423.47460.927696.499175@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 54. http://www.w3.org/mid/200309282304.h8SN40r2004872@nerd-xing.mit.edu
| Section 6.4.4 (Precedence of non-CSS presentational hints)
| "type" is not presentational in some cases, but presentational in others (on
| <ol>, <ul>, <li>, to be precise).
Resolution: type on lists is not presentational.
Reply: http://www.w3.org/mid/16423.47458.270282.447366@lanalana.inria.fr
Response: http://www.w3.org/mid/4027D22B.7040706@mit.edu
Resolution: add "(except on LI, OL and UL elements)" after "type" in
the list in section 6.4.4.
Document updated.
Reply: http://www.w3.org/mid/16434.32592.921798.559429@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 55. http://www.w3.org/mid/200309282315.h8SNFiEh006969@nerd-xing.mit.edu
| Section 7.3 (Recognized media types)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/media.html#media-types>
| What does "The names of media types are normative" mean? What should a UA do
| when encountering an @media or @import rule that lists an unknown media type?
| E.g.
| @media screen, boomerang {
| ....
| }
hakon says: http://www.w3.org/mid/200311031937.hA3JbsG24559@mail.opera.no
| I reworded the text sightly to address Boris first concern. I do not
| suggest discussing @boomerang.
Resolution: Agreed; also add: "Unknown media type identifiers should
not result in the @media rule being ignored." somewhere. Also strike
"parenthetical" in the text "names of media types are normative, but
the parenthetical descriptions are informative".
Reply: http://www.w3.org/mid/16423.47455.464079.962636@lanalana.inria.fr
Document updated.
Response: http://www.w3.org/mid/4027D1EB.5070006@mit.edu
Resolution: Remove "parentherical".
Document updated.
Reply: http://www.w3.org/mid/16434.33059.22990.896833@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 56. http://www.w3.org/mid/1064856561.a6c4b580cmoschini@myrealbox.com
| In the CSS2.1 Default HTML Style sheet:
| http://www.w3.org/TR/CSS21/sample.html
| It still says that CSS2.1 cannot fully express the presentation
| of elements like img and frame. Yet CSS3 can, like so:
| img, object, applet, embed, iframe, frame, frameset {
| display:inline-block;
| }
| -- http://www.w3.org/TR/2003/WD-css3-ui-20030703/#qA
| With the introduction of inline-block to CSS2.1, it can in fact
| fully define all these elements' presentation. This and several
| other sections of the sample stylesheet need to be updated to
| reflect this newly available value in CSS2.1.
Reply: http://www.w3.org/mid/20030929175350.GA4936@darby.dbaron.org
| That doesn't fully describe the presentation, since it doesn't say what
| the replaced content is. Doing that requires CSS3.
| [...]
| The addition of 'inline-block' doesn't change *anything* for replaced
| elements, since the rules for inline and inline-block replaced elements
| are exactly the same. ('inline-block' allows non-replaced elements to
| act like inline replaced elements.)
Resolution: no change.
Issue closed.
------------------------------------------------------------------------
Issue 57. http://www.w3.org/mid/5D96738D926D724CA6744CB249F6799D17E5CA@RED-MSG-53.redmond.corp.microsoft.com
| http://www.w3.org/TR/CSS21/visufx.html
| The example list of overflow cases includes:
| - A descendent box has negative margins, causing it to be positioned
| partly outside the box.
| Even though this list is not meant to be comprehensive, I suggest we
| similarly add:
| - A descendent box is relatively positioned, causing it to be positioned
| partly outside the box.
| And change:
| "An element's height exceeds"
| to
| "An element's height (or line-height) exceeds"
| I think it's also possible that vertical-align of an absolute length
| (e.g. 200px) can also cause overflow.
Internal Reply: http://www.w3.org/mid/20031001001902.GA3745@darby.dbaron.org
| I'd prefer not to mention line-height here, since I don't think the
| logical box considered by line-height should be considered to be
| overflow. I think only the box generated by the font edge, padding,
| border (and margin?) should be considered overflow. That doesn't mean
| that the line-height couldn't cause overflow by increasing the height of
| a block, but the existing text accounts for that. If that's what you
| meant by the addition of the parenthetical comment, I'd rather not say
| that because I think it could be misinterpreted.
|
| Perhaps we should define what counts as overflow a little more clearly.
| For example, we could say whether it's the border-box, the margin-box,
| or the union of the two that defines the part of a box considered when
| computing overflow. Mozilla does border-box, and it would be rather
| difficult to change. Saying that it's only the margin-box would
| probably be a bad idea because of negative margins. The existing text
| isn't clear at all, and could be interpreted as undefined, as
| content-box, or perhaps as margin-box.
Resolution: no change.
Issue closed.
------------------------------------------------------------------------
Issue 58. http://www.w3.org/mid/15E88F9C-F3A7-11D7-B3E3-00039382AC6C@apple.com
| This reminds me of a question I had about relative positioning and
| overflow. It seems like the rule of relative positioning is that the
| object is not supposed to have any effect on the layout of following
| objects. However, if you decide that the final position of the object
| (once offset) constitutes overflow, and if overflow is set to auto, are
| you supposed to show scrollbars in order to scroll to the object?
|
| If you do show scrollbars, then you have just affected the layout of
| the object that follows you, despite the fact that the spec says you
| should not. Right now, when deciding whether or not to show
| scrollbars, Safari actually looks at the untranslated position and so
| Safari will not provide the ability to scroll to see the relative
| positioned content, but I suspect this might be different from other
| browsers.
Resolution: http://lists.w3.org/Archives/Member/w3c-css-wg/2003OctDec/0004.html
| Change 9.4.3 (visuren "Relative positioning"): Add "However, if
| relative positioning causes an overlflow:auto box to have overflow,
| the UA must allow the user to access this content, which, through the
| creation of scrollbars, may affect layout." to the first paragraph.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 59. text-decoration model discussion
Original thread:
http://www.w3.org/mid/3F7B235B.20958.28A853@localhost (needs answer A)
http://www.w3.org/mid/200310011710.h91HArhC013740@nerd-xing.mit.edu (reply)
http://www.w3.org/mid/3F7B2B12.5571.46C81E@localhost (reply)
http://www.w3.org/mid/Pine.GSO.4.58.0310012037070.20874@korppi.cs.tut.fi (needs answer B)
http://www.w3.org/mid/3F7B457C.12276.ADF822@localhost (reply)
http://www.w3.org/mid/Pine.GSO.4.58.0310012255100.25242@korppi.cs.tut.fi (reply)
http://www.w3.org/mid/3F7B596C.2060902@escape.com (good answer to B)
http://www.w3.org/mid/Pine.GSO.4.58.0310020923540.11649@korppi.cs.tut.fi (needs answer C)
http://www.w3.org/mid/3F7C661B.12938.2A2F51@localhost (CSS3 comments)
Issue split into 59a, 59b, 59c.
Issue closed.
------------------------------------------------------------------------
Issue 59a. http://www.w3.org/mid/3F7B235B.20958.28A853@localhost
Resolution: That's the way it was in CSS1.
Reply: http://www.w3.org/mid/16423.47452.313141.937717@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 59b. http://www.w3.org/mid/Pine.GSO.4.58.0310012037070.20874@korppi.cs.tut.fi
Reply: http://www.w3.org/mid/3F7B596C.2060902@escape.com
Reply: http://www.w3.org/mid/16423.47446.538444.910079@lanalana.inria.fr
Resolution: It was in CSS1 and is heavily used.
Issue closed.
------------------------------------------------------------------------
Issue 59c. http://www.w3.org/mid/Pine.GSO.4.58.0310020923540.11649@korppi.cs.tut.fi
Reply: http://www.w3.org/mid/16423.47449.480503.679534@lanalana.inria.fr
Resolution: We do not see any reason to deprecate.
Issue closed.
------------------------------------------------------------------------
Issue 60. formatting context discussion
Thread:
http://www.w3.org/mid/3F7B3147.4242.5F08EB@localhost (query)
http://lists.w3.org/Archives/Public/www-style/2003Oct/0050.html (reply)
http://www.w3.org/mid/3F89D7DF.13755.2A8DAB4@localhost (further query)
http://www.w3.org/mid/Pine.LNX.4.58.0310131334280.29626@dhalsim.dreamhost.com (reply)
http://www.w3.org/mid/3F8AF0D5.15739.531E32@localhost (issue)
Issue split into 60a, 60b, 60c.
Issue closed.
------------------------------------------------------------------------
Issue 60a. The term "based on the content" in 10.6.4 Absolutely
positioned, non-replaced elements is not defined. (If it is, it needs
a link to the definition.) (Occurs twice.)
Resolution: leave it up to Bert to resolve. [Added section 10.6.7
'Auto' heights for block formatting context roots based on Oslo
decision]
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 60b. In 9.4.1 Block formatting context, paragraph 3 is no longer
true for elements that generate new block formatting contexts but are
still in flow.
Resolution: Add ", unless the child establishes a new block formatting
context" to end of paragraph?
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 60c. http://www.w3.org/mid/3F8AF0D5.15739.531E32@localhost
Should inline-blocks that contain floats shrink wrap them?
Resolution: Yes. Covered by issue 6 resolution.
Reply: http://www.w3.org/mid/16423.47443.397987.150474@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 61. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
| Section 8.1 (Box Dimensions)
| <http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
| The description of "content edge or inner edge" makes it sound like this edge
| always surrounds the "rendered content"; the latter term is sort of vaguely
| defined. The overall impression given is that given the markup:
| <div style="height: 1px">
| line<br>
| line2
| </div>
| the "content edge or inner edge" will surround both lines (which is of course
| not the case).
| I hesitate to suggest a better wording offhand, though... Perhaps "content
| area" instead of "rendered content", with a link to a few paragraphs below
| where it says "The dimensions of the content area of a box ..."?
Resolution: Not a problem since 8.1 is rather vague anyway.
Reply: http://www.w3.org/mid/16423.47439.784732.980081@lanalana.inria.fr
Response: http://www.w3.org/mid/4027DDFA.7090700@mit.edu
Reply: http://www.w3.org/mid/20040209194019.GA6816@darby.dbaron.org
Proposal: A simple proposal to fix this issue is to change:
The content edge surrounds the element's rendered content.
to:
The content edge surrounds the rectangle given by the width and height
of the box, which often depend on the element's rendered content.
(Note that "width" and "height" are not links to properties, since that
would be inappropriate for some types of boxes, but they could be links
to sections 10.
7D76
3 and 10.6.)
Resolution: Take change.
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 62. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.1 (Box Dimensions)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#box-dimensions>
The definition of "box width" given in this section gives me some pause. The
only mentions of the term "box width" in chapters 8-18 of the specification
(other than this definition) are:
A) A statement immediately preceding that says that box widths are explained
in a later chapter.
B) Discussion of percent values for left/right (section 9.3.1 Choosing a
positioning scheme: 'position' property). The prose there says these
are percentages of the "containing block's box width"; is it really intended
that he containing block's margin's affect the offset from the padding edge in
this case, per the definition of "box width"?
C) Discussion of min-width/max-width (10.4 Minimum and maximum widths:
'min-width' and 'max-width'). The prose here says that these properties
constrain "box widths".... except that's not true according to the Section
8.1 definition of "box width". They constrain content widths.
D) A reference to "page box width" in chapter 13. This also seems to want the
content width.
In short, there is no usage of this term in this specification that is
consistent with the definition. I suggest striking the definition and changing
the two uses to refer to content widths, since that seems to be the desired
effect.
The "box height" seems similarly useless.
Resolution: Remove definition of box width and box height (A),
Document updated.
Resolution: change occurrences B (remove "box")
Document updated.
Resolution: and C (use "content width" instead of "box width").
Document updated.
Resolution: D is referring to the {{page box} width} not the {page
{box width}}.
Reply: http://www.w3.org/mid/16423.47433.476395.452258@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 63. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.2 (Example of margins, padding, and borders)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#mpb-examples>
"The height of each LI box is given by its content height, plus top and bottom
padding, borders, and margins." What does that mean, exactly? That is, what
does "the height of each LI box" in real terms? The exampls does not really
say what this quantity (which is not even well-defined in the presence of
margin collapsing) is used for.
Resolution: Only an example.
Reply: http://www.w3.org/mid/16425.21820.894632.976802@lanalana.inria.fr
Response: http://www.w3.org/mid/4029683C.5050304@mit.edu
Resolution: Use 'margin-box height' instead of 'height'.
Document updated.
Response: http://www.w3.org/mid/200402161730.i1GHUrOC012037@nerd-xing.mit.edu
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402161755520.2210@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 64. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.3.1 (Collapsing margins)
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html>
"Collapsing is based on the computed value of 'padding', 'margin', and
'border'."
The computed value of margin properties is "the percentage as specified or the
absolute length". What exactly does it mean for collapsing be based on the
computed value if that can be "the percentage as specified"? Especially if the
collapsing margins belong to boxes with different containing blocks (and hence
different meanings of percentage values)?
Resolution: Changed "computed" to "used".
Reply: http://www.w3.org/mid/16425.21827.40104.443466@lanalana.inria.fr
Document updated.
Issue closed.
------------------------------------------------------------------------
Issue 65. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.4 (Padding properties: 'padding-top', 'padding-right',
'padding-bottom', 'padding-left', and 'padding')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#padding-properties>
Unlike margin and border, conforming HTML user agents _do_ have to apply
padding to <html>?
Resolution: \/\/hatever. Non-issue.
Reply: http://www.w3.org/mid/16425.21831.313768.129260@lanalana.inria.fr
Response: http://www.w3.org/mid/402968C8.8050807@mit.edu
Resolution: Remove the two other caveats.
Document updated.
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402171524260.14033@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 66. http://www.w3.org/mid/200310041953.h94JrMkT024123@no-knife.mit.edu
Section 8.5.4 (Border shorthand properties: 'border-top', 'border-bottom',
'border-right', 'border-left', and 'border')
<http://www.w3.org/TR/2003/WD-CSS21-20030915/box.html#border-shorthand-properties>
The heading should list top, right, bottom, left in that order, probably.
Resolution: No change.
Reply: http://www.w3.org/mid/16425.21835.556302.689718@lanalana.inria.fr
Response: http://www.w3.org/mid/4029694D.4030101@mit.edu
Resolution: We'll fix it for you.
Document updated.
Reply: http://www.w3.org/mid/Pine.LNX.4.58.0402171526230.14033@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 67. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
These two sentences are in conflict:
S4.1.3 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q6>:
# In CSS 2.1, identifiers... cannot start with a hyphen or a digit.
S4.1.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q4>:
# In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
Resolution: Strike "a hyphen or" from 4.1.3.
Document updated.
Reply: http://www.w3.org/mid/16425.21839.732821.339942@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 68. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.1.7 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#q10>:
# A rule set (also called "rule") consists of a selector followed by
# a declaration block.
What you're saying here is that a "rule" is also a "set of rules".
The construct should be either singular /or/ plural, not both at the
same time. Please pick *one*. (And make sure its use is consistent.)
# A declaration-block (also called a {}-block in the following text)
# starts with a left curly brace ({) and ends with the matching right
# curly brace (}).
Is there a particular reason why "declaration-blocks" are not defined in
terms of "blocks" (as defined in the previous section)?
And don't call it a {}-block. @media rules have braces-delimited blocks,
too. Just call it a declaration block. It's a nice, unambiguous term;
there's nothing wrong with it.
Resolution: No change.
Reply: http://www.w3.org/mid/16425.21844.920400.9373@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 69. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.1.9 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#comments>:
# CSS also allows the SGML comment delimiters ("<!--" and "-->") in
# certain places, but they do not delimit CSS comments. They are
# permitted so that style rules appearing in an HTML source document
# (in the STYLE element) may be hidden from pre-HTML 3.2 user agents.
# See the HTML 4.0 specification ([HTML40]) for more information.
It says SGML comment delimiters are allowed "in certain places". Very
mysterious-like, especially considering the amount of detail about
HTML. Why not say where exactly?
And why is the definitive CSS document referring to the HTML 4.0 spec
for details about CSS syntax? Or is the "more information" more
information about hiding from pre-HTML 3.2 user agents, not "more
information" about, like, where the comment delimiters may be placed?
Resolution: Change text to say "in certain places _defined by the
grammar_" in section 4.1.9.
Document updated.
Reply: http://www.w3.org/mid/16425.21847.694241.729068@lanalana.inria.fr
Issue closed.
------------------------------------------------------------------------
Issue 70. http://www.w3.org/mid/3F81EB3F.5020400@escape.com
S4.2 <http://www.w3.org/TR/2003/WD-CSS21-20030915/syndata.html#parsing-errors>: