CSS3 Feedback: Graphical Thoughts
Published 15 years, 9 months past(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:
- 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. - 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 ofbackground-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.)
Comments (27)
I figure I might as well speak up since I was one of the people who recommended CSS gradients. A few other things to take into consideration with CSS gradients is where the points and midpoints fall.
It’s probably easier for browser vendors to just give us the ability to define a beginning and ending color but sooner or later we’ll also want the ability to place the colors closer together or further apart (much like we already do in Photoshop) or the ability to create midpoints in between those colors. I image this could be done using percentages, say something like:
background-gradient: #ccc 5%, #aaa 95%;
or
background-gradient: #ccc #aaa, 5% 95%;
Regarding inline vs block level content, I’d be happy if it worked the same way as it currently does with border etc just to stay consistent.
Yeah, that’s sort what I was covering with the “value syntax will be hard but solvable” comment, Neal. You seem to have left a gradient direction out of your examples, for example—and will gradients always be linear, or can we have circular gradients as well? And so on, and so on.
Not impossible to work out, but not as easy as just setting a background color, obviously.
background-gradient-type (linear, radial, conical, square)?
background-gradient-color-start
background-gradient-color-end
background-gradient-midpoint (%)
or shorthand:
background-gradient: #000 #fff linear 50%;
I’m almost certainly missing an obvious shortcoming. I always do.
Firefox 3.1 supports using CSS to apply SVG masks to HTML content.
http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html
CSS+SVG does raise a good question. What will Microsoft implement first?
1. A new CSS gradient solution that the W3c comes up with
2. SVG
@jsutcliffe
I like that, it flows nicely and makes sense. Mid point might be a little ambitious, but I like that overall concept
One of the things that I’ve wanted for a long time was a “foreground” property. Works exactly like background—or more specifically, the proposed multiple-backgrounds—except its color and/or images are laid over text nodes rather than under. I think there are several potential uses for this…
A new text-to-image replacement method in which you wouldn’t need to hide the text, potentially solving the CSS-on-images-off issue with most replacement methods.
And remember when you wanted that scrollable div whose text faded away into a sweet gradient at the bottom, and you had to position another element on top of it to make it happen? Remember how annoying that was? Foreground.
Stepping aside the topic at hand for a moment, I feel it necessary to say that I’m really enjoying this CSS3 Feedback series of posts. It’s reaffirming a lot of the features I’ve felt CSS has been missing for a long time, and it’s getting me [over] excited at the possibility of these features actually being implemented at some point. I’d have to imagine that browser manufacturers would be more inclined to take heed from someone like yourself backed by 100+ commenters as opposed to the ramblings and tweets from a few average Joes like myself.
Keep it coming.
Of course, I just now realize that “foreground” was mentioned in the WASP feedback document. I guess we can chalk up my comment as an additional vote for it.
To comment #5 by Neal G, there should be a third option:
3. Nothing
Until CSS gradients are commonplace, there’s always this.
What about image rotation via CSS? I know I have remade images a number of times for simply representing different rotations of the same image which not only increases load time, but clutters and adds to code complexity (and feels overwhelmingly tedious!!!).
@mike whitfield
I’d be satisfied if we could just flip images. You could even leverage existing the width and height css properties. e.g. width: -10px;
All good stuff this. I like the gradient option, and jsutcliffe offers a good concept here. I agree midpoint might be a little ambitious, but since when was ambition a bad thing?
Ironic how you could do some of these things waaaay back in IE5. Stuff like photo filters, rotation, zoom and even grayscale! However, now I see you can do CSS3 transforms in WebKit which is promising.
Unidirectional background repeats
Oh please please yes =)
I don’t know how many times I’ve added structurally unnecessary wrapper divs to my contents just because I needed a vertical bagkground patten to start with a vertical offset from the bounding box of the container element.
Firefox 3.1 will support CSS transforms as well (based on Webkit’s proposal).
Pingback ::
Max Design - standards based web design, development and training » Some links for light reading (3/3/09)
[…] CSS3 Feedback: Graphical Thoughts […]
Surely we don’t need to think too hard about gradients: they work okay in SVG amongst other things, so it seems a little silly to even consider doing them differently, without having a really good reason.
For those browsers that can handle SVG already, this has the extra benefit of potentially giving them a quicker implementation path.
Was there any suggestion to allow splitting background-position into background-position-x and background-position-y ?
This would allow to redefine one without the other, reducing the number of rules needed to manage rollovers, etc, using sprite images.
I would have thought this would be in css3 but I can”t find it.
@Mike
SVG is handling a slightly different situation. An SVG image scales, but doesn’t change its vertical/horizontal proportions. Web pages do.
I’m assuming the call for gradients is to allow fluid layout, otherwise a pre-made gradient image would suffice, and the CSS support would not be needed. So there are probably issues like a minimum or maximum dimension at which the gradient should stop scaling.
And if anyone is really generating exactly the same image every time time it’s used – please rethink.
I love the gradient and rounded corner option.
Personally, I think the biggest feature in graphical / background related attributes would be / is multiple background images. It means no more markup soup to get rounded corners!
I really like jsutcliffe concept, I feel that would be a great way to include gradients with CSS
I think jsutcliffe comment was one of the best ways in which a gradient tool could working within CSS3 that I have heard. Nice concept!
Pingback ::
CSS Flavor – Gallery of Best CSS Design Websites» Blog Archive » CSS3 Feedback: Graphical Thoughts
[…] 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?”. Read more.. […]
Thanks, regarding inline vs block level content, I”d be happy if it worked the same way as it currently does with border etc just to stay consistent.
Regards,
Sharon
I like all these added features coming to CSS3, however I wonder how many browser conflict they’ll create with so many ‘extras’. Sometimes it is good to keep it simple when the browser gods seem to hate each other so much.
Pingback ::
Some of the Top Minds in the World of CSS and why you should be following their Work - Inspect Element
[…] CSS3 Feedback: Graphical Thoughts […]