Re: Coordinate spaces in SVG and CSS

On 04/27/2010 03:24 PM, Tab Atkins Jr. wrote:
>
> Ah, k, so the issue is that you're referring to images like in<img>,
> when I'm referring to *just* background-image and list-style-image.
> You are correct that I have to do more to make it apply to the sizing
> of replaced elements.
>
>...
>
> Me reading that section is not the issue; I simply am currently
> purposely not addressing the cases where that chapter is relevant.

The section's titled "Sizing of Images" and states "The general
treatment of images in CSS is as follows"... If you're purpose
isn't to address those cases, then that text is very misleading.

>>> I see what you mean about specified vs intrinsic sizes, though.  I was
>>> writing this in the context of background-image and list-style-image,
>>> where intrinsic sizes *do* win.  Given the context of the Images
>>> module, which is about the<image>    value, this should still be
>>> correct.
>>
>> No, they don't win. You can specify the size of the background image
>> with background-size, and that wins over the intrinsic size. Also,
>> the 'content' property can create a replaced element.
>
> background-size and background-origin are explicitly called out as
> affecting the size of the "default image sizing area".

Like 'width' and 'height', and for exactly the same reasons,
'background-size' needs to be handled in step 2 as well. It
cannot be folded into the "default image sizing area" definition.

And again, even with background images, the specified size overrides
the intrinsic size. 'background-size' is giving a specified size.
'background-origin' is what's giving a "default image sizing area".

>> On another terminology note, you're defining "object view box" as
>> synonymous with "intrinsic dimensions". We don't need another term
>> meaning "intrinsic dimensions". The concept without a term was the
>> bounding box of the image--the thing that's usually synonymous with
>> its viewport. The reason it was needed was so that we could
>> disassociate it from the clipping behavior of having a viewport.
>
> I think that's covered by the CSS View Box, right?  I can change the
> text in step 3/4 to make it more explicit that clipping is not
> automatic, and the image may spill out of the View Box, and CSS will
> take care of the clipping if necessary later down the painting
> pipeline.

No, not really. The bounding box of the image does not necessarily
coincide with the CSS View Box. For example, an SVG image's bounding
box doesn't match the CSS View Box when the aspect ratios don't match
and SVG's preserveAspectRation attribute is set to meet or slice.

~fantasai

Received on Tuesday, 27 April 2010 22:53:55 UTC