forked from w3c/csswg-drafts
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathissues-3
4100 lines (3401 loc) · 146 KB
/
issues-3
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 Second Last Call Issues List
===================================
This list covers issues raised on the Last Call Working Draft
http://www.w3.org/TR/2005/WD-CSS21-20050613/
and the interim Working Draft
http://www.w3.org/TR/2006/WD-CSS21-20060411/
TO RESOLVE AN ISSUE add the line "Resolution:" followed by the
description of the resolution, and then a line on its own with either
one of "=Bert= Edit.", "=howcome= Edit.", and "=Tantek= Edit.", if an
edit is to be made, or just the line "Issue closed." if the issue is
closed. See other issues for examples.
Editors: 1-about = Bert, 2-intro = howcome, 3-conformance = howcome,
4-syndata = Tantek, 5-selector = Bert, 6-cascade = howcome, 7-media =
howcome, 8-box = Bert, 9-visuren = Tantek, 10-visudet = Bert,
11-visufx = Tantek, 12-generate = howcome, 13-page = howcome,
14-colors = Tantek, 15-fonts = Tantek, 16-text = Tantek, 17-tables =
Bert, 18-ui = Tantek, A-aural = Bert, C-changes = Bert, D-sample =
howcome, G-grammar = Bert, F-propix = auto
OUTSTANDING ISSUES:
Hixie has 2 actions
David has 1 action
------------------------------------------------------------------------
Issue 1.
URI: http://lists.w3.org/Archives/Public/www-style/2005Jun/0034.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2004JulSep/0062
Description:
img:before not defined
Resolution:
img:before explicitly not defined in CSS2.1 because we are looking for
implementation and author feedback and will define this in more detail
in CSS3.
We never actually put our resolution in the spec, though.
Add the following sentence to the end of section 12.1 "The :before and
:after pseudo-elements":
This specification does not fully define the interaction of :before
and :after with replaced elements (such as IMG in HTML). This will
be defined in more detail in CSS3.
Issue closed.
------------------------------------------------------------------------
Issue 2.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0157.html
Description:
> Hyatt wrote:
> > I definitely think CSS 2.1 should not be dictating the precise position of
> > the tab stops. I would prefer it be reworded as a guideline/advisory. How
> > about changing the text at
> > http://www.w3.org/Style/Group/css2-src/text.html#q8
> >
> > to:
> >
> > "All tabs (U+0009) are rendered as a horizontal shift that lines up the
> > start edge of the next glyph with the next tab stop. Tab stops occur at
> > points determined by the user agent. One possible algorithm for user agents
> > to use when determining tab stops is at multiples of 8 times the width of a
> > space (U+0020) rendered in the block's font from the block's starting
> > content edge."
Resolution:
No change.
Issue closed.
------------------------------------------------------------------------
Issue 3.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0165.html
Description:
Unclear that word-spacing applies to NBSP characters.
Proposed changes (text.html, section "Letter and word spacing"):
change
"When white space is preserved, e.g. with 'white-space:pre', all
space characters are affected by word-spacing."
to
"Word spacing affects each space (U+0020), non-breaking space
(U+00A0), and ideographic space (U+3000) left in the text after
the white space processing rules have been applied."
Resolution:
Apply change described above.
Issue closed.
------------------------------------------------------------------------
Issue 4.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005AprJun/0175.html
Description:
I was just looking at the HTML diffs, and noticed that the computed
value for 'content' probably needs to reflect what is stated in the
definition of the 'normal' value: that a specified value of 'normal'
computes to 'none' for pseudo-elements:
http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#content
(Should it also say that the computed value for elements is always
normal? Are we consistent about how we describe computed values in
cases where a property doesn't apply?)
Proposal: Change the 'computed value' line to:
On elements, always computes to 'normal'. On :before and :after, if
'normal' is specified, computes to 'none'. Otherwise, for URI
values, the absolute URI; for attr() values, the resulting string;
for other keywords, as specified.
Resolution:
Apply change described above.
Issue closed.
------------------------------------------------------------------------
Issue 5.
URI: http://weblogs.mozillazine.org/roc/archives/2005/06/displayinline_a.html
Description:
Authors use 'display:inline' on <table> elements to make inline
tables, which works in IE but breaks in compliant UAs.
Proposal: Add the following statement in 17.2.1 in points 2, 3, and 4
after the sentences ending in "P and T":
If P is an 'inline' box, then the generated box must be an
'inline-table' box instead of a 'table' box.
Resolution:
Accept proposal.
Issue closed.
------------------------------------------------------------------------
Issue 6.
Description:
(o173071)
The grammar definition of an identifier differs from the prose
definition. The prose, in fact, has two separate definitions for
different things.
Resolution:
Issue became moot due to later resolution of issue 167.
Issue closed.
------------------------------------------------------------------------
Issue 7.
Description:
The following note is repeated twice in the current draft. (Section 5.8.3)
# Note: If an element has multiple class attributes, their values must
# be concatenated with spaces between the values before searching for
# the class. As of this time the working group is not aware of any
# manner in which this situation can be reached, however, so this
# behavior is explicitly non-normative in this specification.
At least a bazillion people reported this duplicate paragraph.
Resolution:
Assumed editorial.
Issue closed.
------------------------------------------------------------------------
Issue 8.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1050615183256.27687C-100000@rmi-sun.rmi.acnet.ge
Description:
Request for CSS2.1 to address namespaced selectors.
Resolution:
Rejected, too late. Proposed text already in CR.
Issue closed.
------------------------------------------------------------------------
Issue 9.
URI: http://www.w3.org/mid/Pine.GSO.3.96.1050615185433.27687D-100000@rmi-sun.rmi.acnet.ge
Description:
Interaction of lists and counters.
Resolution:
Response: http://www.w3.org/mid/20050615164224.GA29310@ridley.dbaron.org
Issue closed.
------------------------------------------------------------------------
Issue 10.
URI: http://www.w3.org/mid/42B07254.6039.F863E@localhost
URI: http://www.w3.org/mid/42FA474B.6855.268DB0@localhost
Response: http://www.w3.org/mid/200509131657.33583.bert@w3.org
URI: http://www.w3.org/mid/43296F0E.3000507@comhem.se
Response: http://lists.w3.org/Archives/Public/www-style/2005Sep/0135.html
URI: http://lists.w3.org/Archives/Public/www-style/2005Sep/0178.html
Description:
Discussion about the replaced element intrinsic sizing rules,
concluding with the following question: "does the table under
'max-width' still work when the replaced elements use the intrinsic
ratio?"
Resolution:
Replace "In this table, w and h stand for the intrinsic width and
height, respectively." with:
"In this table <var>w</var> and <var>h</var> stand for the results
of the width and height computations ignoring the 'min-width',
'min-height', 'max-width' and 'max-height' properties. Normally
these are the intrinsic width and height, but they may not be in the
case of replaced elements with intrinsic ratios."
Issue closed.
------------------------------------------------------------------------
Issue 11.
Description:
It was pointed out in [1] that there is an error in the first example
in section 12.4 [2]. The simplest fix is to add a style rule to the
example:
body { counter-reset: chapter; } /* create a chapter counter scope */
so that the implicit counter creation rules don't create a separate
counter for each header.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=288946
[2] http://www.w3.org/TR/2005/WD-CSS21-20050613/generate.html#counters
Resolution:
Make edit as suggested.
Issue closed.
------------------------------------------------------------------------
Issue 12.
URI: http://www.w3.org/mid/Pine.LNX.4.61.0506181311570.32467@tuomi.oulu.fi
Description:
http://www.w3.org/TR/CSS21/conform.html#x22
| For example, table-column-group elements cannot have borders around
| them, so the border properties must be ignored.
As table-column-group can have borders around them in collapsed border
Better example might be: table-column elements can't affect to font of
column, so the font properties must be ignored.
Resolution:
Make edit as suggested.
Issue closed.
------------------------------------------------------------------------
Issue 13.
URI: http://www.w3.org/mid/op.sskju0zvk4suho@briann.wlfdle.phub.net.cable.rogers.com
Description:
The note near the end of the section is not closed. This has the
unfortunate side-effect of propagating the element's green styling to
the rest of the document in some agents. :(
Resolution:
Fix markup.
Issue closed.
------------------------------------------------------------------------
Issue 14.
URI: http://www.w3.org/mid/20050623172020.GA5947@ridley.dbaron.org
Description:
On Thursday 2005-06-23 21:05 +1000, Michael Day wrote:
> Can pseudo-elements that are not generated still affect counters?
>
> For example:
>
> h1::before {
> content: normal;
> counter-increment: heading;
> }
I think not. I thought 12.4.3 said so explicitly, but apparently it
doesn't. It probably should.
Resolution:
Make edit as suggested.
Issue closed.
------------------------------------------------------------------------
Issue 15.
URI: http://www.w3.org/mid/ef5d0f2f05062802487bdc96da@mail.gmail.com
Description:
'Implementors are urged to implement these features, or correct bugs
in their implementations, if they wish to see thsse features remain in
this specification.'
'thsse' should be 'these', I believe.
Resolution:
Fix typo.
Issue closed.
------------------------------------------------------------------------
Issue 16.
URI: http://www.w3.org/mid/42C69AC2.4050504@lachy.id.au
Description:
While attempting to greatly improve upon some CSS tests I had
written previously for the border collapse conflict resolution
algorithm, I've come across an issue in the spec. Step 4 of the
conflict resolution algorithm states [1]:
4. If border styles differ only in color, then a style set on a cell
wins over one on a row, which wins over a row group, column, column
group and, lastly, table. It is undefined which color is used when
two elements of the same type disagree.
It needs to be defined which border of two elements of the same type
takes precedence when they only differ by colour. Both Firefox and
Opera take a completely different approach, yet because the behaviour
is undefined, both are correct. See the test case [2].
Firefox seems to apply the border colour from the cell above or the
left, while Opera seems to apply the border colour from the cell below
or to the right. I think it makes more sense the way Firefox
implements it, but either way, I think it should be defined.
[1] http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution
[2] http://lachy.id.au/dev/css/tests/bordercollapse/012
Testcase demo: http://junkyard.damowmow.com/207
Resolution:
In 17.6.2.1: Change
4. If border styles differ only in color, then a style set on a cell
wins over one on a row, which wins over a row group, column,
column group and, lastly, table. It is undefined which color is
used when two elements of the same type disagree.
...to:
4. If border styles differ only in color, then a style set on a cell
wins over one on a row, which wins over a row group, column,
column group and, lastly, table. When two elements of the same
type conflict, then the one further to the left (if the table's
'direction' is 'ltr'; right, if it is 'rtl') and further to the
top wins.
Issue closed.
------------------------------------------------------------------------
Issue 17.
URI: http://www.w3.org/mid/Pine.LNX.4.61.0507022020550.11931@dhalsim.dreamhost.com
Description:
9.4.2, para 4:
> "If that property has the value 'justify', the user agent may stretch
> the inline boxes as well."
>
> Does UA allowed to stretch *all* inline boxes (including inline blocks) ?
Resolution:
inline-blocks and inline-tables and their contents shouldn't be
affected here, only actual display:inlines.
In 9.4.2, change "the user agent may stretch the inline boxes as
well." to "the user agent may stretch spaces and words in
display:inline boxes as well." In 16.2, change "the UA may stretch the
inline boxes in addition to adjusting their positions" to "this
property specifies that the inline boxes are to be made flush with
both sides of the block".
Further discussion at:
http://www.w3.org/mid/43271016.6010701@inkedblade.net
http://www.w3.org/mid/200509141456.08425.bert@w3.org
...which may suggest better text.
Issue closed.
------------------------------------------------------------------------
Issue 18.
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0034.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0038.html
URI: http://lists.w3.org/Archives/Member/w3c-css-wg/2005JulSep/0039.html
Description:
Proposal to use 'padding edge' not 'content edge' in 10.1, for
inlines.
Resolution:
Specifically, the three occurances of "content" in 10.1 list item 4
should be changed to "padding" (and then change "right edges" to
"right padding edges" in the second sub-list item).
Issue closed.
------------------------------------------------------------------------
Issue 19.
URI: http://www.w3.org/mid/8E265F97-14C9-44D0-9BF5-37D4E8377447@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Jul/0329.html
Description:
Versioning information story.
Resolution:
Assumed by Bert, Ian: Do nothing as per Sophia F2F.
Issue closed.
------------------------------------------------------------------------
Issue 20.
URI: http://www.w3.org/mid/A0700B54-BD9F-4C0A-BDE0-D5C3A64B707C@w3.org
Response: http://lists.w3.org/Archives/Public/www-style/2005Aug/0171.html
Description:
Request for implementation report of CSS2 in terms of CSS2.1.
Resolution:
Assumed by Ian that this would be WAY too much work and that we don't
want to do it.
Asked Karl if Appendix C is enough.
Issue closed.
------------------------------------------------------------------------
Issue 21.
URI: http://www.w3.org/mid/20050712214143.GB671@ridley.dbaron.org
Description:
I just noticed one more change that I think we need to make in section
10.4. We should change the sentence:
However, for replaced elements with both 'width' and 'height'
specified as 'auto', the algorithm is as follows:
to be:
However, for replaced elements with an intrinsic ratio and both
'width' and 'height' specified as 'auto', the algorithm is as follows:
because I don't think these rules are intended to apply to IFRAMEs or
OBJECTs that embed HTML documents. (It was clearer that they didn't
make sense before the change we agreed to this morning that made them
work for the intrinsic-ratio-but-no-intrinsic-size case.)
-David
Resolution:
Agreed.
Issue closed.
------------------------------------------------------------------------
Issue 22.
URI: http://www.w3.org/mid/EDECFB54-2989-465B-AA38-088DD3F5011C@w3.org
Description:
It is said that
[[[
Conforming user agents must correctly map to Unicode all characters in
any character encodings that they recognize (or they must behave as if
they did).
]]] - http://www.w3.org/TR/2005/WD-CSS21-20050613/syndata.html
The way you define references is very important. The sentence is a bit
vague here with regards to Unicode.
See http://www.w3.org/TR/qaframe-spec/#ref-define-practice
For unicode specifically, the specification Charmod explains how to
reference Unicode.
http://www.w3.org/TR/2005/REC-charmod-20050215/#sec-RefUnicode
-Karl
Resolution:
Editorial.
For Unicode, resolution is to refer to latest (dynamic).
Issue closed.
------------------------------------------------------------------------
Issue 23.
URI: http://www.w3.org/mid/AAAB784B-9C78-4C1C-9403-092E7BA57916@w3.org
URI: http://www.w3.org/mid/i51ekacjbi2.wl@w3.mag.keio.ac.jp
URI: http://www.w3.org/mid/9750588.1121456022734.JavaMail.servlet@kundenserver
URI: http://www.w3.org/mid/op.svanzwqtsmjzpq@r600
Description:
Request to update HTML4.0 references to HTML4.01.
Resolution:
Done.
Issue closed.
------------------------------------------------------------------------
Issue 24.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> Use of terms: "version" vs. "level" vs. "revision"
>
> For me, the use of terms "version" and "level" is confusing, especially
> since "version" is not defined in the specification. Is "version" to
> mean ("level"|"revision")?
Resolution:
Change "any version of CSS" to "any level of CSS".
syndata: 4.1, 4.1.4
Change "future version of CSS" to "future update of CSS".
syndata: 4.1, 4.1.7, 4.2 (twice)
media: 7.3
visfx: 11.1.2
tables: 17.5, 17.5.2, 17.5.3
Change "a previous version of this specification" to "a previous
revision of this specification".
visfx: 11.1.2
Change "updated version" to "updated revision".
changes: C
Issue closed.
------------------------------------------------------------------------
Issue 25.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> Missing: List of special CSS characters
>
> The specification refers to "special CSS characters" that e.g. need
> escaping. I haven't found a list of these special characters. Have these
> to be inferred from parsing context and the core grammar?
> <http://www.w3.org/TR/CSS21/syndata.html#q6> (third bullet)
Resolution:
You have to derive it. In practice you don't need it; as an
implementor you just implement the grammar and make "\" skip past the
part of the code that looks for special characters. As an author you
just stick a "\" in when things don't work.
Issue closed.
------------------------------------------------------------------------
Issue 26.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> Missing: Resolving escapes
>
> Though probably not absolutely required, it would be helpful to have it
> explained that character escapes in tokens must be resolved before
> performing any (mostly: comparison-) operation, so that i.e. an
> identifier written as "te\st" is considered the same as if it had been
> written as "test". This would complement the already existing note that
> pre-processors must not resolve quotes.
> <http://www.w3.org/TR/CSS21/syndata.html#q6> (third bullet)
Resolution:
At the end of 4.1.3, add a sentence saying something like "The
identifier "te\st" is exactly the same identifier as "test".".
Issue closed.
------------------------------------------------------------------------
Issue 27.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> Use of terms: "ISO 10646" vs. "Unicode"
>
> In most places in chapter 4, ISO 10646 is referenced for character set.
> However, in two places the term "Unicode" is used (4.3.7 and 4.4.1). For
> consistency reasons, ISO 10646 should be used in those two places instead.
> <http://www.w3.org/TR/CSS21/syndata.html#strings>
> <http://www.w3.org/TR/CSS21/syndata.html#q24>
Resolution:
Editorial.
Issue closed.
------------------------------------------------------------------------
Issue 28.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> Inconsistent spelling
>
> Throughout chapter 4, spelling of the following terms is changes randomly:
>
> style sheet <--> stylesheet
> CSS2.1 <--> CSS 2.1
> declaration block <--> declaration-block
>
> I suggest picking one and sticking with it.
Resolution:
"style sheet" two words, "declaration block" two words, "CSS 2.1" with
a space.
Be careful not to change the grammar token "stylesheet"!!
Issue closed.
=Hixie= reverify
------------------------------------------------------------------------
Issue 29.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> Concern: starting identifiers with hyphens
>
> I have voiced my concerns and objection to allowing identifiers to start
> with an unquoted hyphen vehemently in the past and will leave it
> therefore at it.
Resolution:
Ok then...
Issue closed.
------------------------------------------------------------------------
Issue 30.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> All levels of CSS -- level 1, level 2, and any future levels -- use the
> same core syntax. This allows UAs to parse (though not completely
> understand) style sheets written in levels of CSS that didn't exist at
> the time the UAs were created.
> ]]]
> and
> [[[
> The list of tokens for CSS2.1 is as follows.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
>
> If all levels of CSS use this *same* core syntax, then why is it only the
> list of tokens for *CSS 2.1* and not all versions of CSS? Remove the
> reference to CSS 2.1 in the second sentence.
Resolution:
Change "The list of tokens for CSS 2.1 is as follows." to "The list of
tokens for CSS is as follows."
Issue closed.
------------------------------------------------------------------------
Issue 31.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> Appendix G describes a more restrictive grammar that is closer to the CSS
> level 2 language.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
>
> I have three issues with the wording of this sentence:
>
> (1) The reader is aware that he is reading the description for the core
> syntax. This reference has potential making him wonder whether what he
> reads is something normative or is not "the real" grammar he has to observe.
>
> Suggestion: Remove this reference to Appendix G completely.
Resolution:
In section 4.1.1 Tokenization, at the end of the paragraph starting
"Below is the core syntax for CSS", add "Parts of style sheets that
can be parsed according to this grammar but not according to the
grammar in Appendix G are among the parts that will be ignored
according to the <a>rules for handling parsing errors</a>."
Issue closed.
------------------------------------------------------------------------
Issue 32.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> Appendix G describes a more restrictive grammar that is closer to the CSS
> level 2 language.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
>
> I have three issues with the wording of this sentence:
>
> (2) When Appendix G describes a more restrictive grammar that is closer
> to CSS level 2 language (or isn't it CSS 2.1 ?), but still not CSS level
> 2, then why bother to specify it at all? Just describe the constructs in
> detail and unambigously in the description of the various parts (sections
> 4.1.2 ff.) - which you have done already - and don't bother to give a
> grammar at all. Why? Giving this grammar may lead implementors into
> believing they can use that grammar as-is for their implementation, when
> in fact they can't due to the many restrictions and error handling
> requirements which are not implementable by throwing the grammar at a
> scanner/parser generator. They might waste their time in doing this, just
> to find out some time later that a generated parser using the
> normative(!) grammar will not be easily forced into being a conforming
> parser, and that they would have been way better off in implementing the
> spec as described verbally (they'd have probably written a recursive
> descent parser manually right from the beginning, thereby having saved
> several hours of work.)
>
> Suggestion: Remove this reference to Appendix G completely.
Resolution:
Resolved by issue 31.
Issue closed.
------------------------------------------------------------------------
Issue 33.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> Appendix G describes a more restrictive grammar that is closer to the CSS
> level 2 language.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
>
> I have three issues with the wording of this sentence:
>
> (3) <nit-picking> Finally, when you want to give a grammar that is
> "closer to the CSS level 2 language", just how close is it? As far as it
> gets? As far as you managed? Why didn't you specify some more grammars
> that are "reasonably close", "a little closer" and "way close" as well?
>
> Suggestion: Remove this reference to Appendix G completely.
Resolution:
Resolved by issue 31.
Issue closed.
------------------------------------------------------------------------
Issue 34.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> The meaning of input that cannot be tokenized or parsed is undefined in
> CSS2.1.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#tokenization>
>
> I suggest removing the reference to CSS 2.1 here. This is the section on
> core grammar valid for all levels of CSS: there should not be a reference
> to the current level. When you need to apply restrictions to the core
> grammar, make it a specific section, "CSS 2.1 Grammar restrictions". This
> way, when there are several levels of CSS available to be implemented,
> readers of the spec have a chance to easily compare restrictions between
> levels they need to implement without having to browse through the
> otherwise identical descriptions of the core grammar, which - due to its
> nature - should never change in the future.
Resolution:
No change.
<David> I think this should stay the same. I think me may define this in
future versions.
<Ian> I agree.
<David> It can change as along as it is a backwards compatible change.
<Bert> No change.
Issue closed.
------------------------------------------------------------------------
Issue 35.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Response: http://lists.w3.org/Archives/Public/www-style/2005Oct/0141.html
Description:
> Suggestion of sectioning:
> - 4.1 CSS Core grammar: consists essentially of current 4.1.1 with
> references to CSS 2.1 removed.
> - 4.2 Grammar of CSS 2.1: consists of 4.2.1 with restrictions to the core
> grammar now in 4.1.1, and continues with 4.1.2, ... relabelled to 4.2.2, ...
>
> Of course, it would even be better to separate general constructs'
> descriptions which will not change (e.g. "Statement", "At-rule", ...)
> into the core grammar description, and then add restrictions for CSS 2.1
> in the CSS 2.1 grammar's section. It makes it much easier for
> implementors to decide on factorings and identifying features to be put
> into the parser core and which should go into configurable CSS profile
> support.
Resolution:
We will consider this for CSS3, but it doesn't seem appropriate for
CSS2.1 right now (not a change of functionality, so too late at this
time to change 2.1).
Issue closed.
------------------------------------------------------------------------
Issue 36.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> Keywords have the form of identifiers.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#keywords>
>
> The term "identifiers" is nowhere clearly visibly defined in the
> specification, though a link later in the document suggests that this
> should be the second item in the list in 4.1.3. Please add a link here
> since it is a forward reference to the definition.
Resolution:
Add link in 4.1.2 to make this clearer.
Issue closed.
------------------------------------------------------------------------
Issue 37.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> Keywords and property names,...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>
>
> The term "property names" is a *forward* reference to its definition in
> 4.1.8 (although there, only *property* is actually defined, but not
> *property name*). Suggesting to make it link to that section.
Resolution:
Add link.
Issue closed.
------------------------------------------------------------------------
Issue 38.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> In CSS2.1, identifiers may begin with '-' (dash) or '_' (underscore).
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>
>
> According to the core grammar, identifiers (assuming this being IDENT
> tokens) may start with these characters in *all* versions and levels of
> CSS, not just CSS 2.1 . I guess you mean to say that it is in the
> *keywords* and *property names* that CSS 2.1 allows them for use as
> vendor-specific extensions designators, but nowhere else.
Resolution:
Drop "2.1" and make it just "In CSS, identifiers..."
Issue closed.
------------------------------------------------------------------------
Issue 39.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> An initial dash or underscore is guaranteed never to be used in a
> property or keyword...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q4>
>
> Is "property" a synonym for "property name", or are these two different
> things? If it is the same (and it seems to be when reading 4.1.8), why is
> there the term "property name" used earlier in 4.1.2.1? Looks like it
> should be "property" only.
Resolution:
Answer is "yes", "property" and "property name" mean the same thing.
Change "property" to "property name" in two places in 4.1.8: in first
paragraph and in first paragraph after example.
Issue closed.
------------------------------------------------------------------------
Issue 40.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> ...consists of a list of statements (see the grammar above).
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q7>
>
> Suggestion: Remove "(see the grammar above)" and link "statements" to the
> respective line in the core grammar.
Resolution:
Link "grammar" to the grammar, but leave the bit in parentheses.
Issue closed.
------------------------------------------------------------------------
Issue 41.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> In this specification, the expressions "immediately before" or
> "immediately after" mean with no intervening whitespace or comments.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q7>
>
> This definition is rather buried, especially since it is not at 4.1-
> level, but can be construed to be part of 4.1.4-level. Move this up to
> 4.1, Syntax, introduction.
Resolution:
Editorial, but move it to 4.1.
Issue closed.
------------------------------------------------------------------------
Issue 42.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> ...after any valid rule other than an @charset or an @import rule.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#at-rules>
>
> Inconsistent usage of the term "rule" (first occurrence in sentence
> above): Later in 4.1.7, "rule" is defined to be a synonym for "rule set".
> Neither @charset nor @import are a rule set, however; they're at-rules.
> So the first occurrence of "rule" in the above should be changed to
> "statement".
Resolution:
Do exactly what he asks for (in 4.1.5).
Issue closed.
------------------------------------------------------------------------
Issue 43.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> ...to achieve the effect of only importing a style sheet for 'print' media,
> use the @import with media syntax...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#at-rules>
>
> Should probably be: "...use the @import rule with media syntax..." ("rule" added).
Resolution:
Do exactly what he asks for.
Issue closed.
------------------------------------------------------------------------
Issue 44.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> In between there may be any characters...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#block>
>
> Shouldn't this better read: "In between there may be any tokens..."? If
> not, what's the rationale behind using "characters"? Changing to "tokens"
> in the above would also mean you could drop "Single (') and double quotes
> (") must also occur in matching pairs, and characters between them are
> parsed as a string. See Tokenization above for the definition of a
> string." completely. Honestly, I do not understand why this description
> is falling back onto character level when there is a generally valid
> tokenization definition given already that is also universally valid for
> every style sheet.
Resolution:
Change "characters" to "tokens" in that sentence but do nothing else. (4.1.6)
Issue closed.
------------------------------------------------------------------------
Issue 45.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> ...followed by a declaration block. A declaration-block...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q10>
>
> Use consistent hyphenation for declaration block (i.e., none).
Resolution:
See issue 28.
Issue closed.
------------------------------------------------------------------------
Issue 46.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> ...also called a {}-block in the following text...
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#q10>
>
> I think it's unfortunate to use that abbreviation. When reading aloud,
> one always must remember how to pronounce "{}-block": Is it "braces-
> block"...? Or what was it again...? Well, it's a "declaration block", so
> why not keep using that as written? Same goes with the rule set
> abbreviation: Why introduce it? It makes communication more fragile
> between different people when there is a synonym to remember for each
> basic concept.
Resolution:
Replace "{}-block" with "declaration block" throughout that section
(used twice), and remove the "also called a" part that introduces the
term in the first place. (4.1.7)
Issue closed.
------------------------------------------------------------------------
Issue 47.
URI: http://www.w3.org/mid/20050713212905.652@mail.visualclick.de
Description:
> [[[
> Because of the way selectors work, multiple declarations for the same
> selector may be organized into semicolon (;) separated groups.
> ]]] - <http://www.w3.org/TR/CSS21/syndata.html#declaration>
>
> I think when turning around the above sentence, it is more precise:
>
> "A semicolon (;) separated list of declarations in the declaration block
> for a specific selector may be used as a shorthand for multiple single-
> declaration rule sets with the same selector in the same order.
>
> Thus, the following rule
>
> h1 {
> font-weight: bold;
> font-size: 12px;
> line-height: 14px;
> font-family: Helvetica;
> font-variant: normal;
> font-style: normal
> }
>
> is equivalent to
>
> h1 { font-weight: bold }
> h1 { font-size: 12px }
> h1 { line-height: 14px }
> h1 { font-family: Helvetica }
> h1 { font-variant: normal }
> h1 { font-style: normal }"