border-image-outset:4px 3px 2px 1px;
padding:-4px -3px -2px -1px;

what do you think about this?

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

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.

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).

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.

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.

When I’m at the end of design/development of the given version of my website I enjoy messing with rendering-engine specific implementations of CSS3 so if this stuff gets done you can count me as an early adapter. I just really hope we will be able to completely manipulate *ALL* properties via JavaScript/DOM especially since browsers are apt to occasionally incorrectly implement a spec and later fix it.

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.