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

> [Original Message]
> From: Michael Day <>
> To: Ernest Cline <>
> Cc: W3C CSS List <>
> Date: 1/24/2004 5:13:15 PM
> Subject: RE: [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)
> Hi Ernest,
> > I said discount, not ignore.  You have a vested interest in seeing that
> > the CR follows what you have already implemented which raises the
> > possibility of a conflict of interest.  That is one reason why it is
> > suggested that private extensions to CSS such as those that Yes
> > Logic uses have a vendor specific prefix.  That suggestion has
> > been pointed out to you before IIRC,
> Are you serious?
> @page { size: yeslogic-a4 }
> @page { size: microsoft-a4 }
> @page { size: moz-a4 }
> @page { size: -o-a4 }
> Of course we will not introduce a vendor specific keyword to represent the
> A4 paper size. It is an international standard (!) and hardly likely to
> change on a whim. Vendor specific prefixes are not necessary for things
> that can only be implemented in one possible way. The following example is
> so perfectly obvious and idiomatic that it would be crazy to remove it:
> @page { size: A4 }
> I strongly believe that this should be in the standard, not because we
> have already implemented it, but because it is a good idea. You are
> putting the cart before the horse: we implemented it *because* we believe
> that it is a good idea, and we wish to see it in the standard for the same
> reason.

Just because you think "A4" is obvious does not mean that others will
think so, or that it will turn out to be the best solution.  "A4" is
an obvious choice to consider, but for the reasons I have already
given, I don't think that it is the best choice.

Had you followed the recommendation in this case it would have been:

@page {size: -yeslogic-a4 }

(Note the extra - in front.)  Yes, the recommendation does put an extra
burden on those who seek to extend the standards beyond the current
recommendations, but I can't fault the reasoning behind it.

> If iso-a4 is added to the standard we will definitely support it.  
> However, we will not remove support for "a4", as the good reasons for
> having it remain valid. Our implementation of this keyword without a
> vendor prefix is also valid, as the standard will never give the "a4"  
> keyword a meaning other than ISO A4 paper size.

I'll grant you that it is extremely unlikely that the keyword "a4" would be
used in any other meaning in the context of paper size, if only because
any new standards would likely seek to avoid confusion with the ISO
standards.  The JIS B series was adopted before the DIN 476 standard
was adopted as ISO 216 in 1975.  Given that it is only slightly larger
than the ISO B series, I can understand why they never made the switch.

As for "letter" it was just over 20 years ago that we had two letter sizes
over here in the States, the more commonly used size of 8.5" x 11" and
a second size that was used mainly by the government of 8" x 10.5"
until as one of the first acts of the Reagan administration, the sizes used
mainly by the government were finally phased out.
(Just think!  If they had instead switched to the ISO standard, we might
be using sane paper sizes here as well.  Certainly the ISO sizes would
be more commonplace in the States than they currently are.)

> > If the module goes beyond just A4 and letter, I am of the firm opinion
> > that the B sizes should be included as well, and that means that
> > a prefix is needed to indicate whether iso-b4 or jis-b4 is intended.
> We do not currently support the JIS paper sizes, but if they are widely
> used we would be happy to add iso-b* and jis-b* keywords.

Given your product's current lack of support of East Asian scripts
(according to your website) I can understand the lack of JIS paper
support.  I wish I knew more about the paper sizes used in China
and Japan.  What information I have been able to find suggests
that they have some non-ISO sizes that are in common use there,
(probably at least as common as 11" x 17 " is here in the States)
but nothing to indicate how common.

Received on Friday, 23 January 2004 22:24:40 UTC