Re: Coordinate spaces in SVG and CSS

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

What you're doing in the sub-steps of step 2, is trying to define
how to resolve auto-sizing. Auto-sizing is merely one branch of
sizing, and IIRC it does differ between background images and
list style images. It would be much better, I think, for you to
focus this section on the negotiation between the object and CSS
model, and leave the details of how CSS does its calculations to
elsewhere.

If you want to define a generic auto-sizing function in the draft,
I suggest extracting it out from this particular list.

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

Here's a rough draft of a terminology rewrite that might help.
You'll need to add "object view box".

<h2 id="sizing-objects">Sizing Images and Replaced Content</h2>

<p>Images and replaced content in CSS can offer many types of sizing
information to CSS, or none at all. This section defines generically
the size negotiation model between the image or replaced content
object and the CSS layout algorithms. First, the following terms are
defined:</p>

<dl>
   <dt><dfn>intrinsic dimensions</dfn></dt>
   <dd>The intrinsic dimensions are defined are the object's preferred,
     natural size or aspect ratio, if any. There can be an <dfn>intrinsic
     height</dfn> and <dfn>intrinsic width</dfn>, defining a definite
     rectangle. (Most bitmap images fall into this category.) There can
     be an <dfn>intrinsic aspect ratio</dfn> defining the relation of the
     width to the height, but no definite size. (SVG images designed to
     scale may fall into this category.) There can be just an intrinsic
     height or width. Or there can be no intrinsic dimensions at all,
     implying that the object has no preferred size or aspect ratio.
     (Embedded documents are often assumed to have no intrinsic size.)

     If an object (such as an icon) has multiple sizes, then the largest
     size is used. If it has multiple aspect ratios of that size (or of
     no size), then the aspect ratio closest to the aspect ratio of the
     default image sizing area is use <span class="issue">This is pretty
     arbitrary</span>.</dd>
   <dt><dfn>specified size</dfn></dt>
   <dd>The specified size of an object is given by CSS. The specified
     size can be a definite width and height, a set of constraints, or
     a combination thereof.
   <dt><dfn>CSS view box</dfn></dt>
   <dd>The CSS view box is the result of transforming the intrinsic
     dimensions into a concrete size using the specified size and the
     layout rules in CSS.  A CSS view box always has a definite height
     and width.</dd>
   <dt><dfn>default object sizing area</dfn></dt>
   <dd>The default object sizing area is a rectangle with a definite
     height and width that is used to resolve the CSS View box when
     dimensions are missing from both the specified dimensions and
     the intrinsic dimensions.</dd>
</dl>

I outlined the negotiation model here (bottom):
   http://lists.w3.org/Archives/Public/www-style/2010Feb/0164.html
What we probably want is to merge that with what you have in the
draft.

I can't seem to find our emails discussing the object view box /
bounding box / viewport issue...

~fantasai

Received on Tuesday, 27 April 2010 23:54:30 UTC