Re: [css3-background] <border-image> property

On Wednesday 19 July 2006 22:35, Ben Towne wrote:

> I would like to propose modification of the definition of
> <border-style> to allow a <uri> followed by one of the optional image
> keywords: [stretch | repeat | round].
[...]
> Thus, the value set <border-style> would be redefined as:
>
> <border-style> = <uri> [stretch | repeat | round]? | none | hidden |
> dotted
> | dashed | solid | double | dot-dash | dot-dot-dash | wave | groove |
> | ridge inset | outset
>
> Border style values may be in a comma-separated list when used (also
> new to the definition).
[...]
> *     If there is no useable value for border-style-left,
> horizontally flip the image used on the right if a uri, or use the
> same border-style keyword if a keyword is used on the right.
[...]

I think it is a good proposal, but I'm not convinced it's better than 
the current draft.

We considered at some point making use of symmetries in borders and 
letting the browser rotate or mirror some images to construct the other 
parts of the border, but is it really necessary? It's maybe five 
minutes more work for an author to rotate the image in his paint 
program and it is something that all authors understand, while the 
syntax for specifying the transformations (rotate or flip) into CSS 
could make the property look quite complex, even if you don't plan to 
use the feature.

Maybe transformations provide a little gain because of smaller 
downloads, but these images are probably quite small most of the time 
and especially when combined into a single image for 'border-image', 
the download is quick.

(The example image in the spec is 849 bytes and together with the HTTP 
headers it fits in a single TCP packet on most types of connections. 
Making the image smaller doesn't cause any noticeable gain in speed.)

An advantage of 'border-image' is also that all sides and corners are in 
a single file and thus the browser either gets all of them or it gets 
none. No need to define what happens if the top edge can be loaded but 
the bottom cannot; that situation never occurs. Depending on how you 
design the images, it may be more or less work to make a single file as 
opposed to eight separate ones, but the difference is probably not all 
that big.

The current 'border-image' proposal indeed doesn't have multiple 
fallbacks. It specifies that the image is used if possible and 
otherwise the old 'border-style'. In what cases would you need multiple 
fallbacks? It may be that you use an image format that some browsers 
don't understand, but that can be handled with HTTP negotiation 
instead. (Although HTTP isn't the only protocol on the Web, it is the 
most common.) And otherwise PNG and JPEG are pretty universally 
accepted.

'Border-image' also doesn't allow combining images on some sides with 
traditional border styles on other sides. I think that is a small 
limitation that helps make the model easier to understand and easier to 
implement.

>           Handling at the corners:
>
>           The current draft specification “does not define how
> borders of different styles should be joined in the corner.”

We haven't tried specifying exactly what browsers should do, because we 
didn't want to wait until they all did the same thing. MacIE was a 
browser that tried to do better than others, but most browsers only 
handle certain cases in a nice way and leave the rest to chance.

There aren't that many ways to connect borders in the corner.

Two solid border can be connected with the "angle" method. Ditto for two 
3-D borders of the same type. Two borders with a dashed style should 
connect with a solid L-shaped piece in the corner, if necessary by 
scaling the dashes a bit. Two dotted borders connect with a dot in the 
corner, by shifting the dots a bit so that they exactly align to the 
corners. (If the dots are of unequal diameter, use the largest for the 
corner.) A solid border can connect to a double border by letting the 
solid border fill the whole corner. Ditto for connecting a solid border 
to a dashed or dotted one. But how to connect other combinations in the 
most pleasing way isn't clear, probably it is best to let the 
horizontal border fill the corner.

I'm not sure it is useful to provide a property for the corners, because 
there isn't all that much to choose. I'd prefer to lobby a bit among 
the implementers to do "the right thing" in more cases.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Monday, 7 August 2006 09:41:46 UTC