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

On 1/23/04 6:52 PM, "Michael Day" <> wrote:

> Hi Ernest,
>> 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
>> certainly an obvious choice to consider, but for the reasons I have
>> already given, I don't think that it is the best choice.
> It is not that *I* think that it is obvious, it is that A4 paper is
> commonly referred to as such by the wider user community. It is marketed
> and sold as being "A4 paper" and printers and photocopiers offer "A4"
> paper trays and folders are sold as "A4 folders" for holding A4 paper and
> so on and so on. The ISO acronym never comes up outside of forums devoted
> to standardisation such as this one.
> Allowing the ISO prefix is fine and consistent. But *requiring* it is
> unnecessary, redundant, pedantic and confusing for ordinary users.

I agree with this sentence 100%.  Too often it seems standards committees
add extra codeJunk to technologies for some sort of theoretical fear without
considering the practical inconvenience multiplied thousand/million-fold for

>> Had you followed the recommendation in this case it would have been:
>> @page {size: -yeslogic-a4 }
> One look at this monstrosity makes it pretty obvious why we did not
> implement it this way.

Nothing says you have to use your fullname.  You could have used


or even:

 -y-a4  (no one is using the -y- prefix yet AFAIK, and Opera chose to use
-o- so why not?  and if there are eventual collisions it doesn't matter
because folks are not supposed to depend on these eventually anyway).

> Not to mention that identifiers cannot begin with a
> hyphen-minus in CSS 2, the highest level of CSS that is currently a W3C
> Recommendation (and has not been deprecated). Only the Working Draft of
> CSS 2 Revision 1 allows this syntax.

True, but if that was your concern, you could have used a y-

And thanks for the reminder that the CSS WG needs to hurry up and deliver
the CSS2.1 CR so that this excuse can no longer be used :)

> If we were implementing a new property that was likely to conflict with an
> existing or future property from another vendor, then we would need to
> qualify it appropriately to avoid conflicts. But as I said before,
> qualifying "A4" in this manner is ridiculous.

Agreed, but is this good practice for an implementer of standards? (

> Similarly with the extension in the usage of the portrait and landscape
> keywords:
> @page { size: A4 landscape }
> It would be difficult to keep a straight face while documenting this:
> @page { size: -yeslogic-A4 -yeslogic-landscape }
>> (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.
> Standardisation follows implementation, not the other way around.

I am of two opinions about that.

In general I agree that standardization should follow implementation, rather
than having committees of folks (most of whom may not even have pragmatic
interests in the technologies involved) invent a bunch of theoretical stuff
that no one ends up using.

OTOH, if implementers see an area that needs development, it may make sense
for them to cooperate in a standards committee to establish a common format
rather than experimenting with different incompatible variants first, and
then later having to potentially change and have all their customers change



Received on Friday, 23 January 2004 23:40:16 UTC