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

Re: Sizing

From: Mike Bremford <mike-css@bfo.co.uk>
Date: Tue, 19 Sep 2006 10:28:15 +0100
Message-Id: <D34DAE02-3280-4C58-B311-8B70AA24F26C@bfo.co.uk>
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 GMT

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