meyerweb.com

(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008′ series.)

My few thoughts on the “Graphical Effects” part of the feedback document. A lot of what was mentioned by the community is already in the pipeline, so there’s not a lot to say about those except “hurry ‘em up, willya?”.

Gradients — like rounded corners, no surprise these came up. (All we need is to define wet-floor-reflect and we’ll complete the Web 2.0 design tricks hat trick.) I’d like to see them myself, and I don’t think defining them is quite as hard as the commentary implies:

Imagine, for example, applying a gradient to the text of a <span> broken across two lines. Do you apply the gradient to each part individually? Glue them together as if they were all on one line first? Draw a rectangle around both parts and apply the gradient to that? (CSS3 Backgrounds and Borders has a control for this.)

I’d say the answer is right there, in the form of background-break, but let’s assume for a moment that said property never existed and we still had to deal with this problem. I can think of two solutions:

1. Only allow gradients to be applied to non-inline boxes. This would not be my preference, but it could be so defined. There’s already precedence with CSS for that sort of limitation: width, height, text-align, and other properties are restricted to non-inline boxes.
2. Treat gradients the way backgrounds and borders are already treated on inline boxes. I’d be much more in favor of this. In other words, lay out the inline box as though it is all on one line and then break it in pieces as needed to fit into the actual text flow. (This is the behavior of continuous, the default value of background-break.)

But since background-break exists, you just treat gradients as you would any other background in accordance with background-break’s definitions.

The somewhat trickier problem is how to define the value syntax for background-gradient so that’s both powerful and extensible without being unusable. I think that’s solvable, but not easily, and probably not in a way that will satisfy everyone.

(Though this would be a fabulous place for the cardinal-point values from pre-CSS1 days, which you can still find in the specification if you look hard enough, to make a roaring comeback, wouldn’t it?)

Unidirectional background repeats — I say yes. Here, have some values: repeat-up, repeat-right, repeat-down, and repeat-left. In each case, the image would be repeated in the indicated direction from the origin image (the one placed by background-position). Ironically, really old versions of IE did half of this by not correctly supporting repeat-x and repeat-y, treating them instead as if they were repeat-right and repeat-down.

There are occasions where this would be very useful, especially if you can combine the values into something like repeat-down repeat-right, and most especially in conjunction with multiple backgrounds. So you could put an image stripe across the top of the element background, another one down the left side, and then fill in the rest of the background with a repeat-down repeat-right image. Not a particularly common case, but the only way to handle it at present is with multiple nested elements, each with its own background and possibly a lot of negative margin trickery, and nobody wants that. (Which may also be why it isn’t a particularly common case.)

You could also put an image in the center of your page and then a single stripe that goes only downward from behind it. Like a golf ball on a tee, say; or a tree trunk below the leafy crowm; or a stem from a flower.

Slanted corners — sure, why not? The issues are all the same as with rounded corners; the only difference is that you have a flat corner instead of a rounded one. It makes joins between different borders styles/colors more obvious, but that’s a good thing: any solution that works well for the slant corner should work as well for the rounded corner. Besides, if we’re already going to the effort of rounding corners, this seems like a pretty easy add-on.

Multiple borders — I think this would be quite useful. I occasionally fake this with a border and an outline (as in my diagnostic styles) but that only works for two; if you want three or more nested borders (or two or more in IE/Win) you have to start nesting elements. Also, having multiple borders lets you define your own gradient borders like you were a pixel artist, and who doesn’t like pixel artists?

At the same time, though, I do feel that this should be fairly low on the implementation totem pole. And, as pointed out in the document, if image borders get implemented then a lot of the need for multiple borders goes away.

Alpha channel image masks — the problem I have here is what happens if you, say, try to use an image to alpha-mask a non-replaced element? How does it scale? Or does it? Will there be a mask-stretch property? Who really wants to stretch an image over a great big div anyway? (From a visual-results point of view, I mean.)

Allowing masks might help in figuring out how to do non-rectangular float areas, in that you could use the alpha image to define the area used for float exclusion. Combine that with a stretch ability and SVG support, so you can draw scalable vector masks, and I think you’re really getting somewhere. (As does Matt Wilcox; he and I have been chewing this over in the comments on the previous post in the series.)