forked from w3c/csswg-drafts
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathissues-2
More file actions
3065 lines (2797 loc) · 119 KB
/
Copy pathissues-2
File metadata and controls
3065 lines (2797 loc) · 119 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 Post CR Issues List
==========================
This issues list covers issues in the Candidate Recommendation
http://www.w3.org/TR/2004/CR-CSS21-20040225/
_________________________________________________________________
,-----------------------------------------------------------------/|
| THIS ISSUES LIST IS CLOSED. ||
| ||
| NO MORE ISSUES WILL BE RESOLVED BEFORE THE CSS2.1 SPECIFICATION ||
| REACHES LAST CALL. (AGAIN.) ||
`-----------------------------------------------------------------+'
^Issue ([0-9]+[a-z]*)\.$
^URI: (.+)$
^Description:$ followed by lines of text
^Section: (.+)$
^Rejected.$
^Resolution:$ followed by lines of text
^Reply: (.+)$
^Issue closed.$
------------------------------------------------------------------------
Issue 1.
Description:
Need to add something somewhere to make it clear that vertical margins
on inline elements have no effect and can be ignored.
Resolution:
Add to the definition of "'margin-top', 'margin-bottom'", after the
property table (section 8.3):
| <p class="note">These properties have no effect on non-replaced inline
| elements.</p>
Issue closed.
------------------------------------------------------------------------
Issue 2.
Section: 7.3 Recognized media types
Description:
The spec says:
# Media types are mutually exclusive in the sense that a user agent
# can only support one media type when rendering a document. However,
# user agents may have different modes which support different media
# types.
This makes print-preview non-conformant according to some people.
Resolution:
Accepted.
Internal resolution:
Use text based on these:
<Hixie> Media types are mutually exclusive in the sense that a user agent
<Hixie> can only support one media type per canvas when rendering a
<Hixie> document. Multimodal media types use one canvas. However, user
<Hixie> agents may have different modes which support different media types.
<Hixie>
<Hixie> For example, the 'tv' media type's canvas has an X axis, a Y axis,
<Hixie> and a speech axis, but printing implies two canvases: the screen
<Hixie> canvas, and the print canvas.
<fantasai> Media types are mutually exclusive in the sense that
<fantasai> a user agent can only support one media type per canvas
<fantasai> when rendering a document. However, user agents may have
<fantasai> different modes which support different media types.
<fantasai> Note a multimodal media type is still only one media type.
<fantasai> The 'tv' media type, for example, has an x axis, a y axis,
<fantasai> and a speech axis all as part of a single canvas. Printing,
<fantasai> however, implies two canvases: the screen canvas and the
<fantasai> print canvas.
Issue closed.
------------------------------------------------------------------------
Issue 3.
URI: http://www.w3.org/mid/BC5AAC3E.36B54%25tantek@cs.stanford.edu
Section: 15.2 Font matching algorithm
Resolution:
Change "for the given element" to "for the given element or character".
Issue closed.
------------------------------------------------------------------------
Issue 4.
URI: http://www.w3.org/mid/5B78805D3185784993C473999029D73601150B14@RED-MSG-53.redmond.corp.microsoft.com
Section: 12.2 The 'content' property
Resolution:
Replace "in a block, inline, or marker box" with "in a block or inline box".
Issue closed.
------------------------------------------------------------------------
Issue 5.
URI: http://www.w3.org/mid/5B78805D3185784993C473999029D73601150AAA@RED-MSG-53.redmond.corp.microsoft.com
Section: 12.2 The 'content' property
Resolution:
Replace "Same as 'none', but increments (decrements) the level of
nesting for quotes." with "Introduces no content, but increments
(decrements) the level of nesting for quotes."
Issue closed.
------------------------------------------------------------------------
Issue 6.
Section: 17.6.2 The collapsing border model
URI: http://www.w3.org/mid/Pine.LNX.4.58.0402230022480.13400@dhalsim.dreamhost.com
Description:
We seem to be a little vague on where the table background extends to.
For example, with:
<table> table { background: yellow; border: 0.5em solid;
border-collapse: collapse; }
<tr> <td/> </tr> tr > td { border: 2em dotted; }
<tr> <td/> </tr> tr + tr > td { border: 1em dotted; }
<tr> <td/> </tr> tr + tr + tr > td { border: 3em dotted; }
</table>
Where does the yellow background go on the second row? There seems to
be only a few options (assuming that later rows coming in
incrementally shouldn't cause the background in earlier rows to
suddenly change extent or origin):
1. Having it extend outside the table on row 2, and only extend
through half the border on row 3 (i.e. extend as far as the first
row's border). This is the only option that will look ugly if the
borders are solid -- the other options all look fine if the border
is solid.
http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case1
2. Having it extend to half way through the border in all three cases.
Always looks ugly. Means there is no way to put a background behind
the complete border of a normal table.
http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case2
Implemented by: Mozilla (strict mode), Safari, MSN Mac.
3. Having it extend to the table's computed border-width. In this
case, it would extend 1.25em into the first row's border, 0.75em
into the second, and 1.75em into the third. That's a straight line,
half the table's computed border-width from the grid line.
Simplifies to option 2 when only the cells have borders (not the
table itself) which is quite common.
http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case3
Implemented by: Opera.
4. Having it extend to the each row's border edge. This would result
in an uneven background edge and probably be hard to implement, not
to mention being an issue with images. It looks cool though. For
some people.
http://www.damowmow.com/temp/csswg/css21/issues-cr-issue6-case4
5. Another?
Implemented by: Mozilla (quirks mode)
Note that case 3 can actually do the effect of case 2, so it is the
most flexible. The other cases can only do their own rendering, and
can't be tweaked to look like the others.
Resolution:
Add the following at the end of 17.6.2 before "Border conflict
resolution":
"CSS2.1 does not define where the edge of a background on a
table element lies."
=hyatt= Edit CSS3 Tables.
Issue closed.
------------------------------------------------------------------------
Issue 7.
Section: 5.12.1 The :first-line pseudo-element
URI: http://lists.w3.org/Archives/Public/www-style/2004Feb/0330.html
Resolution:
Change:
# A UA should act as if the fictional start tag of the first-line
# pseudo-element is just inside the innermost enclosing block-level
# element.
...to:
| A UA should act as if the fictional start tags of the first-line
| pseudo-elements were nested just inside the innermost enclosing
| block-level element.
Issue closed.
------------------------------------------------------------------------
Issue 8.
URI: http://www.w3.org/mid/Pine.LNX.4.58.0402232300580.1475@dhalsim.dreamhost.com
Resolution:
Agreed. |@charset "| followed by the literal charset name, then |";|
Issue closed.
------------------------------------------------------------------------
Issue 9.
Section: 4.4 CSS style sheet representation
URI: http://www.w3.org/mid/1488001767.20040224031102@w3.org
URI: http://www.w3.org/mid/20040224045752.GA32622@darby.dbaron.org
Resolution:
Change section 4.4 from:
# very start of the style sheet, not preceded by any characters,
# except possibly a "BOM" (U+FEFF).
...to:
| very start of the style sheet or immediately after a Byte Order Mark
| (BOM, U+FEFF) that is at the very start of the style sheet.
Issue closed.
------------------------------------------------------------------------
Issue 10.
Section: 4.4.1 Referring to characters not represented in a character encoding
URI: http://www.w3.org/mid/1488001767.20040224031102@w3.org
Rejected.
------------------------------------------------------------------------
Issue 11.
URI: http://www.w3.org/mid/3B206934-6766-11D8-A256-000502CB1B77@stickdog.com
Section: 7.3 Recognized media types
Resolution:
Change "should not" to "must not" in:
# Unknown media type names should not result in the @media rule being
# ignored.
Issue closed.
------------------------------------------------------------------------
Issue 12.
Section: 4.1.3 Characters and case
Description:
This text could definitely be made easier to understand:
# In CSS 2.1, identifiers (including element names, classes, and IDs
# in selectors) can contain only the characters [A-Za-z0-9] and ISO
# 10646 characters U+00A1 and higher, plus the hyphen (-) and the
# underscore (_); they cannot start with a digit. Only properties,
# values, units, pseudo-classes, pseudo-elements, and at-rules may
# start with a hyphen (-); other identifiers (e.g. element names,
# classes, or IDs) may not.
To highlight the relevant parts:
# In CSS 2.1, identifiers (including element names, classes, and IDs
# in selectors) can contain [...] the hyphen [...]. Only [...] may
# start with a hyphen (-); other identifiers (e.g. element names,
# classes, or IDs) may not.
Sure, the text is technically correct, but...
Proposal:
Just strike the first "(including element names, classes, and IDs in
selectors)".
Resolution:
Emphasise the second occurance of "start" in:
# In CSS 2.1, identifiers (including element names, classes, and IDs
# in selectors) can contain only the characters [A-Za-z0-9] and ISO
# 10646 characters U+00A1 and higher, plus the hyphen (-) and the
# underscore (_); they cannot start with a digit. Only properties,
# values, units, pseudo-classes, pseudo-elements, and at-rules may
# start with a hyphen (-); other identifiers (e.g. element names,
# classes, or IDs) may not.
Issue closed.
------------------------------------------------------------------------
Issue 13.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1040227131149.8909F-100000@rmi-sun.rmi.acnet.ge
Resolution:
Change the Changes chapter.
Issue closed.
------------------------------------------------------------------------
Issue 14.
Section: 16.6 Whitespace: the 'white-space' property
Description:
The link in:
# This property declares how _whitespace_ inside the element is handled.
...should be removed (it links to the grammar definition of
whitespace!).
Resolution:
Agreed.
Issue closed.
------------------------------------------------------------------------
Issue 15.
Description:
Kimberly should either be an editor or an acknowledged.
Resolution:
Acknowledge.
Issue closed.
------------------------------------------------------------------------
Issue 16.
Section: 16.6.1 The 'white-space' processing model, step 1
Description:
# Each non-linefeed whitespace character surrounding a linefeed
# character is removed if 'white-space' is set to 'normal', 'no-wrap',
# or 'pre-line'.
...should define "whitespace", or, better, just list which characters
it means. Ian thinks it is just U+0020 and U+0009.
Resolution:
Change the above paragraph in 16.6.1 The 'white-space' processing
model, step 1 to:
# Each tab (U+0009), carriage return (U+000D), or space (U+0020)
# character surrounding a linefeed (U+000A) character is removed if
# 'white-space' is set to 'normal', 'no-wrap', or 'pre-line'.
Issue closed.
------------------------------------------------------------------------
Issue 17.
Section: 12.5.1 Lists: the 'list-style-type', 'list-style-image', 'list-style-position', and 'list-style' properties
Description:
Should armenian, georgian, lower-greek be removed.
Resolution:
Maybe.
Add, to the status section:
<h3>Features at risk</h3>
<p>The working group has identified the following features as being
currently poorly implemented by UAs. They are therefore most at risk
of being removed from CSS2.1 when exiting CR. (Any changes of this
nature will still result in the specification being returned to last
call.) Implementors are urged to implement these features, or correct
bugs in their implementations, if they wish to see this feature remain
in this specification.</p>
<dl>
<dt>New 'list-style-type' values</dt>
<dd>
<ul>
<li>'armenian'</li>
<li>'georgian'</li>
<li>'lower-greek'</li>
</ul>
<p>Implementors should look at CSS3 Lists instead, where these and
many other new values not found in CSS1 are defined in detail.
[[CSS3LISTS]]</p>
</dd>
</dl>
Remove from 12.5.1:
# A user agent that does not recognize a numbering system should use
# 'decimal'.
Issue closed.
------------------------------------------------------------------------
Issue 18.
Description:
<fantasai> There's a section that says that margins, borders, and
padding of /non-replaced/ elements do /not/ enter into the line box
calculation, but I can't find the section that says margins, borders,
and padding on replaced elements do.
<dbaron> This is clear in CSS1, section 4.4, paragraph 5: "Replaced
elements (e.g. images) on the line can make the line-box bigger, if
the top of the replaced element (i.e., including all of its padding,
border and margin) is above the tallest text section, or if the bottom
is below the lowest."
Resolution:
Edit "10.6.1 Inline, non-replaced elements":
| But only the 'line-height' is used to calculate the height of the
| line box.
...to:
| But only the 'line-height' is used when calculating the height of
| the line box.
Add to "10.6.2 Inline replaced elements, block-level replaced elements
in normal flow, 'inline-block' replaced elements in normal flow and
floating replaced elements":
| For 'inline' and 'inline-block' elements, the margin box is used when
| calculating the height of the line box.
Add to "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":
| For 'inline-block' elements, the margin box is used when calculating
| the height of the line box.
Issue closed.
------------------------------------------------------------------------
Issue 19. http://www.w3.org/mid/3F875337.6080406@escape.com
Section: 5.8.2 Default Attributes
Description:
# EXAMPLE { /*... default property settings ...*/ }
# Because this selector is less specific than an attribute selector,
# it will only be used for the default case.
This is false. The selector will be used for all cases, not just the
default case. If a declaration from this rule conflicts with one from
a more specific rule, then it will be overridden--but the declaration
still applies.
Resolution:
Replace the entire example in 5.8.2 Default Attributes with the
example in:
http://lists.w3.org/Archives/Public/www-style/2004Feb/0391.html
Issue closed.
------------------------------------------------------------------------
Issue 20. http://lists.w3.org/Archives/Public/www-style/2003Nov/0021.html
Section: 16.6.2 Example of bidirectionality with white-space collapsing
Description:
This is wrong:
# This is best avoided by using the natural bidirectionality of
# characters instead of explicit embedding levels.
Richard Ishida was looking at this.
Resolution:
Replace the above with:
"This can sometimes be avoided by using the natural bidirectionality
of characters instead of explicit embedding levels. Also, it is good
to avoid spaces immediately inside start and end tags, as these tend
to do weird things when dealing with white space collapsing."
=fantasai= If that isn't good enough, please provide examples and
we'll open a new issue.
Issue closed.
------------------------------------------------------------------------
Issue 21.
Section: 4.4 CSS style sheet representation
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2004JanMar/0288.html
Description:
Define how the BOM and @charset should work.
Issue closed.
------------------------------------------------------------------------
Issue 22.
Section: 3.2 Conformance
Description:
It's unclear that CSS requires that UAs let authors disable all author
stylesheets.
Issue closed.
------------------------------------------------------------------------
Issue 23.
Section: 4.1.3 Characters and case
Description:
# backslash escapes allow authors to refer to characters they can't
# easily put in a document. In this case, the backslash is followed by
# at most six hexadecimal digits (0..9A..F), which stand for the ISO
# 10646 ([ISO10646]) character with that number, which must not be
# zero.
So what if it _is_ zero? What does that parse as?
Resolution:
Add a warning note in CSS2.1.
In CSS3, say that \0 (an escape of character 0) is simply ignored, so
blockquote and block\0quote are exactly equivalent.
=dbaron= Edit CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 24.
URI: http://bugzilla.mozilla.org/show_bug.cgi?id=182748
URI: http://www.w3.org/mid/20050223233244.GA555@ridley.dbaron.org
Description:
I suspect the spec should probably be changed to
add the paragraph that's in 10.3.3:
If 'width' is not 'auto' and 'border-left-width' +
'padding-left' + 'width' + 'padding-right' +
'border-right-width' (plus any of 'margin-left' or
'margin-right' that are not 'auto') is larger than
the width of the containing block, then any 'auto'
values for 'margin-left' or 'margin-right' are, for
the following rules, treated as zero.
...to other places.
dbaron has sent further details, see second URI.
Resolution:
Change the text within 10.3.7:
# If both 'margin-left' and 'margin-right' are 'auto', solve the
# equation under the extra constraint that the two margins get equal
# values.
to be:
: If both 'margin-left' and 'margin-right' are 'auto', solve the
: equation under the extra constraint that the two margins get equal
: values, unless this would make them negative, in which case when
: direction is 'ltr' ('rtl'), set 'margin-left' ('margin-right') to zero
: and solve for 'margin-right' ('margin-left').
And change the text within 10.3.8:
# 4. If at this point both 'margin-left' and 'margin-right' are still
# 'auto', solve the equation under the extra constraint that the two
# margins must get equal values.
to be:
: 4. If at this point both 'margin-left' and 'margin-right' are still
: 'auto', solve the equation under the extra constraint that the two
: margins must get equal values, unless this would make them negative,
: in which case when direction is 'ltr' ('rtl'), set 'margin-left'
: ('margin-right') to zero and solve for 'margin-right' ('margin-left').
Issue closed.
------------------------------------------------------------------------
Issue 25.
Description:
howcome says the text for "Used values" is a bit arcane.
Resolution:
Edit to say:
Computed values are processed as far as possible without formatting
the document. Some values, however, can only be determined when the
document is being laid out. For example, if the width of an element is
set to be a certain percentage of its containing block, the width
cannot be determined until the width of the containing block has been
determined. The <dfn id="usedValue">used value</dfn> is the result of
taking the computed value and resolving any remaining dependencies
into an absolute value.
Issue closed.
------------------------------------------------------------------------
Issue 26.
Section: 11.1.2 Clipping: the 'clip' property
Description:
We forgot to update the intro text. It still says:
# By default, the clipping region has the same size and shape as the
# element's border box.
It should say:
# By default, the element is not clipped.
Issue closed,
------------------------------------------------------------------------
Issue 27.
Description:
<exclipy> In CSS2.1:12.5.1, the list-style-type values "lower-alpha"
and "upper-alpha" aren't listed formally.
Issue closed.
------------------------------------------------------------------------
Issue 28.
Description:
There is a diagram in the text-decoration section that became out of
sync with the prose during editing.
Resolution:
Update text so that the sentence in "16.3.1 Underlining,
overlining, striking, and blinking: the 'text-decoration' property"
that reads "The <em>text</em> in the em block is not underlined at
all, as it is not contained in the same anonymous inline element." is
changed to read "The <em>text</em> in the em block is also underlined,
as it is in an in-flow block to which the underline is propagated."
(or similar) then update the image to be:
http://www.damowmow.com/temp/csswg/css21/underline-example.png
Issue closed.
------------------------------------------------------------------------
Issue 29.
Description:
empty-cells is too vaguely specified. Does a zero-height zero-width
image could as visible content? What if it is display:inline and thus
creates a line box? What about an empty block with no background,
border, padding, height, or width? What about... etc.
Proposal:
A cell is empty if it contains nothing but the whitespace characters
currently listed _and_ white-space would collapse those characters so
that they don't form a line box. Any other textual or element content
counts as visible content. (I assume we don't have to say anything
about PIs or comments, I mean, those obviously don't affect rendering
right? -Ian)
<Hixie> "cells are empty if they contain no in-flow nor floating
content other than whitespace that has been collapsed away by the
white-space property handling"?
Tests: http://www.hixie.ch/tests/adhoc/css/box/table/empty-cells/
Resolution:
Accepted.
Change this text in 17.6.1:
# Visible content includes " " and other whitespace except ASCII
# CR ("\0D"), LF ("\0A"), tab ("\09"), and space ("\20").
...so that it says:
Cells are empty unless they contain one or more of the following:
* floating content (including empty elements),
* in-flow content (including empty elements) other than whitespace
that has been collapsed away by the white-space property handling.
(Group agreed that cells are empty if they contain no in-flow nor
floating content other than whitespace that has been collapsed away by
the white-space property handling.)
Issue closed.
------------------------------------------------------------------------
Issue 30.
Description:
From CSSWG telecon minutes:
"explicitly state somewhere in media.html that unknown
identifiers are parseable in media lists (e.g.
@media blarg, screen, blorg { p { color: green; } }
should make p elements green for screen media)."
Issue closed.
------------------------------------------------------------------------
Issue 31.
URI: http://www.w3.org/mid/20040412233323.GA5478@darby.dbaron.org
Description:
I think it should be specified what happens when a stylesheet
specifies the same counter more than once in the value of the
'counter-increment' and 'counter-reset' properties. -dbaron
(See URI for details.)
Resolution:
They all get applied (so for counter-reset, the last one takes
effect).
Specifically, replace:
If the same counter is specified more than once in the value of the
'counter-reset' and 'counter-increment' properties, all counters are
processed in the order specified.
...with:
If the same counter is specified more than once in the value of the
'counter-reset' and 'counter-increment' properties, each mention of
the counter is processed (in the order specified).
Isue closed.
------------------------------------------------------------------------
Issue 32.
URI: http://www.w3.org/mid/1940625.20040411235142@w3.org
Description:
Alfonso Martinez pointed out that according to the CSS 2.1
recommendation, lower-greek is an alphabetic system, not a
numbering system, which -- to my surprise -- is true.
As is clear, from my bug report filing, lower-greek should be
reclassified as a numbering system, and handled accordingly,
by www browsers.
Resolution:
Keep lower-greek as alphabetic; in CSS3 we may have 'greek', if
someone can give us an algorithm.
Issue closed.
------------------------------------------------------------------------
Issue 33.
URI: http://www.w3.org/mid/4082CF57.9060709@mit.edu
Resolution:
In "10.8.1 Leading and half-leading" change "The minimum height
consist" to "The minimal height consists". In "10.8 Line height
calculations: the 'line-height' and 'vertical-align' properties", add
a fourth list item that is:
<li>If the resulting height is smaller than the minimal height of
line boxes for this block, as specified by the
<...>line-height</...> property, the height is increased to be that
minimal height.</li>
Issue closed.
------------------------------------------------------------------------
Issue 34.
URI: http://www.w3.org/mid/5B78805D3185784993C473999029D736016D684D@RED-MSG-53.redmond.corp.microsoft.com
Resolution:
Move the paragraph in "17.5.1 Table layers and transparency" after the
list in that section starting "The edges of the rows, columns, ...",
up to section "17.5 Visual layout of table contents", after the list
but before the note.
Then, change "sets" to "determines" in item 2 of the list in section
"Fixed table layout" in section "17.5.2 Table width algorithms: the
'table-layout' property".
Issue closed.
------------------------------------------------------------------------
Issue 35.
URI: http://www.w3.org/mid/4084367E.2020701@mit.edu
Resolution:
Add, after:
| If the letters that would form the first-letter are not in the same
| element, such as "'T" in <p>'<em>T..., the UA may create a
| first-letter pseudo-element from one of the elements, both elements,
| or simply not create a pseudo-element.
...the following:
| Similarly, if the first letter(s) of the block are not at the start
| of the line (for example due to bidirectional reordering), then the
| UA need not create the pseudo-element(s).
Issue closed.
------------------------------------------------------------------------
Issue 36.
URI: http://www.w3.org/mid/BC9B67BC.3A945%25tantek@cs.stanford.edu
Resolution:
Change "only one" in 10.3.8 Absolutely positioned, replaced
elements, subitem 6, to "an".
Issue closed.
------------------------------------------------------------------------
Issue 37.
Description:
(From: Felipe Gasper <fgasper@freeshell.org>)
I am designing a web application for managing accounting data. To
prevent users from "instinctively" holding SHIFT to capitalize, I am
capitalizing all text displayed in form elements (input[type='text']
{text-transform: uppercase}). This, of course, has no effect on the
*actual* data passed to the application server.
This technique works in Gecko and IE, but KHTML (both Konqueror and
Safari) ignores this CSS property of the <input> tag, presumably
because, technically, this is not "enclosed" text as the specification
seems to point out.
Perhaps some stipulation should be added to the CSS spec regarding
this useful property?
Resolution:
Specification says:
# CSS2.1 does not define which properties apply to form controls and
# frames
...which is good enough.
Issue closed.
------------------------------------------------------------------------
Issue 38.
URI: http://www.w3.org/mid/20040310010513.GA11213@darby.dbaron.org
Resolution:
Add to 6.2.1 "The 'inherit' value" some text that says that 'inherit'
on the root element is equivalent to using the initial value.
Issue closed.
------------------------------------------------------------------------
Issue 39.
URI: http://www.w3.org/mid/4058A078.9413.47C932@localhost
Resolution:
Add "Note: This may cause the containing block's width to be
negative." in section 10.1, as a paragraph of subitem 1 of item 4,
under subitem 2 of subitem 1 of item 4.
Add "If the containing block's width is negative, the used value is
zero." to the definition of <percentage> in 'min-width' in 10.4.
Issue closed.
------------------------------------------------------------------------
Issue 40.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
1. Recomended line-height
The default style sheet for HTML contains this:
body { line-height: 1.12 }.
But what all popular UAs use is line-height: 1.2 -isn't it?
This sentence about line-height (section 10.8.1)
"We recommend a used value for 'normal' between 1.0 to 1.2."
should be matched to the recomended value of appendix D.
Resolution:
Remove the line that says
body { line-height: 1.12 }
Issue closed.
------------------------------------------------------------------------
Issue 41.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
2. Recomended font-size of headings, scaling factors for font-size
There are significant differences between appendix D and section 15.7.
The font-sizes of headings don't match.
section 15.7
font-size xx-small x-small small medium large x-large xx-large
<font size> 1 2 3 4 5 6
heading h6 -- h5 h4 h3 h2 h1
scaling factor 0.60 0.75 0.89 1.0 1.20 1.50 2.0
appendix D 0.75em -- 0.83em 1.0em 1.17em 1.50em 2.0em
And think on something like this:
<body style="font-size:40px">
<h2 style="font-size:x-large">heading</h2>
<p>text</p>
On an average screen this h2 may have a font size of 24px, while the
text is larger. Headings should be sized relatively, like in appendix D,
and not absolutely, like section 15.7. may suggest. Throw it out here,
it's confusing.
I don't like the scaling factors of section 15.7. Is this really a
reflection of current implementations? 0.89 seems me to big and 0.60 to
small.
This may be a consistent compromise:
section 15.7
font-size xx-small x-small small medium large x-large xx-large
<font size> 1 -- 2 3 4 5 6
scaling factor 0.60 0.72 0.85 1.0 1.20 1.50 2.0
appendix D h6 h5 h4 h3 h2 h1
font-size 0.72em 0.85em 1.0em 1.20em 1.50em 2.0em
Or this range: 0.62 0.73 0.85 1.0 1.17 1.5 2.0
Proposed Resolution (Boston F2F):
Remove the HTML headings row of the table in 15.7 and remove the
mention of headings in the paragraph before it.
Disagreed by Tantek.
See also: http://www.w3.org/mid/20040701233052.GA12236@darby.dbaron.org
Testcase: http://dbaron.org/css/test/2004/font-size-table
From testing in IE6, FF0.8, and Opera7.53 -
------------+----------+---------+-------+--------+-------+---------+---------
Keyword | xx-small | x-small | small | medium | large | x-large | xx-large
Proportion | 5/9 | 7/9 | 9/11 | 1 | 6/5 | 3/2 | 2/1
Heading | -- | H6 | H5 | H4 | H3 | H2 | H1
<font> size | -- | 1 | 2 | 3 | 4 | 5 | 6
------------+----------+---------+-------+--------+-------+---------+---------
using David Baron's test case
http://dbaron.org/css/test/2004/font-size-table
Resolution:
Replace the table with a remark that a fixed ratio has given problems
in the past and that implementors are encouraged to build a table that
takes into account the medium font size of the user and the device it
is being displayed on and the resolution of the device.
Leave Appendix D as is.
Issue closed.
------------------------------------------------------------------------
Issue 42.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
3. I'm missing img in appendix D.
Shouldn't img have display:inline-block like object?
Resolution:
Remove 'object' from the 'inline-block' rule.
Issue closed.
------------------------------------------------------------------------
Issue 43.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
4. btw...
I found "CSS2" where "CSS 2.1" should be used:
12.4 Automatic numbering in CSS2 is controlled...
13.3.5 CSS2 does not define...
CSS2 does not forbid a user agent...
But CSS2 does recommend that...
... just like normal CSS2 declarations.
18 18.2 CSS2 System Colors
18.2 Note. The CSS2 System Colors...
...etc., CSS2 introduced...
Full Table of Contents 18.2 CSS2 System Colors
Resolution:
Chapter 18 is correct. The other two aren't though:
Edit section 12.4 to say CSS2.1 instead of CSS2.
Edit section 13.3.5 to say CSS2.1 instead of CSS2.
Issue closed.
------------------------------------------------------------------------
Issue 44.
URI: http://www.w3.org/mid/5365489$10804178564065de40129434.27614134@config21.schlund.de
Description:
5. btw...
section 4.1.2: -khtml- is a known vendor-specific extension too.
Resolution:
Do nothing.
Issue closed.
------------------------------------------------------------------------
Issue 45.
URI: http://www.w3.org/mid/20040504012730.GA8545@darby.dbaron.org
Resolution:
Add:
The width of the table is the distance from the left inner padding
edge to the right inner padding edge (including the border spacing
but excluding padding and border).
However, in HTML and XHTML, the the width of the <table> element is
the distance from the left border edge to the right border edge.
Note: In CSS3 this peculiar requirement will be defined in terms of
UA stylesheet rules and the 'box-sizing' property.
...after the second normative paragraph in 17.6.1 "The separated
borders model".
Issue closed.
------------------------------------------------------------------------
Issue 46.
URI: http://www.w3.org/mid/BCBC55C3.3CFAB%25tantek@cs.stanford.edu
Description:
In 'outline-color', in the final note, the outline is refered to as
"focus outline." I thought at first that this was another, independent
outline, so maybe the word "focus" should be dropped.
Issue closed.
------------------------------------------------------------------------
Issue 47.
URI: http://www.w3.org/mid/408AC1C4.4060106@mit.edu
Resolution:
No change.
Issue closed.
------------------------------------------------------------------------
Issue 48.
Section: 15.3 Font family: the 'font-family' property
Description:
We should say that <family-name> cannot start with a '/', so that
'font' parsing is non-ambiguous.
Resolution:
Change "Similarly, quote marks, semicolons, exclamation marks and
commas within unquoted font family names must be escaped." to
"Similarly, quote marks, semicolons, exclamation marks, commas and
leading slashes within unquoted font family names must be escaped." in
"15.3 Font family: the 'font-family' property".
Issue closed.
------------------------------------------------------------------------
Issue 49.
Description:
The grammar for 'property' doesn't allow for nested blocks which means
that font-family isn't described by the grammar.
Resolution:
Remove "either balanced or" from "15.3 Font family: the 'font-family'
property".
Issue closed.
------------------------------------------------------------------------
Issue 50.
Description:
Should we say that 'overflow' on the root element applies to the
viewport instead of the root element?
Resolution:
Change, in section 11.1.1 "Overflow: the 'overflow' property":
# HTML UAs may apply the overflow property from the BODY or HTML
# elements to the viewport.
...to:
# UAs may apply the 'overflow' property set on the root element to
# the viewport (instead of the root element). HTML UAs may also apply
# the 'overflow' property from the BODY element to the viewport.
Issue closed.
------------------------------------------------------------------------
Issue 51.
Description:
Should the description of the property tables be normative?
Resolution:
Remove "In this section, we begin the formal specification of CSS 2.1,
starting with the contract between authors, users, and implementors."
from section 3.1.
Issue closed.
------------------------------------------------------------------------
Issue 52.
Description:
CSS2.1 should clarify the ability for implementations and
specifications to extend the CSS language.
Resolution:
Add:
| CSS2.1 reserves for future versions of CSS all property:value
| combinations and @-keywords that do not contain an identifier
| beginning with dash or underscore. Implementations MUST ignore such
| combinations (other than those introduced by future versions of
| CSS).
...at an appropriate place in chapter 4 (e.g. first paragraph of 4.2,
or in 4.1).
Issue closed.
------------------------------------------------------------------------
Issue 53.
Description:
(raised at the workshop on compound documents)
Does a line breaking opportunity exist between two replaced elements?
Does a line breaking opportunity exist between two inline-blocks?
Does a line breaking opportunity exist between a character and one of
the above?
Assume no characters that allow line breaking are otherwise present.
Tests: http://dbaron.org/css/test/2003/line-breaking/
Tests: http://fantasai.inkedblade.net/style/tests/ad-hoc/line-breaking/objects/
Resolution:
Move to CSS3 and needs a formal proposal.
Add a note saying that "Note: CSS 2.1 does not fully define where line
breaking opportunities occur." to the end of section 16.6.1 The
'white-space' processing model.
Issue closed.
------------------------------------------------------------------------
Issue 54.
URI: http://lists.w3.org/Archives/Public/www-style/2004Mar/0178.html
Resolution:
Ian to reply.
Done: http://www.w3.org/mid/Pine.LNX.4.61.0503292104530.25644@dhalsim.dreamhost.com
Issue closed.
------------------------------------------------------------------------
Issue 55.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
1. According to chapter 4 in CSS 2.1, identifiers may
now begin with '-'. However, the lexical scanner in
Appendix G.2 has not been updated to reflect this change.
Resolution:
Bert to propose changes.
Issue closed.
------------------------------------------------------------------------
Issue 56.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
2. In section 4.1.3 it says about identifiers:
"... they cannot start with a digit."
Shouldn't this be:
"... they cannot start with a digit, or a '-' followed by a digit."
Resolution:
Editorial.
Issue closed.
------------------------------------------------------------------------
Issue 57.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
3. The grammar in Appendix G.1 states that function values
may be prefixed with a unary operator, that is, '+' or '-'.
But with the introduction of identifiers that start with '-',
it will no longer be possible to prefix functions with '-'.
Any attempt to do so will only cause the '-' to be considered
part of the function name. In other words, this syntax:
-myfunc(x)
will be tokenized as:
FUNCTION, IDENT, ')'
rather than
'-', FUNCTION, IDENT, ')'
As far as I know there are no functions in CSS 2.1 that it would
make sense to prefix with a minus sign, but apparently such functions
(representing length values, for example) may be introduced in CSS3?
(Note, that it will not help to say that function names cannot start
with '-', because the tokenizer will still see the '-' as part of
the identifier, and the example above will yield:
IDENT, '(', IDENT, ')'
which will likely cause a parsing error.)
Resolution:
Bert to propose changes.
Issue closed.
------------------------------------------------------------------------
Issue 58.
URI: http://lists.w3.org/Archives/Public/www-style/2004Jun/0013.html
Description:
4. Another change in the lexical scanner in CSS 2.1 is that some tokens
are defined to include their preceding white space (for example LBRACE).
This, together with the change that the production 'simple_selector'
no longer ends with S*, means that, for example, the following syntax
is no longer valid:
P /* A comment */ { color: red }
because this will tokenize as:
IDENT, S, LBRACE, S, IDENT, ':', S, IDENT, S, '}'
and the grammar does not allow the first S. (According to section
4.1.9, comments only occur between tokens, so the space before the
comment will not be seen as part of the LBRACE token.)
Resolution:
Bert to propose changes.