Hello,
The Last Call period of the W3C's CSS Print Profile [1] ends on January 31,
2004. The Last Call period of the W3C CSS3 Paged Media Module [2] ends on
the same date. [2] extends the size property to accept media names, I
suggest that [1] also be extended to accept media names in the size
property.
Currently there is a brisk discussion on www-style@w3.org about media names.
Comments?
Jim Bigelow,
CSS Print Profile editor
-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
Of Ernest Cline
Sent: Monday, January 19, 2004 9:43 PM
To: Bjoern Hoehrmann
Cc: www-style@w3.org
Subject: Re: [css3-page] examples in 3.3.2 (page size) are 'US-centric'(?)
> [Original Message]
> From: Bjoern Hoehrmann <derhoermi@gmx.net>
> To: <ernestcline@mindspring.com>
> Cc: <www-style@w3.org>
> Date: 1/19/2004 5:27:11 PM
> Subject: Re: [css3-page] examples in 3.3.2 (page size) are
> 'US-centric'(?)
>
> * Ernest Cline wrote:
> >I don't get your point. W3C specs such as XHTML aren't revised
> >whenever another language is added to ISO 639 or another MIME type is
> >registered
with
> >the IETF. Rather they just reference the standard and mention where
> >one can get the latest list of registered values. Why then should
> >CSS3 Page
need
> >to be revised when the IEEE PWG accepts a new standard paper size?
>
> A CSS user agent would be expected to support new keywords out of the
> box while a Voice Browser would not be expected to support speech
> synthesis for a new language or a browser a new image format just
> because of new registered language tags or MIME types. 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;
>
> 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 ;
or if you can't remember the short name, then altho not strictly kosher, a
UA should be able to understand either:
size: custom_xyzzy_8.5x11in;
or:
size: us_letter_8.5x11in;
as referring to 8.5" x 11" paper.
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.
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. However, since there are only a few common paper
sizes, it should be practical to require a basic set of keywords (or even
restrict the list of allowed short keywords to just those
keywords.)
What follows is what I feel to be a likely maximum minimum:
na_invoice (5.5" x 8.5")
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)
For general printing, we probably don't need to have CSS support keywords
for envelope sizes, and I don't know how commonly the non-ISO paper sizes
used by China, Taiwan, or Japan that are referenced by the IEEE standard are
used with computers. As it is, with these nine I probably have overkill for
general use, as "na_letter" and "iso_a4" are certainly the two most used
sizes of computer paper. "na_invoice" and "iso_a5" are most likely to be
used when a user has chosen to print a document in a 2-up format.
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.
This archive was generated by hypermail 2b29 : Tue Jan 20 2004 - 19:51:08 EST