W3C home > Mailing lists > Public > www-style@w3.org > June 2007

Re: border-image clarifications needed

From: David Hyatt <hyatt@apple.com>
Date: Fri, 15 Jun 2007 16:19:05 -0700
Message-Id: <3EFB12DB-D46F-4370-9A50-6452FC65FEDD@apple.com>
Cc: Andrew Smith <asmith15@learn.senecac.on.ca>, www-style@w3.org
To: David Hyatt <hyatt@apple.com>

Oh, my apologies to Bert!  Sorry, Bert! :)  The spec does still say  
exactly what I described.

"The resulting images are placed centered in their respective parts  
of the border (the middle image is put in the middle of the padding  
area) and then tiled.

I do not think the spec needs to be changed at all.

dave

On Jun 15, 2007, at 4:12 PM, David Hyatt wrote:

>
> I strongly disagree with your suggested changes.
>
> I don't understand why you think repeat would not do a scale.  You  
> always want to scale a border-side slice to the actual width of the  
> border.  Especially when high DPI is involved, the image slices are  
> not necessarily even in the same coordinate space!  1 pixel in the  
> image != 1 CSS pixel!  This is why CSS pixels are not used to do  
> the slicing.  I think you need to take some time to think about  
> this difference before proposing changes.
>
> It looks to me like the current spec has changed the definition of  
> repeat for the worse, so I'll tell you how we do repeat (which is  
> how it was specified at the time I implemented it).
>
> Repeat preserves the image's aspect ratio and scales the image in  
> the correct dimension to the border-width.  It should then do a  
> tile that spreads out from the center of the border side.  All this  
> was specified when I last looked at the spec.  Centering achieves  
> the best result, since you want the joins of the images at the  
> corners to be symmetric.  Tiling from a corner is a bad idea, since  
> you get asymmetric results.
>
> Round is basically like repeat but ensures that a whole # of images  
> fit within the border.  The aspect ratio of the images gets messed  
> with slightly to make this work.
>
> dave
>
> On Jun 13, 2007, at 10:31 AM, Andrew Smith wrote:
>
>>
>> I couldn't find Dave Hyatt's email address (would someone email it  
>> to me?) but I looked at the Safari beta to test the -webkit-border- 
>> image property. Here's what i found:
>>
>> Andrew Smith a écrit :
>>> Regarding http://www.w3.org/TR/css3-background/#the-border-image
>>> 1) Of the three keywords (stretch, repeat, and round) only two  
>>> are explaned. If 'repeat' is explained somewhere else, a  
>>> reference is needed.
>> In webkit this does not tile the image. For example: on a  
>> horisontal border the width of the tile is as set by the four  
>> numbers used to split the source image; the height of the tile is  
>> the same as the height set by border-width (or the replacement for  
>> border-width from border-image). In case I'm not explaining it  
>> well, here's a screen shot: http://littlesvr.ca/border-image/ 
>> safari-border-image-01.PNG
>>
>> Not sure what you (fantasai) mean by anchoring. The first tile  
>> starts from the left (or top) and is cut off on the right (or  
>> bottom).
>>
>> Regardless, if it's not explained it's really up to the  
>> implementer to decide what to do and I think this part could use  
>> some consistency, so at least a "'repeat' means to simply tile the  
>> image as for background-image" would do nicely in the spec.
>>
>>> 2) The sample source image in Example 1 does not break cleanly  
>>> into 3x3. This is entirely unexpected. The coordinates should be  
>>> 0-26 for the first diamond, 27-53 for the second, 54-80 for the  
>>> third. The image the way it is now is hard to use for testing,  
>>> because of 1 or 2-pixel artifacts. I can make a replacement if  
>>> you like.
>> On the webkit blog I found Hyatt saying the same thing. I took a  
>> quick look again and at least the top left tile is too big: 0-27  
>> in both directions, it should be 0-26. I use http://littlesvr.ca/ 
>> misc/border.png for testing instead.
>>
>>> 3) "If the first keyword is 'round', the top, middle and bottom  
>>> images are reduced in width" - I assume that means they get  
>>> squashed horisontally, but on the example it looks like they  
>>> haven't lost their proportions, which is very unlikely unless the  
>>> container is sized to accomodate the border image. Should clarify  
>>> this.
>>> 4) "If the first keyword is 'round', the top, middle and bottom  
>>> images are reduced in width, so that exactly a whole number of  
>>> them fit in the width of the padding box" - if the width of the  
>>> padding box is a prime number the only way to fit a whole number  
>>> of images in it is to have them sized to 1 or to the width of the  
>>> padding area. Should clarify this.
>>> 5) "X' = W / ceil(W / X)" - this doesn't give me a whole number,  
>>> is it supposed to? If not, what am I to do with this formula? If  
>>> it does make sense, a reference to where this is explained would  
>>> help a lot.
>> In webkit for 'round' the tiles are increased or decreased in size  
>> to keep their proportions. Any space left is used up equally on  
>> both ends, with the tiles cut off on both ends.
>>
>> Since I can't figure out what the author(s) of the specification  
>> meant, I propose the following changes: http://littlesvr.ca/border- 
>> image/border-image-01.pdf If approved, the webkit implementation  
>> remains mostly valid (except for the 'repeat'). I believe that  
>> will handle all the expected use cases and I will happily  
>> implement the same in Mozilla.
>>
>>> 6) If the width of two consecutive sides isn't the same, what's  
>>> done to the corner? There are at least three different ways to  
>>> deal with it. Should clarify this.
>> In webkit the corner is stretched in both directions. Actually  
>> this is already explained in step 1 bullet 3, but I moved it in  
>> the proposed changes document.
>>
>> Comments please?
>>
>> Andrew
>>
>>
>
>
Received on Friday, 15 June 2007 23:19:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT