UltraNormal

Gradients and multiple backgrounds are definitely the two must-haves.

As far as gradients go, implementing them would be huge. For one, it would improve loading speed. It would also allow them to be used in new ways with liquid designs. It doesn't even need to be anything fancy, just two colors. I've almost never used a three color gradient.

CSS Circles and hexagons with drop shadows would be Great!

Circles and hexagons!? WTF? Unless John can elaborate, that is definitely not a CSS problem; images will do fine.

2 color gradients would probably be sufficient, especially for CSS3. Maybe in version 4 there could be more, but... baby steps. Although I would add that designers are probably going to get fed up really quickly with the fact that those gradients can't do alpha transparency so I'd love to see that in CSS3. (That is to say opaque on one end, and transparent on the other.)

I find it strange that with multiple backgrounds the first listed is the closest to the user, yet when you do background shorthand the background-color comes first and it is the furthest from the user. That strikes me as a pretty big oversight. Shouldn't it, for the sake of consistency and for the sake of people new to CSS, be the same for both: either first is closest or first is furthest?

I would keep 'round' in background-size and leave -repeat only to handle repeating. Keep it simple. Perhaps the keyword 'approximate' or 'average' instead of 'round' would be better. 'round' might get confusing for new users looking for rounded corners. 'approximate' is pretty explicit.

It would be nice if background-origin could recieve a % or px so I could have a block of repeating images that begins at a certain point inside the containing block. Or it would be good if I could set a number to background-repeat such as repeat(3) repeat(4) so I would have a background that had my image repeated only 12 times (3 on the x axis by 4 on the y axis) and then ends.

Jim, since "transparent" is an existing color value, if we do gradients, I don't see how we'd get away with not allowing "transparent" as a value.

The rounded corner borders are in there and would make life a hundred times easier. That and the gradient backgrounds would be top of my wish list.

The ability to add more than one background image to an element, but I think is covered by the layering background images.

But it's amazing how you learn to work around problems to the point were you forget you ever struggled.

Drop shadow, both external and internal, with an ability to determine the amount it fades out and the length.

This is worth some more in depth thought. bookmarks page Sorry for the stream of consciousness.

kevin, I don't mean a background that is transparent, I mean a background gradient that can do transparency.

For instance, a gradient that goes from opaque blue to fully transparent blue.

Since Flash borrows so heavily from HTML and CSS for it's most recent versions, why not have a look at what flash is doing (even for a laugh) at: http://www.macromedia.com/software/flashplayer/maelstrom/

The problem with looking at Flash is that HTML+CSS isn't supposed to be a competitor with Flash. That's SVG's territory, and one I don't think anyone on the CSS Working Group wants to jump into. Styling documents is enough to bite off, I think. ;)

Kevin, first of all, thanks for the work you and the working group have already done on CSS3. And thanks for opening up (and listening to) additional forums and means of providing feedback other than traditional W3C mailing lists.

I'll second pretty much everything Jim noted in the third comment. In addition, I'll emphasize that the two most common uses of gradients are either one color to another color, or one opacity to another opacity of the same color.

I'm not sure where you'd start and stop with gradients, as it seems you'd quickly be overlapping roles with SVG. But if gradients were an option, the related property types you may want to consider which may or may not be obvious:

- gradient-type: linear is the obvious default, but radial is also common being useful for creating glows in the center of a box, etc.
- gradient-origin: or use gradient-start-position and gradient-end-position
- gradient-direction: depends on -type and -origin; could be an angle (0 to 360, or 180 to -180) our outside-in/inside-out
- gradient-length: even if a box is 400px in height, I may only want a vertical linear gradient to span the first 50px.
- gradient-start-color and gradient-end-color: possibly used for both color and opacity of that color.

Background-origin sounds potentially useful. Though the current definition is not what I imagined or hoped for. I've always thought background-position imposed an unfortunate limitation since px values always originate from the top-left corner. What if I want a background-image positioned 200px away from the right edge, and -50px starting outside the bottom edge of a flexible width/height box?

Expanding the role of background-position may break backward compatibility and understanding. So background-origin might be the property to tweak to determine which corner context is used for background-position values. Maybe use something like "background-edge" for what is currently labeled background-origin?

And border-radius by corner, definitely. Rounding just one corner, or the top two, or the right two, or opposite diagonal corners -- all common desires to counter the boxy-ness of CSS-produced designs.

As a final general note, I'll stress the growing importance of clear specification language. Even though the specs are primarily written for those who build the tools, increasingly, those who build with and for the tools are turning to the specifications to learn and understand CSS features -- especially in the absence of anything like a CSS3 version of Eric Meyer's Definitive Guide. Even though I consider myself fairly fluent with the ins and outs of CSS and wordings of past specifications, I'm still confused about the border-image section, even after reading through parts of it 3 or 4 times.

Thanks again for listening.

Ahhhh, gradients and rounded corners. The absolute life's-blood of all of AOL's interfaces ;) Well certainly of AOL Search anyway... had a nasty flashback there!

Kevin, as usual, I like all of the work you do and this is no exception. If I knew CSS better (still a neophyte) I would be able to add more. As it is, I like what has been proposed so far especially the rounded corners seeing as how I was one of the major perpetraitors of the wee beasties at AOL... hehehe

Is there a projected timeframe for when CSS3 will be usable?

Doug (and Jim), since CSS3 includes rgba (and hsla), I think opaque gradients would be a no-brainer (ok, maybe not - I came up with it last night when I was trying to go to sleep after two days thinking about it off and on). You could specify rgba(33,33,33,.8) for the top and rgba(33,33,33,1) for the bottom to get a dark grey gradient with slightly less opacity on the top than on the bottom.

I can't promise anything since I'm just one member of the group, but it makes sense to me. And Doug, thanks for the suggested properties!! If everyone else could try to express how you'd like to define these things we want, that makes it a little easier to make concrete (because the concept's not always difficult - defining it is).

As for "usable"? Some of it is now if you use Firefox or Safari. For example, I can use CSS3 selectors now if I don't care about IE. I don't think IE supports any CSS3 properties except the ones they invented and the group adopted (the only I can think of is text-overflow, but I may be wrong about that - it's early).

Gradients: Its easy enough to do this with images. But Scalable CSS Gradients would be a cool idea too.
Multiple Backgrounds: I would say this is realy a must. This is realy my #1 wishlist item for css3, besides all the selectors.
background-origin and background-clip: never used them.
More atomic background positioning: if i understood it correctly, why not. would definitely be usefull.
border-radius by corner: this should definitely go in.

Kevin,

Thanks for this opportunity! And of course, as Douglas said, thanks for all the work you and others have already done on CSS3 so far.

Here's my input:

Gradients
Addendum's to Doug's items already:
- gradient-type: reverse; it would start at gradient-start, end at gradient-end, and at the 50% point in-between those two it would reverse itself. So basically, a double gradient.
- gradient-origin: I wouldn't use this for positioning (as Doug suggested), but for specifying where the point of origin is, exactly like how background-origin functions in the CSS3 B&B WD, now.
- gradient-start-position: much like background-position, a way to let it start somewhere on a specified position. Through combining this with gradient-origin you can have it start absolutely anywhere you could possibly imagine;
- gradient-end-position: to specify where the gradient must stop. This is like the gradient-start-position: property an actual coordinate.

Example of the above few properties:
if I specify the gradient-origin as top right, a gradient-start-position of "-50px 5px" would start 50 pixels left of the right edge of the element, and 5px below the top edge.

- gradient-width: 1px would make a 1px-wide gradient (don't ask me how exactly that should be implemented with diagonal gradients, though), a value of 100% would make it go full-width, taking the gradient itself from a top-to-bottom point of view. That means, if the gradient is set to show up from left to right, a width of 100% would make it occupy space from top to bottom of the element, in the direction left-to-right.
- gradient-start-opacity: &
- gradient-end-opacity: keep these as separate properties instead of combining them with -color (in rgba/hlsa style). A shorthand could let them all be done in one big property, but much like border-width:, I feel these should be separate properties. Also, I personally very much dislike the use of RGB values on the web; I'm a gigantic HEX-fan and I find CSS and HEX go together much better than CSS and RGB. Maybe that's just me, though.

Possibly interesting:
- gradient-repeat: when combining with gradient-length, this could be used to indicate that a gradient of length 400px should repeat itself if the element is larger (taller/wider) than 400px.
possible values: no-repeat | repeat* | integer
* = values like repeat-x and repeat-y are useless, as gradient-width allows for the same and more.

- gradient-interval: imagine I want a gradient of 120px high, but I want blocks of 20px from black to white. That would give me 6 blocks, in these respective colors: #000-#333-#666-#999-#ccc-#fff
gradient-interval set to 20px would produce that result. The default would be 1px. A value in % might be interesting too.

multiple backgrounds
So. Very. Necessary!

- background-origin and -clip are great, as far as I'm concerned. I like them, and I can see myself use them for sure.

- Separate clip values for each image: yes please

- is there any chance we can make background-origin be a per-image setting? So that we can have a different background-origin for each image on a single element?

- background-stretch is a better name. I was going to recommend background-stretch as a new property but then I saw that -size did what I wanted it to do, and had that note underneath it. +1 vote for background-stretch

- background-attachment: anchored as suggested by Rob Mientjes on the mailing lists here:
http://lists.w3.org/Archives/Public/www-style/2005Jul/0398.html

- border-radius by corner is a definite must. That's how I started using it at first, when Mozilla first added -moz-border-radius. I made boxes with the top-left and bottom-right corners rounded. I liked it, it was very easy to understand that way, and as flexible as I needed it to be.

- On border-images with a conflicting border-radius: I suggest clipping them at the outer edge of the curve. "Not affected at all" is absolutely no good for a lot of situations, much like how it would have been horrible if the background color would span the entire square box even when there is a curved border. Clip, please!

That's my input for the time being... :-)

Fallback, alternative, or replacement text or content. Background images are often used instead of {img} for "nonessential" images, some of which contain text. These borderline cases should be accommodated, at least in CSS3, for accessibility.

You heard it here first.

Multiple background images is my only "must-have" from that list. After that's implemented, half of these other features would be obsolete.

For example, why rely on a browser to render border-radius (and likely not do a very good job of it), if you could Photoshop them exactly how you'd like them, and insert them through multiple background images?

1) I'm on the fence about gradients -- on the one hand, I'd love them - but the fact that I won't be able to likely control all elements of the tonality (such as illustrator and photoshop), most likely, means I'll probably end up just doing it myself graphically. Might be good for some low end users?

2) I only find background size redundant -- I see users loading up huge images and just resizing it with their CSS... havock on download times. Stretch does seem like a better name, too -- not as confusing as mixing it with the size of the containing element. However, I can see how we're also adding an extra useless term into the mix.

