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

Re: 'border-image' confusion

From: Eric A. Meyer <eric@meyerweb.com>
Date: Wed, 26 Jan 2011 13:19:18 -0500
Message-Id: <a06230900c96614ab42f0@[]>
To: www-style@w3.org
At 9:45 AM -0800 1/26/11, Tab Atkins Jr. wrote:

>On Tue, Jan 25, 2011 at 7:51 AM, Eric A. Meyer <eric@meyerweb.com> wrote:
>>  At 7:45 AM -0800 1/25/11, Brad Kemper wrote:
>>>  The webkit implementation is based on an older and less mature version of
>>>  the spec. Firefox is doing it correctly according to the spec...
>>    I gotta say the older, less mature version of the spec is much better at
>>  supporting the simple case as well as the complex ("framed") cases.  I'd
>>  love to know why the change was proposed and decided upon, because in the
>>  absence of a really compelling reason I'd love to see that part of the spec
>>  rolled back to how it used to be.
>If we wanted this functionality (just using the whole image for all
>8/9 slices), it would be *much* better to say this directly.  Rather
>than supplying 1-4 lengths, give some keyword that means "I want to
>use this whole image for all the slices".  Everything else can then
>work as expected.

    I suppose, but it seems like saying "100%" or "5px" once (and then 
being able to control how the image is repeated, with 
round/space/repeat) isn't all that more difficult than having a 
special keyword.
    Is there some reason why the current behavior of 
'border-image-slice' is desirable?  If there is, then yes, a new 
keyword would be needed to make the "use a single symbol all the way 
around" case happen.  But I don't see why slices overlapping should 
cause those slices to be forced to complete transparency in the first 
place, so I don't see why syntax changes are needed.
    I'm really hoping someone here will explain the reasoning behind 
the currently defined behavior of 'border-image-slice'.

Eric A. Meyer (eric@meyerweb.com)     http://meyerweb.com/
Received on Wednesday, 26 January 2011 18:19:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:55 UTC