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

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

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Fri, 23 Jan 2004 20:39:32 -0800
To: Michael Day <mikeday@yeslogic.com>, Ernest Cline <ernestcline@mindspring.com>
Cc: <www-style@w3.org>
Message-ID: <BC37366B.34BA3%tantek@cs.stanford.edu>

On 1/23/04 6:52 PM, "Michael Day" <mikeday@yeslogic.com> 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
users.

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

 -yl-a4

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

Regards,

Tantek
Received on Friday, 23 January 2004 23:40:16 GMT

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