3) Position I can find useful, but it is something that can be done without CSS. I don't think clip will be too useful for me atleast -- as it's just hiding larger downoad times than anything, I should be doing it in an image editor. Unless, of course, if I clip an element to round and my text will flow to that shape, or if I can clip using text (mask the image with dynamic content)? Then you've gained a tool similar to using InDesign, or Quark if you're old school. To counter, clipping to a border is a nice featureset.

4) Isn't that close to choosing content for your choice of background origin, and them manipulating the position?

5) Yes. If I want a bottom left, top right rounded corner, and the other two square without using images, there you go. You could use a background image for this, but that's another redundant image. Unlike my gradient complaint, I would have full control over radius, so I don't see a limitation.

No chance in controlling my border dots/dashes using math to control the spacing or dash/dot size? Illustrator as an example. That's just icing, but would be nice.

Inner Shadow someday would be a cool effect as well for a box element.

Either way, shadows, gradients, and all of the image borders/backgrounds I can see turning web pages into a scary production for the home designer!

Thanks for the opportunity to post!

woops, sorry -- one more time without typos:-)

Well, gradients are inherently problematic due to the bit-depth required to do anything delicate or subtle...

But moving on, I'd like to see this:

#cutOut { alphachannel:url(/masks/alpha1.png;) alpha-invert:false; antialias:true; }

and

#keyholeShape { clipping-mask:url(/masks/keyhole.eps ); stroke-clipping:true; stroke:1px solid #333; }

if you catch my drift.

Instead of bogging the system down with a bunch of lame pre-set shapes that'll be out of style before the spec is implemented, why not load a library of user defined shapes. Box shapes can be vector eps files and alphachannels can be png or tiff or whatever bitmap format you like.

Now THAT would be something :-)

Best,
Dug

Dug, that's cool... but it's really really scary. Good job!

Dug:

Sounds more like something we'll see in CSS4. Putting EPS-capable technology in each browser seems like a bit over the top for today's web and people's hardware.

I know this isn't really something that's the job of the CSS3 specification, but it'd be great if browsers were to use anti-aliasing on border-radius :-)

'background-origin' sounds very useful to me.
Also the gradients and multiple backgrounds would be great to have.

I don't know if this is the place to coin new stuff that isn't in the draft (or maybe it's there, I probably missed it? Didn't read the whole thing to be honest), but wouldn't it be great to say something like:

li { background-rotate: 180%; }

Or...

li { background-flip: horizontal }

In my designs I've used rotated and mirrored images more than once, but of course had to use several images to get it done.

It would be a great bandwidth-saver. You just need one image and you can flip it around any way you like it.

Would be good to make anti-aliasing optional on border-radius. For some designs it's almost essential to have anti-aliased corners, but other times the design requires sharp 'pixel art' style rounded corners.

As a side-issue, it would be good to make anti-aliasing a configurable option on all elements. Being able to turn anti-aliasing off for large font sizes, for example, would sometimes be very useful.

And perhaps anti-aliasing should offer multiple levels, rather than just on/off. Photoshop offers 4 levels of anti-alias for text, and I use each one regularly to achieve the desired effect.

Kevin,
Thanks for the opportunity to give you feedback.

I would just like to emphasis how important Doug’s comment is regarding the “_importance of clear specification language_” and expand it by asking the specs deliver logical, intuitive code.

For example section 11.
If I want a background image to stretch to fill the area I would not expect to write background-size: 100%. Logically to me 100% would imply that the background image size should be its real size and original aspect ratio.
Whereas background-size:auto implies to my the image will automatically stretch to fill the available area?

So in my opinion the property should as you asked be renamed background-stretch with values

None
(the default) – no stretch
Auto
Stretches x and y to fill the area

A specific size.

The percentage is relative to the width or height of the area given by 'background-origin'.

I’m assuming that the way to separate x and y would be two values comma separated, or would background-stretch-x and background-stretch-y be required?

Regards
Paul

sorry the code i copied from the spec got mangled:

background-stretch

None
(the default) – no stretch
Auto
Stretches x and y to fill the area
length
A specific size.
percentage
The percentage is relative to the width or height of the area given by 'background-origin'.

I posted a half-assed proposal this week, but no reply yet, so I'll link it here. Basically, it's all the functionality of background-attachment: fixed but without having it fixed to the viewport and with an additional functionality, namely the level of parent-selecting. My mail is therefore not complete, but it contains a better explanation. It's here for those interested.

Oh, my better proposal?
#content h3 { background: url(h3.png) no-repeat anchored(1) } will put the background "anchored" to (0, 0) of #content, not h3. anchored(2) would put it on #content's parent, etc. etc.

I'll cast more votes for border-radius by corner, transparency in gradients (though I'd like to be able to specify the color in hex with a separate transparency value, not just RGBA), and multiple backgrounds. All fabulous ideas!

To the people saying gradients are already just as easily accomplished with images, think of the ways we have to expand the coverage of the image. Right now, there's only repeating. You can't stretch it in any way. I support the addition of background-stretch (despite the abuses that will come from it), but a CSS3-generated gradient would allow for much more interesting behavior possibilities that don't require adding more images (read: bandwidth) to your site.

I noticed there was a comment in the draft for background-repeat-direction (i.e. repeat-up, repeat-down, etc). I have found a number of instances where I wanted a background to begin at a particular position, and then only repeat in one direction like repeat-down, instead of tiling both up and down by using the repeat-y, or conversely left and right using the repeat-x.

A background-repeat-direction property in conjunction with the other background properties would be a fantastic addition to control with CSS.

Just wanted to throw in really quickly that I agree wholeheartedly with Mr. Estes :)

I've often wanted to have multiple borders on one or more sides of a box. To achieve a shadow effect, for instance, with two 1px borders, one light grey and one white.

Something like border-depth: 2; or something for two borders.

I really would like to have control over border-radius by corner, this would be very useful. The multiple background image could be good. For the rest, I think it would be well done with images. There are too many properties not supported by the browsers today, what about implement them slowly?

With regard to Dug's comment on colour depth, possibly an @colorbitdepth > 256 conditional would be useful (but outside the scope of this module).

I think we should go with the bare minimum. Because I don't think browsers, especialy IE, will implement all of this for years.

For me, multiple backgrounds and radius for borders and border images are amazing to have. It would honestly be really helpful for everyone.

Um gradients and double background would easy things alot. what about some dynamics in css? even more then there is now .Like , we could work with style change without javascript

Edson, what kind of "dynamics" did you have in mind, and what properties would they apply to? I'm not sure CSS should start replacing javascript for the interactive elements, although the argument could be made we already have with things like :hover.

I like to see options to modify the border-type "dotted".

Actually on a dotted-line every second pixel is transparent. But a lot of designs requires more flexibility: one pixel-colored and two pixel-transparent and so on...

Flexible width could also be adapted for "dashed" border-style...

16. The 'border-style' properties - I would add "pipe" and it would be a rounded (gradient) border lit from the top left. If "wave" caused any problems, I would drop it. You might consider creating "corner-type" where a corner can not only be rounded (as adressed elsewhere) but could be decorated in other ways... bulbs, clipped corners, an extended edge, or colored or transparent squares... etc. This might fall into the border image stuff tho. shrug

18. The 'border-image' property - To put it simply, thank you so much! :D

20. The 'border-break' property - Awesome! This will affect me. I create many documents that go to print and it makes me sick when things get cut up.

22. The 'box-shadow' property - Not as important as adding drop shadows to text, but still cool. This will be used and abused for a long time to come.

The only related topic I don't see covered is form elements - but perhaps that's in another document. I bring this up in response to the background and border restrictions on elements such as radio buttons. However, given the scope of the topic - I'm sure it's being addressed somewhere in the spec.

-Specify a position of repetition of the image. In some cases they call that as tile, it is used in the visual themes of the windowsxp and longhorn. Look at the image:
Of course would be better with attributes as "top-left-tile" or "bottom-left-tile".

-Borders and background gradients, without proprietary tags or DirectX effects. It could use an image as mask with Alpha channel besides the background image or color.

-border-top-left-radius with double, dashed and dotted styles, of course yes. It would be good inner-border-radius and outer-border-radius.

Ops, sorry, the textile formatting tags was not working anymore...

