W3C home > Mailing lists > Public > www-style@w3.org > September 2006

Re: Sizing

From: Axel Dahmen <brille1@hotmail.com>
Date: Fri, 22 Sep 2006 15:28:27 +0200
To: www-style@w3.org
Message-ID: <ef0ofj$dgu$1@sea.gmane.org>

Hi Bert,

wouldn't the "resolution" and "scaling" properties proposed below be more
versatile?

With the "scaling" property authors would be able to zoom complete portions
of a document, not only images.

The "resolution" properties would commonly be used on the document, not only
on images. It's a rendering property.

The "image-resolution" property would be interesting on images to override
their native resolution or to provide a resolution to files not providing a
native resolution. When it comes to zooming images, however, the "scaling"
property seems more intuitive to me.

Axel Dahmen
www.dashop.de


--
a) "resolution"

Provides absolute information about device resolution. Separate values for x
and y axis are possible.

    e.g.:
      -----------
      body
        {resolution: "300pt";
        }
      -----------
      body
        {resolution: "300pt" "600px";
        }

  Possible sub properties: "x-resolution", "y-resolution".

  Possible values: length values, "auto".


b) "scaling"

Provides relative scaling information used to scale up or down portions of a
document.

    e.g.:
      -----------
      body
        {scaling: "50%";
        }
      -----------
      p
        {scaling: "75%";        }

  Possible values: percentage values. "100%" is default.


------------
"Bert Bos" <bert@w3.org> schrieb im Newsbeitrag
news:200609182025.36973.bert@w3.org...
>
> On Sunday 17 September 2006 13:07, Axel Dahmen wrote:
> > I see a lack in the CSS specification regarding size which I believe
> > should be discussed for CSS3:
> >
> >
> > <- a ->
> > Absolute sizes of generated content are defined as the generated
> > content's size itself whereas relative sizes are interpreted as being
> > relative to the containing block's calculated size. With the current
> > specification it's not possible to scale images in DHTML by applying
> > CSS attributes (given you don't/can't use DOM properties to retrieve
> > the original size of generated content).
> >
> > A new rule should be introduced for generated content to determine
> > relative sizes as being relative to the generated content's intrinsic
> > size.
>
> There are two proposals under consideration by the CSS working group:
>
> 1) 'image-resolution'
>
> This applies to replaced elements that have a resolution, i.e., to
> raster images. (It would thus also apply to generated content, if it
> happens to be a raster image.) The syntax isn't certain yet, but here
> is an example:
>
> 'Image-resolution: normal' (the default) means to use 1 image pixel =
> 1px.
>
> 'Image-resolution: auto' means to use the intrinsic resolution as given
> by meta-data inside the image file, or use 'normal' if there isn't any.
>
> 'Image-resolution: <number>' means to display the image at <number> dpi.
>
> 'Image-resolution: <length>' means to use that length for the size of
> image pixels. (In other words: 'normal' means the same as '1px' and
> '200' means the same as '0.005in'.)
>
> You can also give two numbers, in case the pixels aren't square.
>
> It's an open question how this applies to background images.
>
> It's also an open question if 'auto' needs a user-specified fallback:
> 'image-resolution: auto' falls back to 'normal', while
> 'image-resolution: auto, 300' would fall back to 300 dpi.
>
> There is support for this property in the WG and I expect it to be
> further developed. The typical use case is actually not to set a
> specific resolution, but to express trust in the intrinsic resolution
> of certain images ('image-resolution: auto'), because browsers by
> default don't trust it (that's why 'image-resolution: normal' is the
> default).
>
>
> 2) 'width: <number>' (and 'height: number')
>
> This applies to block-level elements and replaced elements.
>
> If the element has an intrinsic width, use <number> times the intrinsic
> width as its width. If it doesn't, the effect is the same as 'width:
> auto'.
>
> This hasn't been discussed much yet. There are obviously
> interdependencies with 'image-resolution' and with 'crop'.
>
>
> An author presumably knows both the size and the resolution of his
> (raster) images, so he could use 'width' instead of 'image-resolution',
> but setting 'image-resolution: auto' once for the whole document may be
> easier, especially if you want to write the style sheet before creating
> the images.
>
> >
> >
> > <- b ->
> > There is no way to scale a document, e.g. for printing.
> >
> > What is rendered on screen always varies depending on the screen
> > resolution. Units like "pt" are never displayed in their correct
> > sizes. Similar for printing: "px" unit rules are never printed in the
> > printer's resolution.
>
> "Never" isn't true. My browser uses the dpi of the display as reported
> by the operating system: 98 dpi in my case (while measuring with a
> ruler shows that it is actually 99), so 'pt' displays pretty much
> correct.
>
> I also tried printing with various browsers and other formatters. They
> all printed 'pt' quite well. I found one that was 3% off, but others
> that were 0% or 0.5% off according to my ruler.
>
> And I tried printing 'px' (on recent office-class laserprinters). I
> found one browser that used about 1/72 inch, but the other products
> used values between 1/96 and 1/99 inch. That's a bit too big a 'px' for
> my taste, but it is acceptable. Laserprinters of this type don't round
> values to whole dots (they can effectively print details at 1200 dpi or
> so by varying the size of the dots), so there is no need that a px is a
> multiple of the nominal resolution. Lines won't look any sharper.
>
>
>
> Bert
> --
>   Bert Bos                                ( W 3 C ) http://www.w3.org/
>   http://www.w3.org/people/bos                               W3C/ERCIM
>   bert@w3.org                             2004 Rt des Lucioles / BP 93
>   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
>
>
Received on Friday, 22 September 2006 13:30:17 GMT

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