So, the CSS Working Group is trying to wrap up the CSS3 Backgrounds and Borders Module and prepare it for Last Call. However, there are still some open issues we’d would like to get comments on.
Most of the open issues revolve around
border-image. Brad Kemper knocked down several with his proposal and the CSS Working Group has adopted it in principle. (You can find it drafted into the latest unofficial Editor’s Draft on the W3C site.) We’re still ironing out the details on that, but there are a few others still open on
First Issue: Several people have commented that they would like a way to clip out the center part of the image. There are two options for this: A) Keep the middle part by default (current behavior). Add an
emptykeyword that clips out the middle part. B) Make the middle part clip out by default. Add a
fillkeyword that keeps it. (It’s needed for stretch-tiling things like aqua buttons.) Of course we might also just keep the current solution, C) have authors make that part of the image transparent. Comments? What would you use?
Second Issue: The syntax is particularly arcane. One commenter suggested breaking up
border-imageinto multiple properties, leaving
border-imageitself as a shorthand. For example,
border-image: url(...) 20% 40% / 10% 4em 20% / 0 1em;
would be equivalent to
border-image-source: url(...); border-image-slice: 20% 40%; border-image-widths: 10% 4em 20%; border-image-outset: 0 1em;
This would also allow the values to cascade independently, making it easy to e.g. swap just the image. There’s an overhead cost to more properties, however, so if we do this there needs to be a significant and useful advantage. Thoughts on this idea, or any other ideas for making border-image easier to understand?
Third Issue: There’s still an open question of how
border-imageshould interact with
box-shadow. The two proposals on the table are: 1.) Ignore
border-imageis in effect. (The author can draw the shadow directly in the border-image.) 2.) Use the border-image as a mask to draw a shadow, but only draw the shadow where it appears outside the padding edge (inner border edge). Comments? Preferences?
Fourth Issue: The next topic is fallback colors: the current draft has a feature that lets you specify a background color to use only if the bottommost background image fails to load. The WG wants to know, is this feature something authors really want? Several WG members have posted comments saying that it’s too hard to understand, that it’s not useful, and that the proposed syntax doesn’t make sense. What do you think?
Fifth Issue: The last issue is, the current draft specifies a
background-clip: no-clipfeature that lets a background image spill out of the border box. Implementors are concerned that it’s tricky to implement, and aren’t convinced that it would be useful. If this is something you want, show off a realistic example or two that demonstrates why it is needed.
Off-topic Issue: While I’m here, the WG wanted me to ask what people thought of renaming the
block-directionand whether either was more understandable (or if anyone had better ideas). The property changes the direction of block layout, and the values are
tb(horizontal lines stacked top-to-bottom, like English text),
rl(vertical lines stacked right-to-left, like traditional Chinese text), and
lr(vertical lines stacked left-to-right). This is for vertical text layout, btw; it’s different from graphical rotation. See pages 2-5 of UTN 22 (PDF/HTML+SVG) for a definition.
P.S. Could someone please fix the css3.info style sheet so it doesn’t effectively eat list markup? Thanks.
You can skip to the end and leave a response.
No need to leave out the extra properties, don’t prematurely optimize.
I don’t see how is specifying a background color to use only if the bottommost background image fails to load is hard to understand. Personally, I somewhat like this feature. I made a menu once that would be far easier to do if there were such a property (it had dark background with transparencies and white text).
1. A, empty keyword (C should also work implicitly).
2. Yes, this actually needs to be done with more properties like text-shadow to reduce CSS code duplication (think of combining these with pseudo classes like :hover). It also helps with education because someone can be taught the individual properties first and then the shorthand.
3. Ignoring box-shadow doesn’t sound like the right option, more explanation would help.
4. Why do some WG members seem to think authors can’t tie their own shoelaces?
5. I could imagine some possibilities but nothing very practical. Revisit in Border and Backgrounds Level 4.
This isn’t exactly germane to the questions above, but it does have to do with background images in css3:
Could there be a way to specify the dimension of a background image in a RELATIVE unit? That way, you could specify that a background image is X ems wide by Y ems tall. That would allow for background images to scale up with increased text size, allowing for truly elastic site designs.
The rule could be written something like this:
background-image-size: 40px 20px;
Though with most browsers going to full zoom, I’m not sure how useful this would be. Thoughts?
4. An author being able to make use of a fallback color seems pretty common. Here’s a screen shot of some CSS-based tabs that could make use of separate background-color and fallback colors to gracefully handle text resizing or text wrapping with long translations. http://skitch.com/cgriego/bmay8/tabs-and-css-fallback-colors
@Chip Cullen: That feature is already in the draft: it’s called background-size.
@Chris Griego: All good points. The argument that was given for ignoring box-shadow was that the border-image could contain complex shadows, and box-shadow could be used in the fallback for when the border-image couldn’t be loaded.
I think box-shadow using border-image as a mask would lead to nicer results, box-shadow already follows border-radius and such.
Although that could lead to an issue about how box-shadow interacts with partially transparent image segments, currently it seems the alpha value of the colours (background-color, border-color) is ignored.
Well, right now, the draft of the property only allows for either pixels or percentages.
what I’m trying to advocate, specifically, is the use of ems in that property. while percentages are relative, and do scale, it does sort of behave differently from ems.
For instance, if you had a liquid layout, a percentage based background image would scale and squoosh accordingly. If you want to have a background image stay the same size, but scale when text size is increased, it would have to be based on ems, wouldn’t it?
Second Issue: Splitting out the rules like this and allowing the properties to be set independently would massively increase the ease and maintainability of using these rules.
As someone concerned more with being able to implement rules in real projects rather than what the rules are, I would suggest this is vital. These rules could be used to style, say, a series of buttons that have different states. Changing the styling images would be an easy way to visually display these states and I would not want to have to repeat all the properties for each style when the could be inherited.
Should the use of short-hand and individual properties be consistent with existing stuff like background:; and border:; ?
1: I like option A and B equally. In either option, you have a way within CSS to do both cases. The question is which use case would be more frequent… Perhaps A.
4: You mean resort to using background-color when background-image can’t be loaded? I’m not completely in favor of this. I think both should be in effect. Look at how background-color and background-image interact. Especially when you consider images with alpha transparancy, the desired effect may sometimes be something like “an image WITHIN the normal non rounded border”, not “a shadow around the box”, for which we’re supposed to have box-shadow, possibly in combination with background-image as a mask.
5: I don’t really need that. For most of the stuff I can image, overflow:visible; does the same trick.
Off topic issue: I don’t have an opinion on that one either.
keep up the great work.
“the WG wanted me to ask what people thought of renaming the block-progression property to block-flow or block-direction and whether either was more understandable (or if anyone had better ideas)”
i would suggest using <> as it descries both flow and direction :D and IT”S SHORT!
First – *We definately want a way to make this optional*. I’m not really set on how. Making it transparent feels a bit like a hack and would prevent us from using jpgs. My first thought was leave it out by default because the idea of defining background in the border properties was temporarily confusing, but that could just be me.
Second – Love the idea of breaking it up into multiple properties, as Chris Griego mentions, it’s a good tool for reducing code duplication.
Third – I don’t like the first idea of taking control of the box shadow display away from the developer. If we have background image with a box shadow in it and don’t want a box shadow, can’t we just disable it ourselves? The second option sounds like it would let us do more and cooler stuff.
Fourth – Fall back options are good and I didn’t find the proposal hard to understand. Is it useful? Chris’ example is a good one. As for syntax could we borrow syntax from fonts where the fall back has a comma? Hm, not sure that makes sense either.
Fifth – I can see how this could be useful, and here is my hastily thrown together example (http://flic.kr/p/6gLB8X), but if it delays the module because it’s hard to implement we can live without it!
Opps… let me correct myself:
“However, if there is background-color at the corresponding edge,”
“…if there is border-color…”
“You mean resort to using background-color when background-image can’t be loaded?”
“…resort to using border-color when the border-image can’t be loaded?”
(silly me… I was thinking of how backgrounds do it, and accidently used them everywhere)
@stephanie – We can’t use the comma, because it’s already used for multiple backgrounds.
@boen_robot: Issue 4 was, actually, about backgrounds. Read it again: it’s about specifying a second background color, called a “fallback color”, that’s used *in place of* the regular background-color in the cases where the background image can’t be loaded.
@fantasai – everything i had (thought i) read about the background-size property seemed to only include pixels and percentages. now, i can’t seem to find any of those pages that i read that on, so i have egg on my face. i just re-read the W3 working spec, and you’re completely right. sorry for the thread pollution.
Oh… I see… I though we were talking about fallback colors on border-image. Well in that case – I for one don’t really need such a secondary color. I already think of background-color as an integral (read: important) part of the design – one that is always applied, and I make my designs so that they look well (not so shiny of course, but still readable) even without images exactly because of and thanks to that.
On the other hand, seeing what this does*, I can imagine some scenarios where this might be useful. Overall, I can live without it (so if the WG thinks of getting rid of it, I won’t be advocating against it), but it would be nice to have it if it isn’t troublesome.
*BTW, the idea is not as hard to grasp as WG members think. It did require a certain brain power to think of a use case, but not to understand what it does.
I imagine the border-clip: no-clip; property/value would be useful for :hover effects. In example if you moved your mouse over a background-image that was say a picture of stacked cookies…and you moved the mouse over the area of the element and it would change the background-image to show you that you knocked over the cookies. I think this would require more scripting to be done effectively but it would be cool to be able to use eventually.
The border-image and border-shadow should *BOTH* exist simultaneously and it’s obvious that the shadow should *always* appear next to/under/over the border-image. If you’re already using an image you can technically emulate the border-shadow over the image…but if you have to switch the border-image for some reason but you *HAVE* to keep the shadow then by disallowing them to coexist you could severely limit future design implementations.
1. For border-image (center) clipping, option A makes the most sense if such an option were to be available. However, option C doesn’t seem at all unreasonable.
2. For border-image syntax/properties, having separate properties available would be keeping inline with other CSS properties.
3. For border-image box-shadow interaction, proposal #1 seems the most reasonable.
4. For the image background-color interaction/fallback, the current spec reads clearly enough. Not sure where the confusion is. Seems like it would go towards the whole idea of graceful degradation.
5. Doesn’t seem useful enough.
With border image vs. box-shadow, there are a couple of points to note:
1. Yes, the author CAN set items with border-image to not have a box-shadow, and vice versa. The advantage of having them both specified in the CSS at the same time, but suppressing box-shadow, is that this allows you to have generated box shadows for browsers that have not yet implemented border-image or for people that have images turned off or for places where the images have not yet loaded or failed to load. But then, when border-images CAN be drawn, you have complete control over how they are drawn by editing them in the image editor.
2. If we are to rely on the browser software to generate shadows via a mask based on the alpha channel of the images, then you have much less control. Is the mask drawn using the full alpha channel? For some images with a lot of translucence you may not want that, and only have a shadow along the edge. What if you want some pictures in the same border to appear closer or farther by having the shadows closer or farther, or sharper or fuzzier? What if you want different colored shadows for different parts of the image? What if on you want to decide on a case-by-case basis whether or not you want the effect that the padding box also has a shadow? These are all things that you can determine on your own in an image editor, but not if the software is determining where the mask goes. And since you’re creating the images anyway, there is no extra “cost” to putting the shadow in that image.
3. If the browser software determines the mask for the shadow based on the image, this would not work for JPEG images, since they have no alpha channel or transparency. Any shadow drawn under the image would have to be determined by what, white pixels, drawn above the actual image? White might not be the color you want for determining your mask.
4. The property is called ‘box-shadow’, not ‘drop-shadow’. If you use a non-rectangular mask, it is no longer a box shape. And if you don’t use a mask, but just base the shadow on the border-box (as it works now in experimental implementations), then you always get a rectangular shadow shape that is rarely the shape you want (it only works for images with flat outer edges that line up with the border-box).
I think most authors can see the value in having a fallback color for when the image doesn’t load. For instance, when the background image has transparent areas, then the background-color needs to be transparent, but when the image is completely missing then you need some color there instead to make the text readable.
For me the real issue is not if, but how it is specified.
The current draft has it as part of the background-color property value, for example background-color:transparent/black. Now I know authors are smart enough to learn what that means, but it is not intuitive. To someone getting started with CSS, you have to explain that one of those colors is a fallback color; it’s the one AFTER the slash, and its not a fallback for the other color in the same property, but rather a fallback for a completely different property (background-image).
In other properties that have fallback values (such as font-family), the values are all listed in order of preference within the same property declaration. That is what I’d like to see for fallback color: that background-image can list two or more items to be used as fallbacks, in order of preference. For instance, the first could be an SVG, then a PNG, then a GIF, then a solid color. If the software didn’t support one then it could use the next one on the list. And if it didn’t support images at all (or images are turned off or not yet loaded) then it would use the last item, a solid color background instead.
Nice article, I have an issue, If the border is having radius such that the border is round may be a disc shape and if I need to apply border image to the circle is it possible as the border image is coming as square.
Thanks & Regards,
Sagar S. Ranpise