Re: RFC: ability to assign images to corners

On Thursday 21 February 2002 22:21, Robert Koberg wrote:
|   one more thing on this:
|
|   even if you named these properties butthead1, jimmy2, etc we would love
| to use the feature. It just makes sense to have it included. If the main
| thing that is holding this up is naming then I say get over it and just
| create a new name that makes sense.
|

I would say that it makes sense to get those features implemented.
Included into specs and not-implemented features make no sense, IMO.

|
|   ----- Original Message -----
|   From: "Stuart Ballard" <sballard@NetReach.Net>
|   To: <www-style@w3.org>
|   Sent: Thursday, February 21, 2002 10:44 AM
|   Subject: Re: RFC: ability to assign images to corners
|
|   > Bert Bos wrote:
|   > > The CSS WG also likes it and in fact decided a few months back to try
|   > > to write a draft[1] about it. However, from *liking* it to actually
|   > > coming up with a consistent and implementable specification is quite
|   > > a long way. Corner pieces are relatively OK, but the edges may
|   > > contain a fractional number of tiles, what do you do then? Scale the
|   > > tile? Scale the element's content? Crop the tile? All of those? And
|   > > how do you keep the CSS rules simple to write? There are already
|   > > quite a number of border properties, we'd like to avoid that we get
|   > > two dozen more...
|   >
|   > border-image-width: (<number> | <percentage> | auto){1,2}
|   > border-image-height: (<number> | <percentage> | auto){1,2}
|   >
|   > Width applies to top and bottom (separately if two numbers are
|   > specified). Height applies to left and right. The border thickness can
|   > be obtained from other means (ie, the image for the top border is
|   > always scaled to the height of the thickness of the border). The
|   > "repeat" property is always implied to be in the direction that the
|   > border goes in. (TBD: should it be possible to specify "position" on
|   > the image?)
|   >
|   > border-corner-image: (none | <url>){1,4}
|   >

very good.
Easy to add, hopefully not too difficult to implement.

|   > The size of the image would be determined unambiguously by the
|   > thickness of the two intersecting borders at that point, so the size
|   > doesn't have to be specified. If one image is specified, it applies at
|   > all four corners; otherwise the four images go clockwise from the
|   > top-left. If no corner-image is specified, the borders of the two
|   > intersecting corners should be used, separated by a diagonal line:
|   >
|   > ----------------+
|   > Top border     /|
|   > --------------+ |
|   >
|   >               | | <-- side border
|   >
|   > All that's left is the question of how to actually specify the image
|   > for each side. The only reason that's complicated is that there are
|   > already so many overlapping border-* properties that are shorthands for
|   > each other. Presumably if anybody actually understands the rationale
|   > for all those properties, it should be relatively easy to see where an
|   > image url could be fitted into them. It should be possible to specify
|   > "auto" for the border thickness: the thickness should then be
|   > determined by the intrinsic size of the border image on that side.
|   >
|   > How's that for a concrete proposal? It doesn't cover absolutely
|   > everything (for example, it's not possible to specify an image that
|   > should be tiled uniformly over the whole border area) but it might be a
|   > good starting point?

If you are interested in my opinion: we should go for it!

|   >
|   > Stuart.

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/

Received on Friday, 22 February 2002 11:48:56 UTC