- From: Mike Bremford <mike-css@bfo.co.uk>
- Date: Tue, 19 Sep 2006 10:28:15 +0100
- To: www-style@w3.org
I like "image-resolution" - it's definitely needed for bitmap images destined for printing. It's no use for other replaced elements with an intrinsic width, but I'm not sure that's too important - other replaced items I can think of (flash, svg, applets etc.) are vector or layout based and therefore "stretchy" A fallback to "normal" would probably do it I would have thought - "auto" implies you're expecting the image to have a resolution internally, and won't be used lightly - you're putting your faith in the image creator not to specify something like 1dpi and have the image occupy the whole page (I've seen this done). If I wasn't sure the image had a useful resolution then personally I'd be inclined to always override it with a numeric value if I wanted one. Coupled with max-width and min-width this is pretty intuitive to use - unlike the second proposal there I think. "width" is overloaded enough as it is, and as the majority of CSS users haven't read the spec and tend to slap "width" on every element they can find they would, I suggest, find this implemention slightly confusing. I'd also suggest a "background-image-resolution". It's only one more attribute... Cheers... Mike On 18 Sep 2006, at 19:25, Bert Bos wrote: > > 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, 19 September 2006 09:28:40 UTC