W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2010

Re: Coordinate spaces in SVG and CSS

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 25 Mar 2010 13:04:55 -0700
Message-ID: <4BABC1E7.90402@inkedblade.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Erik Dahlstrom <ed@opera.com>, public-fx@w3.org
On 03/25/2010 08:39 AM, Tab Atkins Jr. wrote:
> On Thu, Mar 25, 2010 at 2:55 AM, Erik Dahlstrom<ed@opera.com>  wrote:
>
>> If we take a concrete example - an<object>  element that references some svg
>> content, then current SVG/HTML implementations don't allow overflowing the
>> <object>  viewport, but allows the SVG to overflow its viewBox if the
>> viewport has a different aspect ratio (than that of the viewBox). The
>> overflow is only visible in certain cases then.
>
> Ah, so SVG can already overflow its viewBox.  That wasn't clear to me.
>   That's very helpful.
>
> The idea here would be similar to what you just described.  The
> background-image wouldn't overflow the normal background area
> (determined by background-clip), it would just overflow the
> self-defined 'bounding box' that normally applies an early clipping to
> the image.
>
> (That is, you construct the image, clip to the image's bounding box,
> then size, position, tile, etc, and finally clip to the
> background-clip box to produce the final background.)
>
>> The CSS background case is still a bit underdefined for SVG content and
>> current implementations may differ on what happens when the area to fill has
>> a different aspectratio from the viewBox (if specified). I think it would be
>> great to get that properly defined in a spec somewhere.
>
> Yup, that's the idea.  So I believe what I'll spec is that SVG content
> (when used in a CSS background) is normally clipped to its viewBox
> (this applies for no-repeat, and obviously for repeat*).  A value of
> 'extend' would remove the viewBox clipping and let it be as large as
> it wants.
>
> So, perhaps I can call this concept the 'view box' to sync with SVG?
> I believe that properly captures the concept I'm looking for.

So, the view box the rectangle that defines the size of the image, and
the view port is the window into the image. And background-size: extend
just makes the view port infinite. I like it.

So, the model is,

   1. CSS requests the view box rectangle from the image: this is essentially
      the rectangle representing the image's intrinsic size. This rectangle
      could have a defined width and height, a defined ratio only, a
      defined width only, or a defined height only. We'll call this the
      Image View Box.
   2. CSS then sizes the view box rectangle according to its rules. We'll
      call this the CSS View Box. It always has a defined width and height.
   3. CSS gives the image the CSS View Box rectangle it's come up with,
      and asks the image to draw itself in that rectangle.
   4. The image sizes and positions itself to the CSS View Box rectangle
      it was given. This may involve rescaling its contents, but ultimately
      it's up to the image how it fills (or does not fill) the rectangle.
      (It could scale width and height independently, scale them together
      to meet or cover the rectangle edges, scale the center, but not the
      corners, seam carve, whatever.)
   5. CSS establishes viewport to which the image is clipped. This is
      typically (but not always) the same rectangle as the CSS View Box.

For replaced element formats (such as bitmap images) that do not have an
infinite canvas, the canvas is assumed to be transparent.

~fantasai
Received on Thursday, 25 March 2010 20:05:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 March 2010 20:05:27 GMT