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: David Vest <davve@opera.com>
Date: Tue, 16 Jun 2015 09:53:49 +0200
Message-ID: <CAHsiBXtk_TvprSBVn8beRo0XNVoUTb74UE4d9Og0rVkVU2z2Vw@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Florian Rivoal <florian@rivoal.net>, Dean Jackson <dino@apple.com>, www-style list <www-style@w3.org>
On Mon, Jun 15, 2015 at 9:49 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>
>> On Jun 15, 2015, at 4:51 AM, David Vest <davve@opera.com> wrote:
>>
>> When looking into the Blink bug related to this
>> https://code.google.com/p/chromium/issues/detail?id=492485 I wrote
>> https://docs.google.com/document/d/1OcebuhY45_RdLUCxXu1yKPYL3u4Pf1yrERqfbGNJwzE/edit?usp=sharing
>> essentially ending up with favoring not drawing anything in the case
>> when there is no intrinsic dimensions at all. WDYT?
>
> I think the diagram that follows "we end up with a case like this" is incorrect. If the border image area is used as the default object size, then the bounding box dimensions of the svg should be stretched to be contained within the border image area, without distorting its intrinsic aspect ratio (which your example does seem to have).

Thanks for the feedback but first, what do you mean by "bounding box
dimensions of the svg" and what effect should that have in this case?
And second, this was supposed to be the case where there was no
intrinsic (aspect) ratio, as postulated in a paragraph above by "But
if there is no intrinsic size or ratio, ...". Do something in the
graphics hint otherwise?

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.

David
Received on Tuesday, 16 June 2015 07:54:21 UTC

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