W3C home > Mailing lists > Public > www-style@w3.org > December 2003

[CSS3-Page] 30 comments I have on the draft, mostly editorial

From: Ernest Cline <ernestcline@mindspring.com>
Date: Fri, 19 Dec 2003 19:23:37 -0500
Message-ID: <410-2200312620023370@mindspring.com>
To: "W3C CSS List" <www-style@w3.org>

Comments on CSS3 Page

These comments are mostly editorial in nature; the exceptions are
comments [9], [14], [21], [22], [25], and [29].

I don't expect a response on any of these except the six comments
listed  above.

[1] Section 1:
The link for "Generated content module" should be to
http://www.w3.org/TR/css3-content and not to a specific working draft.

[2] Section 1:
In the item "the Generated content module which this module extents"
"extents" should be "extends".

[3] Section 2:
The link for "continuous media" should be changed to refer to a non-WD
version such as either:
http://www.w3.org/TR/CSS2/media.html#continuous-media-group
or:
http://www.w3.org/TR/CSS21/media.html#continuous-media-group
depending upon whether CSS 2.1 has exited from Last Call at the time
this module exits Last Call.

[4] Section 2:
The sentence "Furthermore, CSS3 assumes that one page box will be
transfer to a side of a sheet." should have the word "transfer"
changed to "transferred".

[5] Section 3.1:
In the clause "The following terminology and accompanying diagram make
up the page model:" I would prefer a substitute be used for "make up"
such as "describe" or "specify" be used instead.

[6] Section 3.1 "Page Box":
The link for "box model" should be to http://www.w3.org/TR/css3-box/
instead of to http://www.w3.org/TR/css3-page/ .

[7] Section 3.1 "Page Box":
In the clause "there are more complex uses cases", the word "uses"
should be "use".

[8] Section 3.1 "Margin box"
'top' and 'bottom' are mentioned as being present for compatibility
with previous versions of the document.  Could references for those
be provided?

[9] Section 3.1 "Margin box"
Was having 'left-center', 'left-top', etc. rejected because they were
too kitchen sinkish, or were they not considered?

[10] Section 3.1 "Margin box"
The table of margin box definitions should be changed either so that it
is a definition list, or the first column contains <th>'s.

[11] Section 3.1 diagram
The diagram contains a <note-box> area with no definition or reference
given in this section.

[12] Section 3.1 diagram
The pointer for "top box" should be moved so that the text is not
obscured by the vertical lines.

[13] Section 3.1 diagram
The diagram contains no visual distinction between the <page-box>
border and the <page-box> padding.  Those not familiar with the CSS
box properties could conclude from this diagram that they are supposed
to be the same thing.

[14] Section 3.2
This section and the accompanying terminology assumes that the standard
Western practice of binding so that the spine is to the left is the only
standard.  This is NOT the case. Standard Japanese practice is to bind
printed matter so that the spine is to the right.  Given the unfortunate
choice of :left and :right in CSS 2, I don't have any expectation of
changing the pseudoclasses, but the explanatory material should be
rewritten so as to be supportive of Japanese binding.

[15] Section 3.2 "Back side"
In the sentence "Typically, the back side is only used when printing on
both side of the medium." the phrase "on both side" should be "on both
sides".

[16] Section 3.2 "First page"
In the clause "documents where the writing direction is right-to-left
my cause the printer to place the first page on the back side of the
first sheet" the word "my" should be "may".

[17] Section 3.2 "Left page"
According to the only English dictionary I have been able to find that
mentioned this term, "versos" is the plural and "verso" is the singular.
The definition is written so that the singular should be used.

[18] Section 3.2 "Right page"
According to the only English dictionary I have been able to find that
mentioned this term, "rectos" is the plural and "recto" is the singular.
The definition is written so that the singular should be used.

[19] Section 3.3
In the sentence "Different parts of the world uses different paper
sizes." the verb "uses" should be in the singular form, "use".

[20] Section 3.3.1 Example
As Lachlan Hunt has already pointed out, the "cm"s for the A4 paper size
need to be changed to "mm"s.

[21] Section 3.3.2
Having opened Pandora's box with "A4" and "letter", I feel that the
standard should either (1) explain why the decision was made to limit
the listed sizes to just these two, (2) drop these sizes, or (3) change
the list of predefined sizes and explain why those were chosen.

With "A4" and "letter" as part of the standard, it does not take much
imagination to suppose that there will be those who try to extend the
standard on their own.  It would be best if the standard tries to
control these non-standard extensions is some manner.

For example, one could justify supporting only the ISO defined paper
sizes (ISO 216). envelope sizes (ISO 269), etc. by way of non-hyphenated
keywords.  Then if national sizes need to be predefined as well, the
standard could specify a convention such as:
<country-code> "-" <name>
Thus, we could have "us-letter" "ca-p4" or "ja-b4" if including keywords
for national standard paper sizes be deemed necessary.

[22] Section 3.3.2 <length>
Why does the page context have no notion of fonts?  Couldn't this be
the same as the notion held by ":root" exterior to this @-rule?  Or does
this introduce some sort of loop that isn't apparent to me?  Granted,
specifying page margins with respect to font size may not be a good
thing to do most of the time, but I fail to see why it is impossible.

[23] Section 3.4.1 Example
The placing of the comments in the example is haphazard.  Sometimes they
are inside the declaration block, other times they are outside.  Either
placement is justifiable, but the example would look better if comment
placement were consistent.

[24] Section 3.5
As per [22], why does the page context have no notion of fonts?

[25] Section 3.6
With :left and :right always being used even when printing single-sided,
how is an author supposed to be able to specify that he wants one set of
rules used when printing single-sided and a different set of rules when
printing double-sided?  The easiest solution seems to be to specify two
new media types for single-sided and double-sided paged printing (and
possibly a third for printing using a continuous non-paged roll, altho
that could be said to be outside the scope of this module).

[26] Section 4.2 maximum width of the top center cell
Shouldn't this be the width of the "page area" instead of the "page
sheet"?  The wording indicates that the corners play no part in
determining the width of the top-center cell.

[27] Section 7
It would be helpful if one or more links to the 'float' property in the
CSS3 Box Module were included here.

[28] Section 7.4
Where is "@float-area" formally defined?

[29] Section 8
What is the motivation for defining rotation as <integer> instead of
as an <angle>?  If the intent is to simplify the task for the UA,
limiting the potential values to "0", "90", "180" and "270" would be
much more useful than limiting the values to integer degrees.

[30] Section 8
"Tow values" should be "Two values".

Ernest Cline
ernestcline@mindspring.com
Received on Friday, 19 December 2003 19:23:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:25 GMT