Re: Sizing

Is there a path forward on this discussion? I see a need for the proposed
properties and I guess there ought to be a solution at the end.

Axel Dahmen


------------
"Axel Dahmen" <brille1@hotmail.com> schrieb im Newsbeitrag
news: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 Tuesday, 26 September 2006 13:43:16 UTC