W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: 'border-image' confusion

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 26 Jan 2011 16:52:35 -0800
Message-Id: <03CC56F3-B3D6-42EF-B592-C0C287027660@gmail.com>
Cc: "Eric A. Meyer" <eric@meyerweb.com>, "www-style@w3.org" <www-style@w3.org>
To: fantasai <fantasai.lists@inkedblade.net>


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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:36 GMT