meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

CSS3 Feedback: Graphical Thoughts

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

27 Responses»

    • #1
    • Comment
    • Tue 24 Feb 2009
    • 1050
    Neal G wrote in to say...

    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.

    • #2
    • Comment
    • Tue 24 Feb 2009
    • 1054
    Eric Meyer wrote in to say...

    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.

    • #3
    • Comment
    • Tue 24 Feb 2009
    • 1218
    jsutcliffe wrote in to say...

    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.

    • #4
    • Comment
    • Tue 24 Feb 2009
    • 1741
    Robert O'Callahan wrote in to say...

    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

    • #5
    • Comment
    • Tue 24 Feb 2009
    • 2016
    Neal G wrote in to say...

    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

    • #6
    • Comment
    • Wed 25 Feb 2009
    • 0057
    Tim Wright wrote in to say...

    @jsutcliffe

    I like that, it flows nicely and makes sense. Mid point might be a little ambitious, but I like that overall concept

    • #7
    • Comment
    • Wed 25 Feb 2009
    • 1012
    Matt Puchlerz wrote in to say...

    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.

    • #8
    • Comment
    • Wed 25 Feb 2009
    • 1019
    Matt Puchlerz wrote in to say...

    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.

    • #9
    • Comment
    • Thu 26 Feb 2009
    • 0524
    Chris Hester wrote in to say...

    To comment #5 by Neal G, there should be a third option:

    3. Nothing

    Until CSS gradients are commonplace, there’s always this.

    • #10
    • Comment
    • Thu 26 Feb 2009
    • 0954
    mike whitfield wrote in to say...

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

    • #11
    • Comment
    • Thu 26 Feb 2009
    • 1222
    jsutcliffe wrote in to say...

    @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;

    • #12
    • Comment
    • Fri 27 Feb 2009
    • 0412
    Amelia Vargo wrote in to say...

    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?

    • #13
    • Comment
    • Fri 27 Feb 2009
    • 0752
    Chris Hester wrote in to say...

    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.

    As of now you can scale, rotate, skew and translate boxes.

    • #14
    • Comment
    • Fri 27 Feb 2009
    • 1534
    abu wrote in to say...

    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.

    • #15
    • Comment
    • Fri 27 Feb 2009
    • 2109
    Robert O\'Callahan wrote in to say...

    Firefox 3.1 will support CSS transforms as well (based on Webkit’s proposal).

    • #16
    • Pingback
    • Tue 3 Mar 2009
    • 0435
    • #17
    • Comment
    • Tue 3 Mar 2009
    • 0632
    Mike wrote in to say...

    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.

    • #18
    • Comment
    • Tue 3 Mar 2009
    • 1507
    Sophie wrote in to say...

    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.

    • #19
    • Comment
    • Thu 5 Mar 2009
    • 1140
    John wrote in to say...

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

    • #20
    • Comment
    • Thu 5 Mar 2009
    • 2301
    Trendy Pixels wrote in to say...

    I love the gradient and rounded corner option.

    • #21
    • Comment
    • Mon 9 Mar 2009
    • 0731
    Micheil Smith wrote in to say...

    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!

    • #22
    • Comment
    • Mon 8 Jun 2009
    • 0805
    Rak Design wrote in to say...

    I really like jsutcliffe concept, I feel that would be a great way to include gradients with CSS

    • #23
    • Comment
    • Fri 26 Jun 2009
    • 0956
    Sam wrote in to say...

    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!

    • #24
    • Pingback
    • Fri 24 Jul 2009
    • 1804
    Received from 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.. [...]

    • #25
    • Comment
    • Tue 18 Aug 2009
    • 0417
    discount vouchers wrote in to say...

    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

    • #26
    • Comment
    • Wed 26 Aug 2009
    • 1655
    web page designer wrote in to say...

    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.

    • #27
    • Pingback
    • Mon 14 Dec 2009
    • 0507

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


February 2009
SMTWTFS
January March
1234567
891011121314
15161718192021
22232425262728

Sidestep

Feeds

Extras