W3C home > Mailing lists > Public > www-svg@w3.org > September 2012

Re: svg2: Add CSS gradient as paint server for 'fill' and 'stroke'. Fixed...

From: Dirk Schulze <dschulze@adobe.com>
Date: Tue, 4 Sep 2012 11:10:18 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: SVG Working Group repository <cam@mcc.id.au>, www-svg <www-svg@w3.org>
Message-ID: <C41B4984-C664-44E5-8D28-0EF9D22B7634@adobe.com>

On Sep 4, 2012, at 10:18 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Sep 4, 2012 at 10:08 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On Sep 4, 2012, at 10:02 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Tue, Sep 4, 2012 at 9:23 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>>> Sadly you did not call in. The concerns were not the support of CSS. The main concerns were if an <image> does not fit in the boundaries of an element. What should happen? Do we repeat? Do we just repeat horizontal? Vertical? Do we stretch? Note that we don't have the same control as background has on full and stroke. This needs to be clarified first. The usage of <gradient> at the beginning was less controversial and interacts like a paint server in SVG which is not necessarily the case for the other image types.
>>> Note that there is *literally zero difference* between <gradient> and
>>> the more general <image> in these questions.  Limiting to just
>>> <gradient> for now saves you zero work, and just makes things less
>>> convenient for authors.
>> I gave you the exact problems for <image>. Can you point out where you see the problems for <gradient>? I might have missed some points, but currently I don't see the comparison of <gradient> to the other <image> types.
> I just said.  Every question you bring up, applies *exactly* to
> <gradient>.  If you think they don't, you don't understand how CSS
> gradients work. :/
> A <gradient> needs a gradient box to draw in (in CSS, it uses the
> concrete object size; in general, it should be the size of the
> painting area).  It fills said box.  If the box itself isn't as large
> as the painting area, the gradient doesn't stretch or repeat - it's
> drawn once, into the size provided, and that's it.
I would not expect the gradient to draw multiple times :P. However, I agree that a gradient needs a specific size / box to fill. At least as it is defined for CSS3 Images. And actually it isn't very different to what we do with SVG Gradients. For SVG Gradients we have the object bounding box and the view port. You can decide which one you choose with the 'gradientUnits' attribute. All values are resolved against one of these boxes. We need to decide which box applies to CSS gradients (gradient box).

I see your concern of the painting area. On reading CSS3 Images, you can get the impression that the gradient box is equal to the painting area.  This makes sense for the box layout of HTML elements. For SVG shapes it makes no sense to clip gradients to the edges of the gradient box. There is no limitation on the implementation side that would explain this wording. In fact, the gradient box should just be used to solve the sizing of the gradient parameters. If this needs to be stated in the SVG2 specification, I'll do the changes. However, this is just relevant if we decide to use the object's bounding box as gradient box (which I would prefer) instead of just the view port. However, gradient box will definitely differ from the "affected painting area" if we chose object bounding box.

> The only additional issue that some <image> subtypes have is that they
> may have an intrinsic size different from the size of the painting
> area.  In my response (which was below the part you quoted, so I've
> trimmed it out), I stated how to resolve that - it just depends on
> whether the "painting area" is similar to 'background-size' or the
> "background positioning area".  If the former, the image is stretch to
> fill it.  If the latter, it just paints at its intrinsic size in the
> top-left corner.  This is the sole question that is different between
> <gradient> and general <image>s, and is just because <gradient> has no
> intrinsic size (like an <svg> without 'width', 'height', or
> 'viewBox').
Since we don't have a background size, nor a background positioning area, this seems to be more confusing. What is the reference for top left on a arbitrary shape? I would assume the bounding box can help. This would lead to problems on using <image> as paint server for strokes. On an rectangle, the stroke would always be clipped to the bounding box of the object. Furthermore, is it really desirable to have top left on the 'background-size' case?

This is for sure different to <gradient>, as long as you don't either clip the gradient to the gradient box, or define the gradient box to something different as the object bounding box / view port. I would rather use what is more native in the SVG context as described before.

> ~TJ
Received on Tuesday, 4 September 2012 18:11:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:37 UTC