W3C home > Mailing lists > Public > www-style@w3.org > January 2004

[CSS3-Page] 6 comments on the last call draft

From: Ernest Cline <ernestcline@mindspring.com>
Date: Mon, 5 Jan 2004 01:04:30 -0500
Message-ID: <410-22004115643093@mindspring.com>
To: "Ernest Cline" <ernestcline@mindspring.com>, "W3C CSS List" <www-style@w3.org>

> [Original Message]
> From: Ernest Cline <ernestcline@mindspring.com>
> To: W3C CSS List <www-style@w3.org>
> Date: 12/19/2003 7:23:35 PM
> Subject: [CSS3-Page] 30 comments I have on the draft, mostly editorial
> 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.

I haven't gotten any sort of a response on even those six, which I will
attribute to the holidays.  Now that the holidays are beginning to be
behind us, I'm going to repeat those six comments here, and if
that still fails to elicit a response, then next week I'll start repeating
them one at a time.  I don't mind a negative response, but a total
lack of response makes me wonder if they were even read.

> [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?

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

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

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

> [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.
Received on Monday, 5 January 2004 01:04:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:10 UTC