- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 26 Jan 2011 16:52:35 -0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "Eric A. Meyer" <eric@meyerweb.com>, "www-style@w3.org" <www-style@w3.org>
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