Re: Coordinate spaces in SVG and CSS

On Tue, Apr 27, 2010 at 3:53 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 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.

Valid criticism.  So I'll address replaced elements too, then.


>>>> 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.

Argh, you're right.  I don't know *what* I was thinking before.


> 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".

Yes, indeed.  And we want to do this sizing before asking the image to
draw itself, so vector images and other size-agnostic formats can give
us an accurate bag of pixels.

So, it appears that background-size and image-fit function in
precisely the same way.  The only difference is the default values -
for background-images, it acts like a "none" fit by default (use the
image's intrinsic dimensions), while replaced elements have a
"contain" fit by default (use the box's dimensions).  This is
specified in the definitions of background-size and image-fit, though,
so I shouldn't need to say anything about it explicitly, just put in a
note stating that the property in question will define how the fit
works.

So I need to rephrase all of step 2 slightly, particularly step 2.1.
Let me think on this a bit.


>>> 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.

Right you are.  I am indeed slicing the abstraction wrongly.  I'll
shake up the terms a bit and rewrite the section.

~TJ

Received on Tuesday, 27 April 2010 23:21:49 UTC