http://img.photobucket.com/albums/v381/zephon/image-tile.jpg

Thank you Kevin, for the opportunity to provide feedback.

I like the proposed CSS3 specs for backgrounds and borders, especially the radius for corners and background images for border areas. The one thing I would like in the latter is the ability to apply z-index. Lacking that, I'd like to have the behaviour be that the corners would appear 'on top' of side images.

I'd like to be able to use a background image in a liquid design where I can make the top, right, bottom, and left border images use 100% of size with corner images covering the border images only in the corners. This would ensure that no matter the size of the viewport, no break would appear between border side images and border corner images.

Thanks again for this opportunity.

I haven't seen much discussion about borders. And it's not clear to me if this is covered in the spec. Something that allows you to apply an image to each border and control its positioning and tiling, ie...

border-left: 2px solid #000 url(image1.jpg) repeat-x 0 0;

border-right: 2px solid #000 url(image2.jpg) repeat-y 100% 100%;

border-top: 10px solid #fff url (image3.jpg) no-repeat 0 0;

border-bottom: 1px solid #000;

mabye I missed it, but is there a way to include other types of resources (not images) as backgrounds (and mabye borders)? probably most importantly application/xml+svg :D

e.g. whatever{background: url(some.svg)}

Multiple backgrounds images!

For example, on my site -- which granted is a bit dated by now -- i have boxes with corners. In order to make these boxes fully flexible to all sizes, you need to have one picture for each corner and one for each side. Thats a whole lot of duct-tabe div elements...

I think it would be awsome if you could keep adding background images to the same element.

Maybe something like

background:( normal backgroundproperties here, more backgroundproperties here, ... );

so you kinda had "layers" of background images.

This would Greatly reduce the amount of the duct-tape elements on the internet i belive.

Oliver

I agree with most of what was said, but one thing: Gradients!

Wouldn't it be better to use an SVG image along with the proposed 'background-stretch' property to create the gradients?

On that note, I like Paul Duncans 'background-stretch' implementation but it would be better to allow something more like this:

None
(the default) – no stretch
Auto
Stretches x and y to fill the area
Length XY | Length XY
A specific size.
Percentage XY | Percentage X Percentage Y
The percentage is relative to the width or height of the area given by 'background-origin'.

Only the value none would ever have to apply to both X and Y, you should also be able to use 'auto' for either X or Y.

Multiple background images is the most important feature im my opinion. I honestly can't wait to implement this, even if IE users will have to cope without for awhile. ;)

Just wanted to sum up some of the features mentioned above, which I would definitely see a use for.

- background-attachment: anchored
- background-repeat-direction
- background tiling
- atomic background positioning

Gradients I'm not so sure of. Perhaps this should stay an SVG thing.

I think it would be nice to have slashes and backslashes (and any custom symbols or strings, maybe, by means of Unicode) as border-style properties.
Maybe, as in the following example:
border-string: 'border text sample';
border-string-style: 'Times New Roman' 1em italic bold blue;
As well as double or even triple border (through, maybe, something like secondary-border):
secondary-border-color
secondary-border-style
secondary-border-width
secondary-border-image
secondary-border-radius
secondary-border-break
...
tertiary-border-color
tertiary-border-style
...

Forgive me if this has been brought up before: I only skimmed the latter comments. However, I didn't see anything like this.

Perhaps I miss the point somewhere, but wouldn't the best way to do gradient be simply to have them as a colour-value? We could have a gradient "function" as a colour-value which then can be applied to either 'background-color' or 'color'. I'd suggest it would take as parameters the "origin" of the gradient (where the first colour starts, ie. 'bottom', 'top-left') and two or more (for extensibility) colour-values other than a gradient with CSS3 UAs only required to use the first and last it can understand.

