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

> [Original Message]
> From: Christoph Päper <christoph.paeper@tu-clausthal.de>
>
>
> *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.

That's in part beacuse you come from a sensible part of the world
that uses the ISO sizes.  Over here in North America, most people would
have no problem understanding what was meant by letter size paper
(altho they might not know from memory the dimensions)  They'd likely
have to be told the first time that "na" stood for North America.
It's no worse that having to tell people that

vertical-align:center;

isn't valid.  Anyone who will be using this will be likely be referring to
some
form of documentation.  (Not necessarily the official standard, it could
be the The Idiot's Guide to CSS 3, for all I care.)  The people who try to
use
this without using any sort of documentation, are also going to be the
same people who will try to use any of:

size: legal;
size: dl;
size: envelope;

etc.

You can't make CSS idiot proof.

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

Well, I can't see any benefit in mixing units for paper sizes since
either they'll both be mm or both be in.

As for x being misused, I presume that IEEE had as one of its design goals
that the keywords would all fit in the ISO 646 invariant set (or at least
within
the ISO 646 IRV aka ASCII)

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

Yup, half of na_letter aka Canadian P4 (215mm x 280mm).
 Not really available, but it is the logical size for doing 2-up printing
on "na-letter" and unlike you Europeans who have it easy with those ISO
paper sizes that all have the same aspect ratio, if you want to support
2-up (or 8-up printing) you can't just scale the document and rotate
over here in North America.  Still, I wouldn't mind not having that keyword,
as 2-up printing probably won't be that common either.

The three sizes that are commonly available are letter, legal, and ledger.
You can get A4 over here on this side of the Atlantic without too much
difficulty, altho it typically is slightly more expensive than letter sized
paper, even taking into account the fact that A4 is slightly larger as well.
Other ISO sizes require more work to acquire, but it can be done.

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

Only if you assume that the list will never be expanded to include
other page sizes that share the same <sizename> part.
I am not in favor of making that assumption.

There are also two different c5's and two different f's in the IEEE-PWG
standard.

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

Well, as far as case sensitivity is concerned, the IEEE standard is case
insensitive, just like CSS keywords so both standards treat "iso_a4"
 "ISO_A4", and "iso_A4" as all being identical.  All that clause does is
give standards that are case sensitive the freedom to pick a case
as might be the case if we were discussing an XSL version of the
Paged Media Module.

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

True, and I wouldn't raise a fuss if the underscore were replaced by the
hyphen-minus.  I also wouldn't mind the underscore remaining either.

> [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'.

While that might work for all existing CSS keywords, it certainly wouldn't
work for the IEEE keywords (if underscore were replaced by hyphen-minus)
because of the significance of the separating character between the end
of a <size-name> that ends in a digit and the dimension part of a self-
describing media name.

Received on Tuesday, 20 January 2004 14:35:32 UTC