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

> On Jun 17, 2015, at 1:03 PM, David Vest <davve@opera.com> wrote:
> 
>> 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?).

Using Chrome 43.0.2357.124 and Safari 8.0.6, I think that looks correct, or at least pretty close (eyeballing it).

With this particular image, it isn’t very useful, but you could say the same about many combinations of raster image and border-image settings. 

By not having any intrinsic dimensions for the image, but having fixed dimensions for its contents, the image you chose is not a good candidate for use with border-image (unless we change the rules for how intrinsic sizes are found for SVGs, to take into account the content size). It is letting the image itself scale, but not its contents, and the fixed-sized contents span across the different tiles, which are not fixed size (since the border-width independently changes in your examples).

A better use case for this behavior might be an image in which the shapes used for the fill of the border-image-width regions were 100% x 100%, while other elements in the SVG remained a fixed size. The fixed size items might be a pattern that you saw more of when the HTML box was bigger, or it might be some decorative items that are mostly in one corner and trail down the two sides connected to that corner. >>>>This works best if the border-image-slice matches the size of the border-image-width (or of border-width in this case, where border-image-width is auto and there is no intrinsic size).

For instance, try these two rules with your last sample, and pay attention to how the black squares stay the same size and position, while the green and lime areas conform to the whole box shape:

.test {
 box-sizing: border-box;
 border-image-slice: 40 fill;
 border-style: solid;
 outline: 1px dotted black;
 border-image-source: url(‘data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><rect x="0" y="0" width="100%" height="100%" fill="green" stroke="lime" stroke-width="80"/><rect x="0" y="0" width="100%" height="100%" fill="none" stroke-width="40" stroke="green"/><rect x="30" y="15" width="10" height="10" fill="black"/><rect x="5" y="100" width="10" height="10" fill="black"/><rect x="15" y="150" width="10" height="10" fill="black"/></svg>'); 
}
.big {
 border-width: 40px;
 width: 500px;
 height: 300px;
}

and then play around with the dimensions of ‘.big’.

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

Hopefully my example above hints at how the case of “no instrinsic anything, with fixed-sized content” can be less pointless. The pointless part would be to have a border-image-width that ruined the effect, but that is possible with raster images too. The main shortcoming is that you can’t really make useful changes to ‘border-width’ or ‘border-image-width’ without making corresponding changes to the ‘border-image-slice’. 

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

I think it is pretty good, actually. The ability to use that power to make horrible looking test cases is not proof of its uselessness.

> 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

Well, now you are really talking about a way if rendering that is not only useless, but baffling too.

> All that said, you wrote _percentage-based border-image-slice_, and I
> used a numeric one.

That was mainly because you mentioned somewhere that the percentages couldn’t be resolved (if I understood you correctly), and I was showing that they could.

> Would a percentage-based border-image-slice make
> more sense?

Not necessarily. 

In Webkit, at least, if you have “border-image-width:10%; border-image-slice: 10% fill;” (i.e. matching percentages), it actually works out pretty well. The hour is too late for me to work out why… I expected it to be distorted.

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

Unfortunately, that only looks nice if your HTML box is a square. Try making one dimension much longer, and it isn’t so nice.

Received on Thursday, 18 June 2015 09:37:17 UTC