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

*Ernest Cline*:
>> From: Bjoern Hoehrmann <derhoermi@gmx.net>
>>
>> If the page dimensions can be inferred from the keyword that
>> would not be a problem, but then I don't get the point of using
>>
>>   size: na_letter_8.5x11in;
>>
>> (a keyword I would probably have to look up first) instead of
>>
>>   size: 8.5in 11in;

Exactly. Some people probably know the exact dimensions of A4, but none of the
other ISO sizes. I don't know about users of Letter etc. A few years ago I
myself hadn't even realized that virtually the whole world uses our DIN sizes.
Today I'm worried about that "virtually".

>> As an author, what's my benefit if this is added to css3-page?
>
> Well first off, you should be able to use just
>
> size: na_letter ;

I don't know one person IRL who'd knew what that meant. At best (or worst)
they'd wonder what "not available letter" has to do with a property named
'size', not even knowing whether 'letter' means a piece of mail or a character
from some alphabet.

> size: us_letter_8.5x11in;
>
> as referring to 8.5" x 11" paper.

The Media Size Self-Describing Name Format as described by IEEE-ISTO
5101.1-2002 is in my view clearly inferior to the alternate CSS way, which
would consist of two rules, the first with the explicit dimensions written
like CSS parsers would expect, the second one being literal:

  size: 8.5in 11in;
  size: us-letter;

Of course this is overly informative.
CSS also doesn't require to misuse the letter x as an multiplication sign (we
have × and · for that) and it has every number directly assigned to a
dimension, allowing to mix such (in theory).

> The main one advantage this gives an author is that it uses  a standard
> way of referring to page sizes so that if you are also dealing with other
> types of documents than CSS stylesheets, then if they also
> follow that standard, you would only have to refer to one standard.

That's a benefit to just very few people, especially given the
machine-centered aim of that IEEE spec. It's not worth it.

> I will admit that given the sheer number of keywords (165 different
> standard paper sizes in that standard if I counted correctly) it would
> be unwieldy to require that all 165 short names (without the dimensions)
> be supported by all UA's.

I agree, although the sizes of the basic ISO series can be calculated by an
algorithm without a lookup table. JIS B too.

> What follows is what I feel to be a likely maximum minimum:
>
> na_invoice (5.5" x 8.5")

I've never heard of that one, but then I'm not from the USA nor Canada. From
the sizes it looks like P5 from CAN 2-9.60M (140mm × 215mm).

> na_letter (8.5" x 11")
> na_legal (8.5" x 14")
> na_ledger (11" x 17")
>
> iso_a5 (148mm x 210mm)
> iso_b5 (176mm x 250mm)
> iso_a4 (210mm x 297mm)
> iso_b4 (250mm x 353mm)
> iso_a3 (297mm x 420 mm)

With these only, there's absolutely no need for the prefix. There's not much
use for it with the full set either, except that JIS B has to be distinguished
from ISO B.

> As it is, with these nine I probably have overkill for general use,

I've already printed to all A sizes from 2 to 6 and some of the B and C sizes
in that range, but anyhow never a webpage.

> In any event, as I have said, if the decision is made to only
> support a few keywords instead of the full IEEE PWG
> standard for  paper sizes, I strongly want the keywords
> chosen to conform with the <class-name> "_" <size-name>
> format so that if it should be decided in a future version
> of the Paged Media Module to support this standard
> there would not be any legacy keywords that don't follow
> that form that would have to be supported as well.

Although being uncertain about named paper sizes in general, I strongly oppose
the underscore and general lowercase like you and the IEEE-PWG suggest. All
current CSS properties and values use the hyphen-minus instead[1] and are
case-insensitive (I certainly prefer 'A4').

A differing habit from an external standard should not be adopted unchanged,
IMO. Furthermore the pwg5101.1.pdf, referenced earlier in this thread, says in
chapter 6 "Conformance Requirements":

| Other referencing standards may impose case sensitive rules if necessary.

and

| It is also acceptable to replace the underscore separator between
| the "class" and "size-name" with a hyphen.

[1] A while ago I even requested to treat literal properties and values the
same with removed hyphens, i.e. 'pre-wrap' == 'prewrap' == 'p-r-e-w-r-a-p'.

Received on Tuesday, 20 January 2004 03:42:04 UTC