Re: 'border-image' confusion

On Wed, Jan 26, 2011 at 6:45 PM, Eric A. Meyer <eric@meyerweb.com> wrote:
> At 4:52 PM -0800 1/26/11, Brad Kemper wrote:
>
>> On Jan 26, 2011, at 1:32 PM, fantasai <fantasai.lists@inkedblade.net>
>> wrote:
>>
>>>
>>>  It was undefined what happened if you overlapped, so I put in a
>>> definition that
>>>  seemed to make sense? Overlapping sides means negative middles, so I
>>> just floored
>>>  the middles at zero.
>>
>> Hmm. Is it too late too late to make a change like that, to allow overlap
>> and still interpret negative middles as zero? It does seem like a fairly
>> easy win, if it was implemented that way. You'd have all your corners and
>> sides...
>
>   Okay, now I'm seeing the problem.  (So I didn't fully understand
> 'border-image' after all!)  The problem is that you really are slicing the
> image up into nine adjacent regions, not copying portions of the image into
> eight border slices and a background.  For example, the left-side slice has
> to be the region bounded by the bottom of the top left corner slice, the
> left-offset value, and the top of the bottom left corner slice.

Yes.  (Though it could be changed, I like the physical connection that
this metaphor has.)

>   (Aside: even now, how are UAs supposed to treat '50%' when the image has
> an odd-number-of-pixels dimension?  What slices result?)

Rounding is always UA-defined.  Don't do that if you want a predictable result.

>   The only way I can see to rescue what I was proposing is to say that where
> slice areas overlap, the overlapping region is what's used for some slices.
>  Specifically the top, right, bottom, left, and fill slices.  So given this
> image:
>
>   123
>   234
>   345
>
> ...then 'border-image-slice: 2;' would yield the following slices
>
>   12   2   23
>   23   3   34
>
>   23   3   34
>
>   23   3   34
>   34   4   45
>
> That's not entirely intuitive either, though.  It would yield the result of
> '100%' (or, in this case, '3') causing every slice to use the full image,
> but the cases in the range 51% - 99%, like this one, are a little weird.
>  And they could lead to some odd joins between border regions.
>   Unless that sort of result is seen as acceptable or even desirable, then I
> think Tab's right and the only way to make the "repeat a single symbol
> around the edge" use case work is with a new keyword.  Either that or it's
> back to 3x3 grids for everything and a number of years repeatedly explaining
> why something so apparently simple needs a kinda goofy-looking base image to
> drive it.

Agreed; the 100% case isn't too bad, but the other cases are confusing
and weird.

We can add this in B&B 4 at the same time we do 5x5 grids, like Brad suggests.

~TJ

Received on Thursday, 27 January 2011 03:29:11 UTC