W3C home > Mailing lists > Public > www-style@w3.org > June 2015

Re: [css-backgrounds] border-image with an SVG resource that has no intrinsic size

From: Dean Jackson <dino@apple.com>
Date: Wed, 17 Jun 2015 08:32:38 +1000
Cc: Brad Kemper <brad.kemper@gmail.com>, Florian Rivoal <florian@rivoal.net>, www-style list <www-style@w3.org>
Message-Id: <28A3AD45-CA71-42E7-92FF-A588A6AF953E@apple.com>
To: David Vest <davve@opera.com>
At this point I suggest someone (other than me :) should volunteer to specify all this in a document somewhere. There are a lot of edge cases. Then we can implement it and see how we feel. I guess CSS backgrounds is the right place.

Dean

> On 16 Jun 2015, at 9:58 pm, David Vest <davve@opera.com> wrote:
> 
> On Tue, Jun 16, 2015 at 9:53 AM, David Vest <davve@opera.com> wrote:
>> On Mon, Jun 15, 2015 at 9:49 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> The problem I was getting at was that if we have an SVG that's not
>> scalable (no intrinsic aspect ratio) and the "image size" becomes the
>> border image area, the placement of the slices will have no connection
>> to the actual image. What would be eventually draw is therefore
>> nonsensical and I propose we disallow this case and draw nothing
>> instead.
> 
> I realized there actually are ways (of course!) to make an SVG having
> no intrinsic dimensions but still scale to the destination: percentage
> based lengths. It's now (2) at:
> 
> http://doomdavve.github.io/gists/svg-in-border-image-1.html
> 
> Firefox especially shows the difference between (2) and (3). In (2)
> there is no intrinsic ratio, so the image is just scaled to the
> destination. In (3) there is and it leaves blank space instead. Can't
> say I think the result is any good though.
> 
> Now, I'm leaning towards actually doing what the spec says and divide
> the border image area with slices and all and just assume the SVG can
> handle it. Because there is a possibility it may. Thoughts?
> 
> David
Received on Tuesday, 16 June 2015 22:33:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC