Re: 'border-image' confusion

On Jan 26, 2011, at 1:32 PM, fantasai <fantasai.lists@inkedblade.net> wrote:

> On 01/25/2011 07:45 AM, Brad Kemper wrote:
>> 
>> On Jan 25, 2011, at 7:08 AM, Eric A. Meyer wrote:
>> 
>>> In case that last assertion seems dubious, I put a 'border-image' scenario to the readers of meyerweb[1].  A number of them came up with the right answer but complained about the property being very counter-intuitive.  Others hacked around the problem entirely using other methods because they couldn't figure out how to do what I specified, or couldn't figure out how 'border-image' was supposed to work in the first place.  (And a couple of people got it to work in WebKit, but we're still not sure if that was a bug exploit or not.[2])
>> 
>>> I can't see a good reason why it should behave as it does now, where slices get replaced with transparency if your slices exceed half the height/width of the base image.  Note that WebKit already does this, but other browsers do not.
>> 
>>> [1] http://meyerweb.com/eric/thoughts/2011/01/24/border-imaging/
>>> [2] http://meyerweb.com/eric/thoughts/2011/01/24/border-imaging/#comment-531046
>> 
>> The webkit implementation is based on an older and less mature version of the spec. Firefox is doing it correctly according to the spec, as follows:
>> 
>> # The regions given by the ¡®border-image-slice¡¯ values may overlap. However if the
>> # sum of the right and left widths is equal to or greater than the width of the image,
>> # the images for the top and bottom edge and the middle part are empty, which has the
>> # same effect as if a nonempty transparent image had been specified for those parts.
>> # Analogously for the top and bottom values. [1]
>> 
>> I don't recall exactly why we decided on that.
> 
> 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...

Received on Thursday, 27 January 2011 00:53:18 UTC