- From: Axel Dahmen <brille1@hotmail.com>
- Date: Tue, 26 Sep 2006 15:38:33 +0200
- To: www-style@w3.org
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