- From: David Hyatt <hyatt@apple.com>
- Date: Fri, 15 Jun 2007 16:19:05 -0700
- To: David Hyatt <hyatt@apple.com>
- Cc: Andrew Smith <asmith15@learn.senecac.on.ca>, www-style@w3.org
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 UTC