You wouldn't have the fine-grained control of a whole mess of properties, but you could reuse many of the properties currently in CSS3-Background like 'background-size', 'background-position', background-repeat' and 'background-origin'. Plus you have easy gradients for text (though not all kinds of gradient would work well for text, but that's not the point).

If people then want more control over gradients, one can always cook up ECMAscript methods to parse gradient values to change/extract specific bits.

It occurs to me now that the other background properties could only be used if gradients were a value for 'background-image', not 'background-color'. Ideally it should be a value for both, but of course because of the 'background' shorthand it can't. So, 'background-image' should instead be able to use "gradient()" as well as "url()", and maybe we can have "gradient()" apply to 'color', too.

Alan, it's up to the browsers to support image formats other than GIF, JPG, PNG, etc. There's nothing in the spec that defines a list of supported or unsupported formats. So, SVG should be a go, which would provide for more complex gradients.

J. King - that's how I was thinking gradient would be defined. I think having gradient() apply to colors, or even borders, would be nice, and shouldn't be forbidden by the spec. How do you (all of you) think gradient() would work in the background shorthand? Would it be used in place of url()? Could you combine the two? Could you only combine the two when using multiple backgrounds?

I would like a background-style property that works similarly to border-style, which would allow you to have dashed backgrounds, dotted backgrounds, etc.

The problem I think you're likely to encounter with gradients (useful as they are) is providing the level of support designers are requiring. CSS isn't Photoshop, and I don't think it can be expected to provide full gradient support. Support for gradients at 45 degree angles and filling the specified element would be fine, somethin like:

div {background-gradient: #FFF #000 top bottom;}

Which would go white at top of element to black at the bottom. More complex gradients could be:

div {background-gradient: #FFF #000 bottom right;}

Which would start from the bottom left, and go to the top right of an element. Although you couldn't do things like stopping the gradient mid-way through the div, you could always use an image.

Incidentally, if you can provide gradients for element backgrounds, it should definately be possible to set gradients on a border. If you've just set a gradient on the background of random-box-one, then setting a border with a darker version of the same gradient would look amazing. A flat border would look pretty pants, and you'd find people producing nested div hacks to produce that same effect.

Great work opening this up for us all to comment in. Let me know if you have an opening on the working group : )

Are multiple backgrounds necessary at all?

It should be possible to give multiple backgrounds to boxes, as well as multiple borders, etc. by generating wrapping elements with the ::outside pseudo-element

The syntax of this would also be much more intuitive.

Kevin:
I hadn't thought of 'border-color'; good catch. I don't see any reason why gradient() and url() couldn't be mixed when employing multiple backgrounds. After all, one of the images in a multi-layered background could be a gradient PNG, so what's the difference, functionally? Using something like gradient() and url() in any other context doesn't make much sense to me, though. When dealing with the 'background' shorthand, it would I think have to be a value of 'background-image' only.

Nathan:
CSS1 and CSS2 borders are also very limited, but that didn't stop anyone from using what is available effectively. Designers who want more can still use PNG or SVG, but if the working group and implementors think simple gradients are worth considering, stylesheet authors not willing to mess with image editing software still have an easy-to-use option.

Personally I don't think that CSS needs gradients, but then I don't think CSS really needs 'font-family' or 'cursor', either. Obviously a lot of people would disagree with me on this. Nevertheless, I am interested in how gradients should be done right if they are included; it's a fascinating question.

I'd love to see a drop-shadow property in CSS. For instance, something like this:

div {
shadow-start: #000000;
shadow-end: #ffffff;
shadow-position: outside;
shadow-length: 5px;
shadow-direction: 135;
}

... where shadow-start would be the starting color, and shadow-end the ending color. The shadow-position would specify whether the shadow was inside or outside of the border. The shadow-length property would dictate how large the shadow was, while the shadow-direction would be specified in degrees and would basically show where the light-source was coming from.

All of those properties, except the first two, could have -top, -right, -bottom or -left added to the end of them to specify different shadow properties for each side of a box.

I haven't thought of a good way to work shorthand notation for this yet; my guess is it would go about like the border shorthand notation goes.

Another question would be if shadow properties, if implemented, would add to the dimensions of the box like padding, or not.

As already mentioned on the CSS mailing list:
I would like to see simple constant declarations at the top of a CSS file.

This would enable the use of a constant to define such things as pathnames to image files.

So instead of:

_body {
background-image: url(../../images/blue_angle_swirl.jpg);
background-position: center;
background-attachment: fixed;
}_

I could do something like:

/* constant declarations at top of stylesheet */
_const
image_path = "../../images";
another_const_1 = "abc",
another_const_2 = "def",
...
...
another_const_x = "xyz",
endconst

/* stylesheet body */

body {
background-image: url(image_path/blue_angle_swirl.jpg);
background-position: center;
background-attachment: fixed;
}_

At the moment, I have to hand-code paths to images in CSS.

It would be much easier to define the constants at the top of the stylesheet, and just change one instance of the constant declaration there, rather than having to search through the styles and having to alter each hard-coded instance by hand.

Sorry if my first posting above was a bit off-topic !

As well as border corners, it would also be nice to see an ellipse property.

Obviously, the layout of non-rectangular shapes in a browser is going to be alot more difficult than plain boxes.

I would like to propose that an ellipse object would be automatically assigned to living inside it's own unique parent block object.

The four center points of each side of the parent block that an ellipse object lives in, could be used to calculate the arc of the ellipse's sides.

So for a parent block that is say, 200px high, by 200px wide, the ellipse object inside it would be drawn by the browser as a perfect circle, with a diameter of 200px, +- 1 or 2 px.

The shape and size of the ellipse would be dependent on the dimensions of the parent block the ellipse object lives in.

As the ellipse object lives inside a block object, all the browser has to do to position the ellipse object, is to layout the parent block object that the ellipse object lives in.

The 'live area' of the ellipse, eg for mouse-overs, should only extend to the border of the ellipse, and not the parent block's outer border.

I hope this all makes sense!

Further to Keith Robert's point about constants in CSS:

One of the really irritating things that I find with CSS is colour. If I try to define a new site look (with CSS, obviously) that is - say - red instead of blue, I have to produce a whole load of unnecessary code. Say I have a "box" of some sort, two borders dark blue, background blue, two light blue (to give an indented look) then at the very least I have to do this:

.bordertopdark { border-top-color: #222244; }
.borderleftdark { border-left-color: #222244; }
.borderbottomdark { border-bottom-color: #222244; }
.borderrightdark { border-right-color: #222244; }
.bordertoplight { border-top-color: #AAAACC; }
.borderleftlight { border-left-color: #AAAACC; }
.borderbottomlight { border-bottom-color: #AAAACC; }
.borderrightlight { border-right-color: #AAAACC; }
.backgroundlight { ... }
.backgroundmed { ... }
.backgrounddark { ... }
.darkcolor { ... }

You get the point. On top of this, I have to start putting multiple classes into my class attributes in order to keep things generic, which is only going to make things more confusing.

<div class="bordertopdark thinbordertop ...

And then if I use the same colours for text, or links, or anything, I have to edit the colours in loads of places just to produce a stylesheet in a slightly different sort of green.

So can I propose something along the lines of:

!lightcolour = #AAAACC;
!medcolour = #666688;
!darkcolour = #222244;

Which we can then use as:

indentedbox { bordertop: 1px solid !darkcolour; ... }
a { background-color: !lightcolour; color: !darkcolour; }

Then I could do nice things like put all my colour definitions in a separate file and @import my off-green stylesheet, or my high-contrast stylesheet, or my unreadable-yellow-on-cyan stylesheet. Even for single stylesheets, this would greatly simplify maintenance.

I hope those examples make sense. Anyone like to comment on this idea?

Sorry it is a repeated comment!

Why we can't setup if the border is internal or external?

About the multiple background, it is realy interesting and i belive that necessary!

In border-radius why not a border-type? Something like: "border-type: [radius|linear|img(URL)]" ? Maybe it can give us more flexibility?

Sorry to talk about colors, but why whe don't have the #RGB@Alpha ? like, #FF0000@50% it can be a red half transparent, no? Imagine that use in gradients, like: "colors:#00FF00@30%,#FF0000@45%,#0000FF75%", repair in the multiple instance of gradient!

Thanks, and sorry by my english, my poor english!

Sorry it is a repeated comment!

Why we can't setup if the border is internal or external?

See the input type="button" this border is internal, and see the input type="text" this border is external!

About the multiple background, it is realy interesting and i belive that necessary!

In border-radius why not a border-type? Something like: "border-type: [radius|linear|img(URL)]" ? Maybe it can give us more flexibility?

Sorry to talk about colors, but why whe don't have the #RGB@Alpha ? like, #FF0000@50% it can be a red half transparent, no? Imagine that use in gradients, like: "colors:#00FF00@30%,#FF0000@45%,#0000FF75%", repair in the multiple instance of gradient!

Thanks, and sorry by my english, my poor english!

Yes, instead of using the opacity property, why don't we use the colour format from Inkscape:

#AARRGGBB

Multiple background images: brilliant! I and many others have wanted to do this for ages, and it would make a lot of current CSS techniques a lot simpler.

Suggestions: drop border images altogether!

The multiple background images spec is quite sophisticated already, and I’d much rather see a single, comprehensive mechanism for layering images in CSS than two incomplete ones. Of course, this is predicated on the expectation of being able to use multiple background images to create borders, for which we’d need to...

Expand the background-clip property, perhaps to allow rectangle specifications such as: background-clip: rect(0%-12px, 0, 0, 100%) -- to clip an image into a 12px border on the left-hand-side -- that is to say, provide some way of referring to the edges of the borders and the edges of the content.

Expand the background-position property to allow easy positioning outside the image area, or relative to edges. The notation above might be a good approach, so one could specify coordinates as x%±y. For example: 100%+3px to position an image (if used for the x coordinate) 3px right of the element box, or bottom -1em which would be 1em up from the bottom of the element box.

(This could cover your ‘sprite’ requirement too, as the ‘offset’ number shifts the image appropriately.)

To enhance borders using background images, we also need a way of saying border-style: transparent -- (which would be generally useful too). This isn’t the same as ‘none’; it’s a border which takes up space but isn’t actually rendered. Background images could then be layered into the empty space.

Lastly, cascading has to be defined more rigorously too. I presume that, after declaring 10 background images, that a single background: url(new-bg.jpg) removes all of them and replaces them with a single background image.

However, my stylesheet may wish to update only image 2. Can I be allowed to write background-image: , url(logo-image.png),, to replace image 2, but inherit images 1, 3 and 4?

Even better, could I write background-2: url(logo-img.jpg) top left... or background-image[2]: url(thing.gif) ..?

(post 1/2)

Border radius: definitely should be per-corner, since a common use of this is likely to be navigation ‘tabs’ at the top of pages...

However, the way that Gecko currently allows shortcuts (with “-moz-border-radius”) is a bit annoying—it attempts to emulate the ‘compass points shortcuts’ of the other CSS thickness properties, and ends up not being very useful (since rarely does one want to make opposite corners the same radius).

I’d much prefer a shortcut mechanism whereby:

single number: all corners the same radius

2 numbers: 1st number for both top corner radii, 2nd number for both bottom corners.

3 numbers: 1st number for top-left corner radius, 2nd number for both bottom corners, 3rd number for top-right.

4 numbers: 1st number t-left, 2nd number b-left, 3rd number t-right, 4th number b-right.

Elliptical corners

I think that these will be far less used than 1:1 corners. Perhaps a notation such as this would suffice:

border-radius: {1,4} [, [|]{1,4}]?

That is: up to 4 border radius specifications, optionally followed by a comma and another (up to 4) numbers to give a second radius for each corner to generate ellipses. If the second numbers are percentages, 100% means 1:1, 50% means flattened vertically, 200% means squashed horizontally.

(post 2/2)

Individual corner radii - YES!

Now, what would happen if you spec'd a 100px radius on the corner of a box that was only 50 pixels wide? In Ken's ideal world, the radius would limit itself to the maximum size of 50 so that liquid layouts with rounded corners wouldn't break.

Thanks for all your hard work!!!! I raise my muddy shovel in salute from down here in the trenches.

PS: Where do I post my desperate plea for multi-column text that automatically evens out the column lengths in a fluid layout?

It's not about Backgrounds and borders at all, but something I always wondered is something like this:

div { dimension: 35em;}

or

div { dimension: 35em 10em;}

Its just to simplify the width and height attributes in only one.

Holp to be usefull.
Dudu.

I'm not overly familiar with SVG, but it strikes me that much of the styling here could be handled by it, if it were possible to use that type of image as a background, with some control over positioning and stretching to fit.

I would really like the background swapping possible.

For exemple

#bgImg {
width: xx;
height: xx;
background-image: xxx;
background-image-alt1: xxx;
background-image-alt2: xxx;
}

And then i would be really good we can program it with php and make it random

Multiple backgrounds are a must (everyone thinks that), but what would also be nice is a way to set transparency override.

Ex: I have three images for a tab, the right, the left, and the center image that will be repeated horizontally. I have some fancy look on the side images that includes some transparency. I would want that transparency to not show through to the repeated background of the element, but rather to the background behind that.

.tab{
background-image: url('left.png'), url('right.png'), url('center.png');
background-position: top left, top right, top;
background-repeat: no-repeat, no-repeat, repeat-x;
background-transparency: collapse; (layered/collapse would be the two settings. collapse would combine all the alphas together taking order into account, layered would render them separately. the setting might be able to be applied to each individual image in the background)
}

I like the "gradient()" concept for doing gradients, as it fits into a more generic color setting. Perhaps: gradient(type x y width height angle, color1 percent1, color2 percent2,... colorN percentN) (percent being the location along the gradient, type being linear, square..., x, y, width, height, and angle allowing you to set those parameters)

For borders it would make more sense to have dot dash combinations left to the user:

.border{
border-style: line-style('..-.-'); (line styles could become more advanced: jagged lines could be calculated with "/" and "\".)
border-width: 2px;
border-color: black;
}

Also for borders (though it doesn't really apply to CSS) is for somebody to put pressure on browser makers to allow border override for select elements, and maybe even some specific pseudo classes to handle text highlighting/option selection in inputs and selects.

Gradients would be great.

Rounded corners would be great also.
I think Mr. Bowman hit the nail on the head with that one. the ability to specifiy radius on all 4 corners would be best.

Multiple backgrounds would definately help keep our code semantic. I hate adding div's just to make a background elastic. a background for all four corners would be excellent. BUT.... I am also wondering if we would need to add a background for the center of all 4 sides. center-top, center-bottom, center-right, center-left.
The only reason I bring this up is because of the existing way we have to make elastic boxes.
see: 456bereastreet.com

Although, I think it could be done with a little ingenuity with just 4 corners for backgrounds. I also think making elastic boxes would be the main reason for multiple backgrounds, therefore it would be most important that the multiple backgrounds worked for elastic boxes.

Thanks

Polygonal borders.
That'd be real useful to structure text, IMO. Using only four-edged blocks, it's hard to align text to some background-picture(having slanted edges), it can be done by using multiple small blocks(that float along the wall, increasing their width), but it is likely to break when resizing the text.
With polygonal borders, it should be easier to create a block that forms the text inside.

Or, joining blocks(though this doesn't belong to borders), that'd achieve the same result by a different way.

I would like to have:
* gradients for shadows and 3-d-effects
* rounded corners to leave out images for that!

Thanks!

Baby steps first...

I have often wished there was a "long hand" method for defining horizontal and vertical background positions in separate statements.
Something like:

background-position-x: left;
background-position-y: bottom;

Let's not make this same mistake by only allowing multiple background images to be defined within the one statement.

What's CSS without the Cascading?

Just thought of something rather important about those rounded corners: I need to be able to specify which corners are rounded. This will help with tasks such as building tabs.

Since I am using sliding doors almost always I opt for something like the following:

using images as borders:

border-left-image: url('left.png') repeat-y top left;
background-image: url('right.png');

But multiple backgrounds may provide an even better/cleaner solution. Well, it's just an idea.

Would be cool if I could use corners with some cutting. If will be made rounded corners, why not sliced corners or reverse-rounded corners?

About gradients backgrounds, they need to have the option to set the angle, colors, and styles. Roundeds gradients, linears gradients, mirrored gradients, and so on... Two colors by now is ok...

The shadow and alpha effects would be cool to apply at blocks and could be and CSS standard too.

Let me see... Something else? Why not shubby borders, zig-zag borders, gradient borders and somethings like that?

Sorry... I've got an idea now...

The CSS3 would set alternating backgrounds to tables. You know, odd color and even color and apply the colors for example...

That's would be very cool!

Sorry if someone already said it. I'm not used to read english...

For sliding doors, custom borders, and other stretchy effects, I'd like a 'background -extend' effect. This would stretch an image only at the specified x-y points, preserving the four corners of that image.

123
456
789

would become:

122223
455556
455556
455556
455556
788889

with 'background-extend: 2px 2px' and,

111123
444456
444456
444456
444456
777789

with 'background-extend: 1px 2px' instead of:

112233
112233
445566
445566
778899
778899

With a regular stretch routine. More useful than first appears.

Most of what I can think of has been covered, but I want to reinforce what I believe are great ideas.

-Multiple background images (to support expandable boxes with fine tuned graphics)
-More control for dotted/dashed borders (dot spacing, dash spacing etc.)
-border-image:

Thanks for allowing designers input, thats great.

Sure, I want it all and I want it now!

But, as mentioned here. Gradients seem to be overlapping with SVG. Even rounded corners are in this category.

Rounded corners in CSS would not add anything to the user-experience, when static. When scalable they would.
And here we are seeing arguments like: getting away from the boxiness usually associated with CSS, or a question like: why not sliced corners or reverse-rounded corners?

The first indicates that the complexity involved with building a rounded corner box with the various divs is a very steep learning curve at times.
The second remark reinforces that and at the same time poses the question:

Should CSS supply the tools for perhaps temporary fashions in design?

Which leads to an even more basic question: Do we want CSS to be a lay-out tool or do we want it (also) to be drawing tool?

There is not an easy answer to this. Freeform runarounds would most certainly require both abilities.

It is surely a layout language. If the positioning of graphics needed to form a rounded box were easier to implement, I am not even sure if the proposal for rounded corners would have been put forward.

The fluid (or not so) three column lay-out is still referred to as "The Holy Grail"

So rather than having these exotics, I would much rather see a set of definitions which makes o.a. the rounded corners and liquid lay-outs simpler. And there are some more positioning issues I can think off.

This would flatten the learning curve, speed up the design process. Thereby be more tempting to newby designers to step in and make CSS spread faster.

The user would get better sites in return. And in the end that is really all that counts.

There must, must, must be a property to change a border's length, to make it shorter (or even longer?) than corner-to-corner.

For instance if you wanted a little line centered over the content, you could do something like

border-top-length: 30%;
border-top-position: center;

The border-length properties should accept any units.

The border-position ones should accept at least left | center | right (or top | center | bottom). You could also specify an offset, like

border-top-position: left 5%;

or

border-top-position: center -10%;

which would shift the border appropriately.

These effects are, s'far as I can tell, very hard to accomplish in an elegant way at the moment. And it seems like something that wouldn't be //too// big a deal for user agents to implement, as it involves calculations they're already making for elements' dimensions.

-LH

Thanks for opening this forum for us to supply feedback.

I would like to see an attribute added to borders that would allow the designer to choose whether the border was placed on the outside or inside of an element.

Choosing to place the border on the outside would apply the normal box model, but when it's placed on the inside, the width of the border would be absorbed by the elements width, and the border would overlay the contents of element.

Too many times when designing liquid layouts have 1px borders thrown everything off because they make that element 2px wider and taller.

Garrett Murphey

What Lanny says above sounds useful. I also like Douglas Bowmans suggestions for the gradient properties. (Yes, we want gradients!!)

I also really REALLY like the sound of HSL colours and semitransparent colours using RGBA/HSLA. Sweet! (Looking forward to being a CSS3 designer, you bet.)

Another thing from the above comments that sounds useful is the suggestion for {background-repeat: down | up | left | right} and not just x vs y.

As others have said already, please let us set border-radius on a per-corner basis!

Carsten Altena's suggestions above for rotating and flipping a background image sound great. Could be useful.

Faruk Ates suggested {gradient-interval:[length]}. If you've got the time that would be great to have, too. :-)

Thanks for reading!

ps. Feels great to be able to give direct feedback like this.

This may sound "out there" but I was thinking it would be nice to have "images as borders" functionality to do away with multiple divs to create a box with borders (e.g. torn paper)

about background repeat:
{background-repeat: down | up | left | right} is ok.
It could be very useful when I try to repeat an image from a fixed point (eg.top 100px) to a direction (eg. down) leaving blank the first 100px. Now with repeat-y is impossible to do:(

Are multiple backgrounds necessary at all?

It should be possible to give multiple backgrounds to boxes, as well as multiple borders, etc. by generating wrapping elements with the ::outside pseudo-element

The syntax of this would also be much more intuitive.

Being able to rotate (rather than simply flip) a background image would be superb. Implementing this in degrees would be even better. For example:

background-rotate: 0; (default orientation)
background-rotate: 90; (clockwise 1/4 turn)
background-rotate: -45; (anti-clockwise 1/8 turn)

...etc. It would save on resources, and open the door to some new and interesting user feedback too.

man, that working draft is a pretty exciting page to read. If the browsers implement even half I'd be a happy guy indeed. I mean, multiple background images! Border-images! With stretching? Background Origin? my god.

I'd like to jump on Doug's "clear specification language" boat. Maybe the w3 could sponsor a second version of the specs geared toward designers. I dont mean a tutorial but human oriented language and clearer examples would help a lot of us get it straight.

I'd really like to see a designer be a part of the working group. Not only as an artist but as someone who understands the history of communication design and the tools and langauge of that past.

Thanks for asking for input. Good luck to you all.

Perhaps I missed it in the specs or in one of the (many) comments above, but has anyone suggested a property for clipping borders or something to define how far a border spans down each particular side of an object? Something like this:

border: solid 1px #000;
border-left-clip: top 50%;
border-right-clip: center 50px;
border-top-clip: left 50px;
border-bottom-clip: center 50%;

Also, more alpha/transparency controls on backgrounds, borders, etc. would be great as well as multiple background images. I love the idea of support for SVG in background images too.

These specifications look great, thanks!! Now all we have to do is wait 20 years for IE to start supporting it!

IF gradients are going to be supported, for gods sake build in the ability to have more than two colours.

gradient-color: color1, colour2, colour3.. etc
gradient-direction: vertical/horizontal/degrees
gradient-position: 0%, 33%, 65%.. etc

Would be my thoughts on syntax. Defaulting to evenly spread across the direction if no positions are given for the colours.

Please lets make it useful, not limited.

One man's useful is another's too much.

The ability to scale any background when a user (agent) makes the screen font larger or smaller would be useful. Something like this:

background-aspect: fixed; (default)
background-aspect: scale; (shrinks/grows image relative to amount of scaling given to on-screen text)

Could the background-color properties be enhanced to support two digit/character shorthand? For example, instead of having to write out:

background-color: #f9f9f9;

- we could just put:

background-color: #f9;

- and CSS3 automatically create/interpret the triplet?

This could even extend to single char declarations:

background-color: #f; (white)
background-color: #0; (black)

Granted, this only applies to differing shades of grey, but it would still be helpful I think.

Many thanks for opening up the discussion!

It may have been said already, but I noticed in the working draft the notes under the background-repeat property, and I believe specifying the direction of the repeat (up, down, left, right) would be a handy tool. Probably wouldn't generate much fanfare (not like multiple backgrounds) but it would be useful.

Thanks.

Thank you Kevin, for the opportunity to provide feedback.It's really something ...

I don't whant to repeat anything previously said but here are my opinions:

There must be provided a way to specify the "rounded corner's" position inside or outside the box indicating where the arch is orientated.

It would be usefull to be able to specify some sort of "border fade" to simulate blending into the surrounding page elements color(s). If such a feature would exist it should allow me to specify at least:

Direction: left to right (and the oposite), top to bottom (and the oposite)

Lenght: in em, px, % etc, as i may want to simulate the border fade ony for a certain amount/part of the border.

Colors: A start one and an end one applicable only to the specified "lenght".

Start point: expressed as a number and measured in pixels, ems, precentage, etc with the posibility to specify a start position left, right,top,bottom or simiar.

It would be interesting to be able to apply two similar/mirrored efects like this to the same border as i may want to simulate a gap/crack/whatever in the border.

I appologize for my English. I'm working on it :)

I would love to see gradients included in the next CSS spec, I didn't look too closely, so someone may have said this already... but I would very much like to be able to do the following.

Edges

drop-shadow: (distance) (opacity) (color);

corner-radius: (size);

Background

gradient: (with ability to change direction and median point i.e. begin gradient -100px or 100px);

opacity: (percentage);

These little improvements would bump up loadtime dramatically for my site. It would be great to use CSS for this, instead of loading up images. This way we can get the nice alpha transparency of PNG files, and the ability to degrade gracefully for older browsers.

In response to Ron van den Boogaard,

I think we are in agreement here, but I wanted to make sure.

I also think that CSS positioning works (for the most part) as it should, with the exception of browser compliance (or lack thereof) to CSS positioning. Therefore, I think positioning should not change so that some browsers can finally get it right before we go and change it again.

So that is what I got from your information and I happen to agree.

Now my one other question is if we make rounded corners, will images and backgrounds comply to those rounded corners?

Gradients: yes, gradients would be nice, but are non-essential. I'd love to have them as long as they didn't take time & energy away from more essential things. Really I'd like CSS to allow me to do in stylesheets just about anything that I can now do with Fireworks or Photoshop. That'd be great, but what would be the cost!? Would it make browsers way too bloated, and slow on all but the newest machines? Would it make CSS seem too complex to newbies? Gradients are to me in this category. Bring 'em on if it's not going to cost too much, and bring on just about everything else that a graphics tool can do that would make any sense to do now in our CSS rules, but not if the cost is too great. There are already good ways to manipulate images dynamically on the server if needed, and most of what we do with images is static anyway, so we don't really NEED gradients or any other things that are funamentally matters of manipulating images. But they could certainly be nice.

Curved corners are, to me, on the other hand, essential. Having to use images to achieved boxes with curved corners is—in my opinion—a kludge. Having to use images to achieve gradients is, on the other hand, natural, since gradients are generally just background images. Making gradients with images is very quick and easy, even for a novice. Making boxes with curved corners is only easy if you're following an example or have done it before, and too often this is done with tables. It totally makes sense that you should be able to specify curved corners (and YES, each corner needs to be able to be specified independently).

I know it would result in lots of web pages that look like "Word Art" (as in Microsoft Word) but if we get gradients, they should also be able to be applied to any element, not just backgrounds of boxes.

Another thing I think CSS needs is text that can be written at any angle, not just horizontally. And while we're at it, why not text along any curved path. And while we're at it, let's just merge SVG into XHTML, and style it all with CSS... but I digress...

I would like to echo the call made by Garret Murphey and others for the ability to specify whether borders applied externally or internally to an element.

This would not only be a valuable design choice to make available, but it would do wonders for developer tools like Firefox's Web Developer module that impose borders on elements to highlight them for debugging. Currently, such borders often break the layout of a closely packed page, rendering them useless. Internally applied borders would have no effect on layout and so would be desirable in this and many other cases.

Also, since I have the conch:

+ Rounded corners: Awesome. Per-corner Radii: Awesomer.
+ Gradients: I think basic gradient functionality would be a wonderful bandwidth-saver and well within the scope of what CSS should be for. I would even love to see gradients applicable to borders!
+ Defined constants ala Nathan Kitchen's comments would be huge. Being able to assign attributes a pre-defined variable instead of a named constant each time would both increase functionality and readability/ease-of-design in a potentially elegant way. One question: Can my javascript change these variable values in the DOM, and if so is it reasonable to require browsers to propogate the change throughout the rendered page?

I´m sorry if CSS already covers this or a post has already requested it for i didn´t have the time to read the whole thread but...

Is it possible to make drop shadows available?
Text borders would also be usefull in order to keep the images count minimal.

Drop shadow detailed settings would need to cover:
-global position: from where the light hits;
-distance: how far from the text does the shadow start;
-size: the thickness of the shadow;
-opacity: or transparency;
-color: the color of the shadow.

For the text-border it would be nice to have the following controls:

-size: the thickness of the border;
-color: the color of the border;
-color: the color of the border;
-opacity: or transparency.

Any coments?

Gradients
That(!) would be very usefull. Even though if it's just a simple two color gradient. "Gregory Wild-Smith" suggested a nice sheme. (with or withour the comma doesn't matter atm;)):

gradient-colors: white, red, black;
gradient-position: 0, 23, 100;
gradient-direction: 45; /* an angle/degree value would be nice*/

If you only define the gradient-colors, the colors should be "stretched" proportional. Otherwise it would be a lack in logic. Also it would be great if you can define a linear or radial gradient. But if you can set the gradient type, then we need to set the position. ie:

gradient-type: radial;
gradient-margin: auto; /* so it would appear in the mid of our block element */

thus the gradient-margin property should have then also as additional property the left, right, top and bottom "extention" according to the current margin property ;)

However: I guess this could bring up some problems with slower computers. But I'd love this property!

round corners and border-radius by corner
This is a must! Something like the FF sheme should be perfect. I think the FF specific property has a good syntax and it's a pleasure for every designer/html'er, to drop all the image related workarounds for it.

atomic backgrounds
That would be nice, but it's imho not necessary. I mean, I can't thing about a situation when I really needed it.

multiple backgrounds
THAT would be usefull too!

css version and devices related switches
right now there is no good switch for the different css versions. I'd like to have something like:

if:css2 {
html {
/* css2 related definition */
}
}
if:css3 {
html {
/* css3 related definition */
}
}

with other word a more nested css 3 would be great. Right now there are only things like:

#myID SomeElement AnotherElement {
/* my definition */
}

At least I hope the browser developper implement it correctly ;)

biophonc

Layers.

Many designers currently use extra wrapper elements to achieve some effects.
These wrapper elements have no semantic value and should not be in the xml.
All they provide to the css is an extra css-box to which one can apply styling.

The possibilities of multiple css-boxes are actually quite large. For example, the multiple background images and rounded corners are currently achieved, using extra wrapper elements in the xml. Other uses are multiple borders and drop shadows.

I'd like to specify this from within the css.

Example:
div.example (0){style for layer 0}
div.example (1){style for layer 1}
div.example (2){style for layer 2}
div.example (3){style for layer 3}

Regards,
Alwin

Hi!

Something I'd love to have is this type of syntax:

div#myDiv
{
.red { color: red; }
h2 { size: 1.1em; }
h3 { size: 1.0em; font-weight: bold; }
}

i.e. that you are able to cascade it onto children. The markup above would work better than this:

div#myDiv .red { color: red }
div#myDiv h2 { size: 1.1em; }
div#myDiv h3 { size: 1.0em; font-weight: bold; }

in my opinion - it would save time and also make it easier to read. (for example the huge number of times you have to write "ul li" when dealing with 2 or 3-level drop-down menues.

Related to Rob Mientjes' background-attachment request, a method of making an element's background stick to the edges of the page body would be useful.

ie, how an absolutely positioned element would behave on a scrolling page.

WOW there is a lot of discussion on this, too much to follow. Hopefully I won't be repeating anything.

A couple of thoughts:
1) Someone mentioned that HTML+CSS doesn't compete with Flash, SVG does. Since SVG uses CSS, its worth thinking about still.

2) Would it be useful to be able to specify an image to use for a border, perhaps with images for corners as well

3) If you are going to stretch backgrounds, you want to make sure that you can maintain aspect ratio. That means you want to control which edge is used to set the dimensions. I'm pretty sure SVG has some language to describe this.

4) An idea for handling multiple backgrounds and gradients might be to make colors and images the "same thing", tileable, stretchable, positionable things. In the case of colors, its not meaningful but it might be easy to work with:

background-image:
color(#ffaa3344),
linear-gradient(#ff00ffff, #ff00ff00, 0px 0px, 65px 100%),
url("foo.png", keep-aspect);

I changed the fonts from RGB to RGBA to make alpha gradients work. I made up the linear gradient definition (you'll need one for each type of gradient) as start RGBA, end RGBA, start X start Y, end X end Y.

I also added an argument to url(). In this case, we want to constrain the image to maintain its aspect ratio. This way you can allow the image to scale to the height and the width will maintain its aspect, either clipping or tiling, or what not.

At any rate, it seems that treating color, images and gradients as "all the same thing" might simplfy a lot of things... like borders as it would allow you to define images for borders, or gradients or what ever.

I've always thought that it woud be nice to define arbitrary patterns for borders something like:

border-pattern:
(1,2,3,2,1),
(3,1,2,1,3),
(1,2,1,2,1);
border-color: (yellow, black, lime);

would produce a 3 px thick repeating pattern of:

yellow, black, lime, black, yellow
lime, yellow, black,yellow, lime
yellow, black, yellow, black, yellow, black

The width would have to be ignored or some weird math when you have a 5px border with this pattern. 6 is ok but non-integer multiples will be a problem.

Adam

How about the ability to use a background image and then specify "stretch margins"; these would tell the image where to stretch and where to keep size, let me try and explain this a bit more graphically:

Um... yeah, the image would actually help:

http://www.neoanathema.com/i/stretchback.jpg

From taking a peek at some of the resources in OS X I believe this is how they package the images for their buttons and other GUI elements.

To do what Gill is saying, you'd only have to specify four points in the image (aside from the obvious box-model stuff) on the stylesheet ...

By using the rectangle in the center of his image (x1,y1), (x2,y2), (x3,y3), (x4,y4), the browser would then be able to disect the image, and send the four parts to repeat as designed.

#foo {
background: url('foo.png');
background-slice: [x1] [y1] [x2] [y2] [x3] [y3] [x4] [y4];
};

I'm awfully tired, but I think I got it right.

Stephen, you got it. The only thing I was thinking is if the slices require full x,y coordinates or only margins, similar to the current box model.
The simplest way to implement this is just by using margins because the "center square" is always in a rectangular shape, so:

background-slice: 3px 2px 1px 4px;

would actually make sense.
If we use x,y coordinates it opens the floodgates to different shapes, which while could bring very interesting effects might be too much to ask for the first draft of this.
Stretching rectangle/squares is pretty straightforward, but stretching irregular shapes might make some people a bit queasy =P

Just took the time to read some of the previous comments if you look at what Zephon requested up there:
http://img.photobucket.com/albums/v381/zephon/image-tile.jpg
This could also be achieved with this technique by keeping the top and bottom margins at 0.

border-radius by corner ?
Absolut, this makes life as a designer very more fun

After I thought about it, I suppose that x1 would always equal x3, etc. so the margin idea makes more sense.

We gotta make sure that the image tiles are repeated along the axis, not so much stretched. the gradient effects as most designers like to use for such objects would not turn out as expected if the image were simply stretched.

I also think the word "slice" is applicable, because designers already use the slice tool in Illustrator, Photoshop and Fireworks to make this effect by other more complicated methods.

I agree with Dave Shenk - if you can specify radius even when border:none, it should be corner-radius rather than border-radius. When specified, the border then just follows the shape of the element.

Definitely specificity by individual corner, and outer/inner border would be very nice. How about border-gradient too? In most instances it'd only be used for 3/4px, but would be a nice smooth fade out and could lead to some much more interesting designs with massive borders and good use of z-index.

Is there any mileage in negative border-radius values? Not so much for "plaque" style corners, but perhaps for a large top-left cut-out into which another rounded box would sit (with a channel between them)...

I agree with Dave Shenk - if you can specify radius even when border:none, it should be corner-radius rather than border-radius. When specified, the border then just follows the shape of the element.

Definitely specificity by individual corner, and outer/inner border would be very nice. How about border-gradient too? In most instances it'd only be used for 3/4px, but would be a nice smooth fade out and could lead to some much more interesting designs with massive borders and good use of z-index.

Is there any mileage in negative border-radius values? Not so much for "plaque" style corners, but perhaps for a large top-left cut-out into which another rounded box would sit (with a channel between them)...

Thanks for such good work, and the nice discussion...
For Gradients and shadows, and in all possibilities and directions, imho MS IE has a nice enough options.
Please do refer to http://msdn.microsoft.com/workshop/author/filter/reference/reference.asp
Anything over and above that is fabulous....

Being able to do rules like this would be great, and (i think) a clear solution to the atomic positioning you mentioned:

background-image: url(a.gif);
background-anchor: 0 150px;
background-position: 0 0;

background-image: url(a.gif);
background-anchor: center center;
background-position: bottom right;

background-image: url(a.gif);
background-anchor: 100% 100%;
background-position: center center;

background-image: url(a.gif);
background-anchor: 50% 50%;
background-position: 50% 50%;

If an background-anchor wasn't specified, or was set to 'auto', then it would default to today's functionality where it basically mirrors the background-position.

It seems to me that the multiple-background stuff is a simplistic attempt at providing a generalised system for non-interactive layers. I think that being able to specify a background in the following manner would be more flexible (and not much more complex):

HTML:background {content:url("helloworld.html")}

Then, you would put whatever background you want in helloworld.html, using all of the flexibility of HTML and CSS, including perhaps having backgrounds of the background. Of course, you would not allow background layers to affect the cursor, be selected or otherwise directly affect their containing document, as they'd be purely presentational.

It would need more design work.

A huge thank you to everyone who posted a comment. I'll be compiling the comments tomorrow and will try to summarize them as best I can. I'll post an update shortly (hopefully tomorrow) and then start on formal proposals based on all your feedback. Thanks again!

If there are going to be gradients, it would be nice to be able to link to SVG gradients, i.e.

background-image: url(svgfile.svg#gradient_in_defs);

then background-repeat, -clip, -position, etc. can be used to manipulate the gradient as if it were a regular background image (but of course, scalable). Use of SVG patterns would be nice, too. (But is all this already included with using SVG images as background images? Can an SVG document's components be referenced with a hash, etc?)

Someone above suggested clipping with EPS outlines. I suggest that using SVG clipping paths (or masks, for really impressive effects) might be better, as browsers are already beginning to support SVG. (Opera has SVG Tiny support, Firefox trunks have partial SVG support, and Safari/WebKit is working on it.)

Some people above have suggested that the syntax for multiple background images should be:

background: background 1 ;
background: background 2 ;

That doesn't make sense, as it conflicts with the CSS inheritance model. (How would you override it? Wouldn't you just add another image?)

The ability to have absolute and fixed position elements relative to their parent element instead of the screen. That'd be VERY nice.

I would agree with a lot of the opinions that multiple backgrounds would replace most of the corner and border issues. Let's face it, corner radius (and handfull of other corner styles) will only get so much mileage. But a good multiple background 'module', that makes placement a breeze would be IMO far more beneficial. It provides the designer with more flexibility (multiple borders, custom border styles, custom corners, shadows even).

And the good people developping IE won't be perplexed with a more complicated box model : )

Ron van den Boogaard: excelent post.

If background-clip was more specific then yes, it would be useful! There needs to be a way to specify coordinates to which a background layer clips, not just just what edge it should cut off at.

For instance, if you want an image to cover all but 10px on all sides but 30px on the bottom you might use: background-clip 10px 10px 30px 10px.

I would also like to be able to use only subsections of an image as a background. Is this what you meant by 'sprites'? If I use different images for the corners, sides, and background of a block then I would like to be able to save them all in one image file and specify rect coordinates for where each piece is defined.

A background-flip: [horizontal | vertical] attribute would be killer.

1. Gradients: They're really popular. Would it be a good thing to have simple gradients as a part of the spec even though you can do them today with graphics, SVG, or proprietary CSS filters?

As I posted on the W3C CSS mailing list, I believe that some kind of @-rule for simple gradients in CSS would benefit CSS in general. Though it can be done using SVG, I've always followed the opinion that the less in outer images, the better. And using an @-rule would be easier to extend in the future, in case it turns out there IS interest in having more powerful gradients in CSS.

1. Multiple Backgrounds: Everyone I know is clamoring for these, and a lot of people add extra markup, or "appropriate" other elements to do this now. What would you like to see from multiple backgrounds? Is what's in the spec now sufficient, too much, too little, etc?

As I posted on the W3C CSS mailing list, I'd like to see the ability to tell the browser whether to use the current tiling system, or to simply stretch the image into the bounding box (see later). Stretching would likely be more useful when it comes to working with vector graphics, and background-size assumes this:

iS = intrinsic image size
eS = element total size
eS = iS * n, where n is the modifier given to background-size

Also, I'd like to see some enhancements to background-position, but I'll mention those later.

1. background-origin and background-clip: Are these useful?

I'm fine with background-clip as it is. However, I feel that if W3C is going to look at allowing the author to specify the starting point of the background image positioning, then maybe it should look at the possibility of allowing the author to use a parent element as the origin of child background positioning, which would allow for a type of image positioning not easily accomplished in current CSS.

1. More atomic background positioning: I could see a use for a background position for both the image and within the element. For example, if I had an image sprite, I might want to get to position "-50px 0" of the image, position it "left bottom" within the element.

I also suggested the use of rect() and inset-rect() in background-position for more power over image positioning.

Multiple backgrounds and border-radius by corner would be nice. But then again, if you have multiple backgrounds, the use for rounded borders are redundant.

sorry about this post being all over the place but I'm in a rush.

I think the gradients should be capable of at least 3 colors (left,right,middle) and agree with an earlier comment on there being the ability of gradients to control tranparency.
Imagine combining 3 shades of blue gradient with 3 shades of gray alpha as the background color of a div with rounded corners. 60 pixels in height with 30pixel corner radius creating a rounded mac aqua pill button with no need for images :)

Multiple backgrounds are a must. I feel there should be at least: top, top-left, top-right, left, right, bottom, bottom-left, bottom-right. A friend also suggests right-top along with top-right etc, no explanation given? Or, how about near-infinite(128) multiple background images and just use background crop and position to say where they go.

I really feel that a lot of the custom filter: stuff from IE should be considered for inclusion. And ROTATED IMAGE PLACEMENT. I hated having to use flash for dynamic images just because they client wanted the image to 'tweak' a little to the left or right. Actually, any chance of being able to just arbitrarily rotate anything? Oh and IE's filter for using the same image but flipping/mirroring it would be very useful and bandwidth saving since it's the same image.

I don't think this one has to do with the specs, more with the browser developers. How about state transitions. Like I have a drop down menu. at first it's just a button, on mouse over a css drop down appears. The browser knows it has to draw from regular menu to drop down showing menu. Why can't the browser just have a default fade in transition for all such changes on the page instaed of having to animate it with javascript.

I want animated, transparent png's with rotate:-45deg; skew:33px top;

I'd like to be able to apply image map polygol like attributes to a div
and create a 5 pointed star with a background of 3 separate star fish pngs against another underwaterphoto for the background.

I just see no reason why we can't expand on what css has given us so far
and someday achieve at least the level of possibilies that I have with
illustrator, quark, and even MSpublisher & Word (rotate a square object with text in it and a background gradient!)

All browsers should support safari's drop shadow (it looks the most photoshoppish) (see Elsa Bartley above)

But back to gradients, I don't really know anthing about svg, but like
Douglas Bowman said about overlapping roles with SVG, how about I just
save a svg file that contains nothing more than my instructions for a
9 color 4 alpha gradient and apply it as the url(background) of my
100% liquid width element and have it behave as expected.

I'd really like to be able to define at the top of my css some color swatches.
like:
swatch(~logo_blue){#6cabf3}
and now wherever in my css I use background:~logo_blue;
it will be that exact hex value instead of changing multiple occurances
of #6cabf3;

I'd like to be able to resize the width and height of background images
and rotate them as well.

CSS needs an official method for 100% height.
Designers have found making a containing element position:relative;
then having an absolutely positioned element within it with
top:5px; bottom:5px; gives the desired spanning of total height of the
container with 5px of space between edges (yes 0px works fine too! yes can also be used to achieve liquide width as well as height).

A previous post mentioned backwards compatibility.
Can we just define what level of Css our files should be parsed with.
That way, should the usage of background position change, it would
have no affect on older sites since those sites didn't indicate
to parse the css as css3. It's the whole doctype thing, that works.

I'd love to be able to clip an image with text.
div {background:url(day.jpg); color:url(night.jpg)}

Doug Falby's #keyholeShape { clipping-mask:url(/masks/keyhole.eps ); stroke-clipping:true; stroke:1px solid #333; } and my idea of something
similar to an image map polygon for people without vector drawing apps!
Oh, and svg instead of eps please.

I like brad's "border-depth: 2; or something for two borders."
I often fake an effect like that in photoshop by having a 2 color
gradient with very little transition set to the stroke color.
OOOH Can we get gradient-shape burst!?
Imagine the earlier keyhole example with a large stroke and the color
of the stroke was actually a gradient that conformed to the contours
of the keyhole shape.

Btw, just ask and I can whip up some images of what this stuff would
look like if you don't have access photoshop (yeah, right)l.

George Crecoukias said: Because I don't think browsers, especialy IE, will implement all of this for years

Well, george, lets think about flash for a second. Macrmedia threw everything they could think of into flash as fast as they could and now flash has like 90% market saturation. I swear, if you woke up one day and flash was only available for konqueror, sales of VMware and downloads of knoppix would skyrocket.

If we can get the specifics of this css stuff hammered out and get it
implemented sensibly ASAP, the visual appeal of our work and the speed
and ease with which we do it would hopefully get people to upgrade
to the new IE or switch to better browsers. I know
LOTS of people with no clue how to upgrade browsers but they ALWAYS MAKE
SURE they have the latest edition of the flash plug in.

We need to tout the term CSS, get the name out there, market this sucker like flash. Sure it does wonders for accessibility and other stuff, but at the end of the day for most people it's all about being pretty. First it let us be as pretty as we wanted to be without all the headache and bandwidth of tables and spacer gifs. The next CSS should let us be prettier that we every thought possible. Let us do things we would normally decide against due to the sheer volume of images and extra per-page markup involved...even after css freed us from tables.
CSS... so pretty ... we got Little Richard in the logo.

If they can design css so well, and browser makers can implement it so well, that we web designers just can't deny the urge to happily use in every personal side project we decide to do, then sooner or later our corporate clients and their visitors are gonna begin to wonder why every business site they visit looks as lame as it did in 1999 and a whole lot of 'other' recent sites look...like they have potential but somethin's not quite right with them and they all tell you that you can use the site just fine but it would look a lot prettier if you upgraded your browser....they just might upgrade.

And for the love of God we need to standardize the dimensions, margins, and padding of form elements. And then style the hell out of them if we feel like it.

I for one hate the fact that Safari Insists on not looking like other forms. But what I hate even more is when I decide to style my submit buttons to look like safari or ANYTHING else, it looks like poop in safari.

I want every f***ing pixel on every form element imaginable to be stylable. I want to be able to style my drop down select boxes and radio's and check boxes to match the drop down menus in my site's top navigation. The flash people can do it!

hm...what else now......
oh
J King said:
wouldn't the best way to do gradient be simply to have them as a colour-value? We could have a gradient "function" as a colour-value which then can be applied to either 'background-color' or 'color'.

That's kinda like my swatch idea. I like.
and the ability to use a previously defined color swatch within a gradient.

I really like where I'm going with this swatch thing. Think about this.
The image sprite technique where you have multiple images saved as one and you just define the position on the image you want to use as the background.
if you've got 7 links in your navigation you still need to type in the
full url of that one image 7 times I believe.
why not:
link(~allnav){'../images/topnav.gif'}
and then whenever you need to use that image in the css
background:url(~allnav) no-repeat;

yes i know it's a heck of a lot like
var myvariable = 'topnav.gif'
but come on, it's not like we're doing serious php level programming with css

exclipy said something about the outside pseudo element....
exclipy needs to say some more....i'm intrigued.

Could we use a gradient() as the color of a dropshadow?

I'm with Keith Roberts on the constants thing along with my swatches. HTML has baseurl right, why can't css?

Keith Roberts ellipse suggestion NEED to be implemented like...from 5 years ago so I could have used it when I REALLY REALLY NEEDED it those times...but then again 6 years ago I didnt know about image maps.

I whole heartedly agree with Eduardo Figueiredo's div { dimension: 35em 10em;} as well as
Alexandre Roerto Pereira's sliced corners.

KEEP WORKING ON THE TEXT FLOWING CSS COLUMNS.

Mugur Padurean asked for a border fade into the background. With shape burst gradiends and the ability to use 'transparent' as a gradient color
there's your answer.

The internal border issue. Isn't there already an 'outline' border in firefox? That would be neither inside or outside and has no effect on the width of the element. Shoulnt it be easy to have an inner border just like it.

ok, damn i'm tired of reading and writing.

ok, I know my post was long as heck. But i'd hate to think it didn't get through. I just don't want to think nobody got to read what I spent so long writing...stupid as it was...

let me know when it gets reviewed and posted

If you'd left an e-mail address, I would. Thanks for the comments!

Nice stuff but I'm affraid it's to complicated for the average designer

But that aside. What I'm missing is the option to add opacity to background images. JPEGs are used quite a lot in webdesign, but they don't support alpha channels (go figure). I'm not entirely sure whether or not it's usefull.

Another thing. When I looked at the border-styles I saw that the dots where in fact round unlike current implementations. Could you add a class called squares or something alike (that shows like current browsers show the dotted style)

Last thing. When I define multiple colors to a border it's, as far as I know, not specified which color the corners (where the borders overlay) should be.

Hi, i'm brazilian and i have a very bad inglish, but i try send one sugestion.

To CSS3 border my sugestion is create four properties.

border-left-image: url(image.gif);
border-right-image: url(image.gif);
border-top-image: url(image.gif);
border-bottom-image: url(image.gif);

To create border's with images, is very good.

To background my sugestion is...

background-image[X]: url(image.gif);

X is equal a number of background-image, this is to create any images of tag or id or somewere option.

Sorry my bad inglish, but i tryed.

hi, me again, I got bored and put together some more ideas and feature requests with illustrations and actual real world examples of times when I wished I had these things and how they would have made the page building process easier.

http://thinsoldier.com/CSSwishlist/

It's still quite short and probably stuff you've already heard but I'll be adding to it as time goes on (if it doesn't slip my mind).

I've only played with this spec briefly in Safari's "experimental" implementation of it, but was disappointed to see that the very thing I wanted to do most with it didn't seem to be possible. Specifically, overlapping background images when one is set to repeat along both axes as a pattern. The image that is set to repeat and fill the entire area works just as well as always, but any attempts to overlay additional, non-repeating images on top of that pattern fail, as they simply never seem to draw. Whether this is an issue with the specification or Safari/WebKit's implementation of it, I am not sure, but it's something that should be fairly simple to implement and mandate.

I absolutely agree with you that the more features are at the designer�s disposal the better the outcome is. We are more than sure that the Internet is satiated with simple designs and the customers, these days, demand creativity and innovation. In Astra Design Company the designers work hand in hand with the html-coders to ensure the high level of final product. I have seen so many times when a designer can produce a quality design but the ideas cannot be put into the html-code because simply there are no ways to do it. And it is such a pity to explain the Client that the design s/he wants does not have a chance to survive in the html-coding.
You are doing a great job introducing new options like multiple backgrounds, etc. I will just repeat myself that the more options are there, the better the design will be!

as I think of stuff I will put it here with examples

http://thinsoldier.com/CSSwishlist/

Multiple backgrounds is an excellent idea. It's something the web community has been clamouring about for a long time.

posizionamento motori di ricerca

I would love to see gradients included in the next CSS spec, I didn't look too closely, so someone may have said this already... but I would very much like to be able to do the following.

Good CSS spec, thank you

Multiple backgrounds, gradients and border radius must be standards! :)

I'm not overly familiar with SVG, but it strikes me that much of the styling here could be handled by it, if it were possible to use that type of image as a background, with some control over positioning and stretching to fit.

I like to see options to modify the border-type "dotted".

Actually on a dotted-line every second pixel is transparent. But a lot of designs requires more flexibility: one pixel-colored and two pixel-transparent and so on...

Flexible width could also be adapted for "dashed" border-style...

What about
border-left-image: url(image.gif);
border-right-image: url(image.gif);
?

Did this ever happen? Any solutions to all of this proposed???

Thanks for the informative article