Re: Coordinate spaces in SVG and CSS

On Thu, Mar 25, 2010 at 2:55 AM, Erik Dahlstrom <ed@opera.com> wrote:
> On Thu, 25 Mar 2010 01:00:19 +0100, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>> I'm trying to spec background-repeat:extend in the CSS3 Images module.
>>  This new value is essentially designed for gradients, but has
>> potential application to SVG as well, and I'd like some collaboration
>> on the best way to talk about this to retain working compat between
>> SVG's concepts and the new ones I'll be writing.
>>
>> First, some background.  A CSS gradient is a new value for the <image>
>> production in CSS.  Gradients, by their nature, paint themselves on an
>> infinite canvas, just like a solid color does.  However, when used in
>> CSS, such as in a background-image rule, the gradient is then clipped
>> to the size of the box.  This clipped image can then be manipulated
>> via background-size, background-position, etc.  (That is, given a rule
>> like "background: -moz-linear-gradient(left, yellow, blue) gray 50px
>> center no-repeat;", you can clearly see that the gradient is clipped
>> to a rectangular region and shifted by 50px to the right, revealing a
>> stripe of background-color underneath it.)  However, I am adding the
>> 'extend' value to background-repeat which changes this behavior, and
>> stops the clipping.  (In the example given, if
>> background-repeat:extend; was specified, you wouldn't see any gray;
>> the yellow that started the gradient would continue to extend
>> leftwards, filling that 50px stripe.)
>
> How would background-repeat:extend affect a raster image?
>
>> I'd like to define all of this in a generic way that can be hooked
>> into by later additions, and by SVG.  Fantasai brought up that this
>> could be useful to allow an SVG image to 'overflow' its
>> viewbox(viewport?).
>
> Before the raster image question has been answered it's hard to answer how
> this could/should apply to svg.

A raster image has a natural 'bounding box' (the term I'm using for
now to refer to the box concept I'm trying to define) equal to its
size.  It doesn't have any data theoretically extending outside of
that box, so background-repeat:extend does nothing; it's functionally
equivalent to background-repeat:no-repeat.

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

~TJ

Received on Thursday, 25 March 2010 15:40:18 UTC