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

I am really confused. How do you admit that the specs are not super clear on this and the rendering is "sometimes-slightly-weird-but-okay" and then you give such a strong opinion like that?

If the specs are not super clear and the "sometimes-slightly-weird-but-okay" rendering is not defined anywhere, how can I differentiate between a bug in the implementation and an accepted and conforming rendering? If the specs are not super clear so why do not we fix it?

I think the decision to be made with the current state of the specs is the choice between:

1. Not really useful but expected results (Safari and FireFox)
2. Sometimes-slightly-weird-but-okay results (Chrome)

I think the decision should not be easy and without having clear specs and without defining what “sometimes-slightly-weird-but-okay” means, no one should claim that one choice is 100% correct and the other is 100% wrong.

Thanks,
Said


> On Aug 13, 2015, at 12:02 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> 
> On Tue, Aug 11, 2015 at 10:35 AM, Said Abou-Hallawa
> <sabouhallawa@apple.com> wrote:
>> Regarding the last point which is why the SVG image (with no intrinsic size)
>> by itself can be rendered correctly while the image-border in WebKit renders
>> all the pieces from the top-left corner, here is my explanation for why this
>> approach was chosen. Let's  consider this simple test case:
>> 
>> svg-no-intrinsic-size.svg:
>> 
>> <svg xmlns="http://www.w3.org/2000/svg" version="1.1">
>> <rect width="100" height="100" fill="lime"/>
>> <rect x="10" y="10" width="80" height="80" fill="none" stroke="black"
>> stroke-width="4px"/>
>> </svg>
>> 
>> test-case.html:
>> <!DOCTYPE HTML>
>> <head>
>> <style>
>>   .box {
>>     height: 100px;
>>     width: 100px;
>>     margin: 10px;
>>     display: inline-block;
>>     background-color: red;
>>     border: 20px solid;
>>   }
>>   .border-image-no-intrinsic {
>>      border-image: url('svg-no-intrinsic-size.svg') 0 fill;
>>   }
>>   .border-image-no-intrinsic-slice {
>>      border-image: url('svg-no-intrinsic-size.svg') 20 fill;
>>   }
>> </style>
>> </head>
>> <body>
>> <div class="box border-image-no-intrinsic"></div>
>> <div class="box border-image-no-intrinsic-slice"></div>
>> </body>
>> 
>> When loading this test case In Chrome, the first div: <div class="box
>> border-image-no-intrinsic”> draws only the fill part of the border-image.
>> But the drawing of the border-image is scaled down by some ratio which is
>> hard to be understood. But from tracing the code here is why this scaling is
>> happening.
>> 
>> This div size is (100x100) with border of 20, so the border box is (140x140)
>> According to the specs: the intrinsic size of the SVG border image should be
>> (140x140)
>> Since the border-image has fill set on but its slice is 0, the whole SVG
>> which is (140x140) has to be displayed in the content box of the div which
>> is (100x100)
>> So the SVG drawing will be scaled down by 100/140.
>> 
>> In Chrome also, the second div: <div class="box
>> border-image-no-intrinsic-slice”> draws all the nine parts of the
>> border-image. But it does not fill the whole rectangle of the <div>; it only
>> fills 100x100 out of the 140x140 pixels. Here is why this happening:
>> 
>> This div size is (100x100) with border of 20, so the border box is (140x140)
>> According to the specs: the intrinsic size of the SVG border image should be
>> (140x140)
>> Since the border-image has its slice set to 20, the drawing size is also
>> 140x140, which means no scaling is applied when drawing the image.
>> Since the SVG itself draws only 100x100 pixels and since no scaling or
>> stretching will happen,  only 100x100 of the element area will be covered by
>> the SVG image.
>> 
>> From these two cases, it was obvious to me that this problem is unsolvable.
>> The nine-piece-slicing algorithm needs to know the bonding box of the
>> drawing to draw the border-image correctly. There is no reliable way to know
>> this bounding box (at least for now). So the only way to know is to require
>> an “intrinsic size” set by the user.
>> 
>> No if the following SVG is used, the border-image will be drawn exactly as
>> expected:
>> 
>> <svg xmlns="http://www.w3.org/2000/svg" version=“1.1” width=“100”
>> height=“100">
>> <rect width="100" height="100" fill="lime"/>
>> <rect x="10" y="10" width="80" height="80" fill="none" stroke="black"
>> stroke-width="4px"/>
>> </svg>
>> 
>> The specs does cover this case clearly. Using the border box of the
>> continuing element as a replacement of the image intrinsic size, if it is
>> not provided, does not even give predictable results for simple cases.
>> 
>> I disagree that this was horrible change in WebKit. I understand it is not
>> the ultimate solution and might not be the expected behavior. But my aim in
>> choosing this approach was two things: (1) Solve this problem with the most
>> straightforward solution so we get predictable and easy to explain results.
>> (2) Make strong emphasis to the users that border-image has to have
>> intrinsic size since we can’t guess its bounding drawing box.
> 
> No, this is absolutely a terrible behavior currently.  What WK is
> currently doing cannot be interpreted as anything other than "this is
> an error, doing minimal recovery to figure out something renderable".
> There's no possible way to defend it as actually desirable.
> 
> The specs aren't super-clear on this, but the behavior in practice is
> clear - in the absence of any other information, the SVG's viewport is
> set so that its px is the same as the page's px.  You then render
> appropriately given that information - in the example given, the lime
> square is 100px wide in the page's coordinate system.  You can see
> this if you use it in, say, a background - regardless of what
> background-origin is given (which alters the background positioning
> area), the square is always rendered the same size.
> 
> The same *should* be true of border-image, using the border box as its
> positioning area, as the spec dictates.  If you don't provide a size
> or a viewBox, this'll often result in a slightly weird result, *but
> that's okay*.  The Backgrounds spec is then quite clear that
> border-image-slice <number> values refer to the vector-space units
> (for SVG, that's user-space units, or px values within the SVG's
> coordinate space).  Applying that then gets you the correct result.
> 
> ~TJ

Received on Wednesday, 19 August 2015 16:00:27 UTC