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: Wed, 17 Jun 2015 22:03:49 +0200
Message-ID: <CAHsiBXu+VGb7_5m7nBYaVAN7-mm6kwWpxrcs3D3k7Eymqui8og@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 Wed, Jun 17, 2015 at 6:02 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> On Jun 17, 2015, at 12:02 AM, David Vest <davve@opera.com> wrote:
>>
>> It doesn't suggest doing it by default until we hypothetically
>> introduce new top-level element for SVG though (see issue 6). Probably
>> because of compatibility reasons but there may be other details here.
>>
>>>> and what effect should that have in this case?
>>>
>>> This would mean that in your examples:
>>>
>>> #1) intrinsic size=100x100 based on green rect, therefore ratio=1:1
>>> #2) no intrinsic size or ratio, fills border image area
>>> #3) intrinsic size=100x100 based on viewbox (or based on green rect, if using viewbox that way is somehow illegal), ratio=1:1
>>> #4) intrinsic size=100x100, therefore ratio=1:1
>>> #5) no intrinsic size or ratio, fills border image area. This gives it a concrete size of 200px in both dimensions, so the slices are 33% of that (66px) all the way around.
>>
>> I we had such a fallback it would be another matter I agree. But we
>> don't, AFAICT.
>
> What harm does it do to allow this, at least in regard to to how SVG images are consumed by CSS? Clearly no one is depending on existing weird rendering of some of these cases in border-image, and probably not in 'list-style-image' or 'content' or 'background-image' either.

I can't really comment on this. Perhaps someone else who has looked
into it can chime in.

> In any case, I think my original point stands about the incorrectness of your statement (in the google docs thing you published) that "this basically means what the image draws has no relation to the image slices." The rendering that follows that statement does not seem to follow the default sizing algorithm. If there is no intrinsic size or ratio, it's size should be "resolved as a contain constraint against the default object size" (last line off the algorithm in 5.3.1). That means that if there is no ratio either, then the object should be the same size as the border image area.
>
> Not having an intrinsic size or ratio doesn't mean you don't know where or how big to draw the image. If such an image is drawn by itself, and has contents that are 100% x 100% it fills up the window. For border-image, it should similarly fill up the border image area.
>
> Even if not 100% x 100% in the contents, it should do the same thing to the base "svg" element, because that is what is supposed to happen in CSS when the image has no intrinsic size or ratio. The contents wouldn't resize if they have fixed height and weight (assuming for the sake of this argument that SVG won't let you derive size and ratio from the contents). But it should be at though the was a height="100%" and width="100%" on the base "svg" element, since that is the effect of the default sizing algorithm. It's not useful for a lot of images to be used in border-image, perhaps, but it does give you a concrete size.
>
> With the concrete size, you can then compute percentage-based border-image-slice too.
>
> Is there something in css3-image or backgrounds that needs to be more clear about this?

The problem isn't that the specs are silent or even unclear on the
matter. What you write is basically what WebKit did until recently and
what Blink still does. The problem seems to be that the results are
sometimes nonsense. In that document I tried to describe a case hard
to make sense of, not what the spec says (my goal was so try
understanding WebKit's patch)

I boiled it down to:

https://doomdavve.github.io/gists/svg-in-border-image-3.html

It shows the same SVG in the same border-image in three size scenarios.

Chrome/Blink does what the spec says and what you write above, AFAICT,
and the result isn't very useful (do you agree?). Since the size of
the border image area (== image size) changes, the slices are placed
differently on the unchanging SVG image contents. It requires an
narrow goldilocks border image size and border width to be a border
image at all, which kind of make border image pointless in this case.
My initial suggestion was to not render this case. Since then I
realized it would could make sense if the SVG used percentage
coordinates, so then I'm kind of back to status quo. Maybe what we
already have in the spec is the best we can do. But we're far from
agreeing on that since one engine (WebKit) just switched away from it,
and one other (Firefox) has never(?) implemented it.

For extra fun, try the example in WebKit nightly and Firefox. I don't
think one rendering is equal to one other rendering, but WebKit and
Firefox do resemble each other.

https://doomdavve.github.io/screenshots/border-image-differences.png

All that said, you wrote _percentage-based border-image-slice_, and I
used a numeric one. Would a percentage-based border-image-slice make
more sense?

https://doomdavve.github.io/gists/svg-in-border-image-4.html (only
change is 20 -> 20% in border-image-slice)

In this case the slices moves uniformly for different sizes and
doesn't cause the weird scaling effects, but I'm not sure how useful
it is as a border image.

David
Received on Wednesday, 17 June 2015 20:04:18 UTC

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