RE: [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)

> [Original Message]
> From: BIGELOW,JIM (HP-Boise,ex1) <>
> I agree you both commenters. When I update the spec later this month or
> next, I will have examples using A4, the sizes will be correct (when used)
> and in mm, in keeping with Ernest's comments.  I also, will reference the
> PWG spec [1] on paper sizes and names.  
> However, I'm not so sure about requiring support for all the paper names
> forth in [1].  I still think that A4 and Letter will cover most of the
> Of course, I can be convinced, otherwise, by persuasive reasoning.  My
> purpose is user/document author convenience and my feeling is that names
> more accurate and readable than sizes.  I don't think it is feasible to
> revise the spec, even periodically, just to add new media names -- that's
> the argument for use of sizes. 
> Is there a compromise that satisfies most of the people most of the time?

I don't get your point.  W3C specs such as XHTML aren't revised whenever
another language is added to ISO 639 or another MIME type is registered with
the IETF.  Rather they just reference the standard and mention where one
can get the latest list of registered values. Why then should CSS3 Page need
to be revised when the IEEE PWG accepts a new standard paper size?

 Presumably, just as with languages and MIME types, a UA will understand
 the ones that it can actually use and merely recognize as valid the ones
the it can't.   If it can handle printing to custom paper sizes then it
should be
able to parse the full forms such as "na_letter_8.5x11in" or
"custom_pre-shredded_1x297mm" and get the size information from the name.

As a side benefit, supporting the PWG self describing media sizes would
also mean that there would be no need to include <length> values in the list
of allowed values for 'size' as it would be able to get them from page size
values that use the full form. Since this would enable the elimination of
special casing what is allowed for <length> I am in favor of this.  I am
against having to special case general purpose values such as <length>,
but I can see why it would not be a good idea to allow page sizes to be
described in terms of units such as em and ex that are variable in size.

In any event, even if it is decided to not support IEEE-ISTO 5101.1 at this
I would strongly prefer that the keywords that CSS3 Page uses follow the
<classname> "_" <sizename> format (i.e., "na_letter" not "letter" and
"iso_a4" not "A4") so that it would be possible to add support for all
paper sizes in a later version  such as CSS4 Page without having to also
support keywords that do not conform to that format in the name of backward

 I am aware that "letter" and "a4" do conform to an even more permissive
format allowed by  the standard which allows for the use of just the
However, as I have said earlier, [1] there is potential confusion between
the ISO B-series sizes and the JIS B-series sizes which despite not being
the same sizes, share common <sizename>s.  Thus they require the
<classname> to know which is meant in a context where either could occur.
Hence, using just the <sizename> portion of the full self describing name
should not be done in an international standard such as CSS.

Since, as I understand it, the WG is also working with other standards
bodies on this module. (including hopefully the IEEE PWG)  Perhaps
you should get some input from them before coming to a final decision
on this particular issue.

Just so that my position on this issue is clear, let me finish up by
stating it concisely.  I feel that for the 'size' property, a UA that
conforms to
CSS 3 Page should be able to parse any media size self-describing name
as specified by Section 5 of IEEE-ISTO 5101.1-2002 or subsequent revisions.
(This enables the UA to get the page size from the dimensions included
in such names, and eliminates the need to include <length>{1,2} in the
allowed values of 'size'.)  A conforming UA could also recognize names
of the form <class-name> "_" <size-name> as allowed by Section 6 of that
standard. (This would permit use of the shorter names that Jim favors.)
It might be worthwhile to require that a conforming UA be able to
recognize a few common sizes such as "na_letter" or "iso_a4"
when the UA is able to print to those sizes so as to ensure that they
can be used interoperably,


Received on Monday, 19 January 2004 16:35:33 UTC