Re: border-image clarifications needed

fantasai a écrit :
 > Andrew Smith wrote:
 >> 1) Of the three keywords (stretch, repeat, and round) only two are 
explaned. If 'repeat' is explained somewhere else, a reference is needed.
 >
 > Repeat is explained, it's just not mentioned explicitly in the algorithm.
 > If you follow through the algorithm in the case of 'repeat', you'll 
get the
 > spec author's intended result.
 >
I think with the changes you proposed it will be clear what it means.

 > I'll step through it like we did on IRC so everyone else can follow.
 > For simplicity, let's just follow the top border region through the 
steps.
 > We have a 10*10 image tile, and the border region is 5px tall and 
17px wide.
 >
 > 1. The spec says:
 >      "The two images for the top and bottom edges are made as tall as
 >      the top and bottom borders, respectively"
 >
 >    We scale the height of our image tile down to 5px.
 >
 > 2. The spec says:
 >      "and their width is scaled proportionally."
 >
 >    We scale the width of our image tile to 5px, restoring its original
 >    aspect ratio.
 >
 >    * According to your image
 >        http://littlesvr.ca/border-image/safari-border-image-01.PNG
 >      Safari skips this step for 'repeat'.
 >
 >    Note that this means the top, middle, and bottom borders will 
often have
 >    different widths; they won't tile together. We *could* change the spec
 >    so that the middle image stretches the same as at least one of the 
other
 >    border images: that would make all three match at least in the 
case where
 >    the top and bottom borders are the same width.
I don't think that's necessary, it should be pretty straight forward for 
the one making the page, to understand that borders with different 
widths will cause all kinds of problems (most of those problems we 
probably didn't even think of yet).

 > 3-round. The spec says:
 >      "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 we don't scale the image, we can fit 17/5 = 3.4 tiles.
 >    We scale down the width of our image until a whole number can fit,
 >    i.e. ceil(17/5) = 4 tiles can fit. Our new width per image tile is
 >    17/4 = 4.25 px. (I hope this explains the use of the formula?)
 >
 >    The CSS spec doesn't discuss how to round partial-pixel sizes.
 >
 >    If we had a 400dpi screen resolution, we could render the tiles at
 >    4.25px by using 4*4.25 = 17 device pixels (see definition of 'px' 
in [1]).
 >    On a device where 1px = 1 device pixel, we'll have to fudge the
 >    partial-pixels by distributing extra pixels to some tiles and not to
 >    others. For our case this means one tile will be 5 pixels wide, and
 >    the others will be 4 pixels wide. All of them will be 5 pixels high.
 >    Ideally we'll distribute the wider tiles symmetrically rather than
 >    all on one side.
I think it is critical to explain (in the spec) exactly how to do this. 
If it's left to the implementer to decide how to allocate the extra 
pixels, inevitably all the implementations will produce different results.

I believe it would be easiest for implementers (and would make no 
difference to users) if one pixel (or something) were added to enough 
tiles, sequencially, starting from:
- the left for horisontal borders, and
- the top for vertical borders

A clause to that effect would make sure there's only one way to do it, 
but any other clearly-specified algorithm will do. Or is there something 
about pixels and device pixels that I still don't understand and that 
makes this impossible to define?

 > So changes I would suggest are:
 >
 >  Replace:
 >   "The nine images are scaled in four steps"
 >  with
 >   "The nine images are scaled and tiled in three steps"
 >
 >  Add as the third bullet point in step 2:
 >   "If the first keyword is 'repeat', the top, middle, and bottom images
 >   are not changed any further", to clarify that 'repeat' participates
 >   in this algorithm.
 >
 >  Add after step 2, replacing the paragraph after it:
 >   "step 3
 >      * If the first keyword is 'round', the top, middle, and bottom 
images
 >        are placed at the left edge of their respective parts of the 
border
 >        (the middle image is put in the padding area). Otherwise the 
images
 >        centered horizontally in their respective areas.
 >      * If the second keyword is 'round', the left, middle, and right 
images
 >        are placed at the top edge of their respective parts of the 
border/
 >        padding area. Otherwise the images are centered vertically in 
their
 >        respective areas.
 >    step 4
 >      * The images are then tiled within their respective areas. All 
images
 >        are drawn behind the element's content, in front of the element's
 >        background."
 >
 > Additionally, we may want to consider
 >
 >  Remove the last bullet in step 2.
Those all look to me like useful changes. With them in the only concern 
I have left is the allocation of extra pixels for round, as I described 
above.

 >
 >  Add to the end of the first bullet in step 1:
 >   "The width of the middle image is scaled by the same factor as the top
 >   image unless that factor is zero or infinity, in which case the scaling
 >   factor of the bottom image may be substituted, and failing that, 1."
 >
 >  Add to the end of the second bullet in step 1:
 >   "The width of the middle image is scaled by the same factor as the top
 >   image unless that factor is zero or infinity, in which case the scaling
 >   factor of the bottom image may be substituted, and failing that, 1."
 >
I can't comment on that, I haven't tried to deal with the 'extra 
background image' part of the spec yet.

Thanks a lot for your time fantasai, I am sure this will help many 
people, not just me :)

Andrew

p.s. Sorry I reorganised my web server a little, the source image I use 
for testing is now here: http://littlesvr.ca/border-image/border.png

p.p.s I first sent this mail to www-style-request@w3.org, but I don't 
see it coming back, so reposting to www-style.

Received on Friday, 15 June 2007 17:56:05 UTC