[css-images-4] image() function for solid colors needs more thought

[faceless2]

If you're going to allow creation a solid-color image with the new image() function:

div { background: image("missing.png" black) }

You'll have to specify the width and height too; it's required for every situation except the one given in the example, where the image is a background-image and repeating in both axes. A specific example:

#bullet { content: image("missing.png" black); } /* what size is it ? */

In addition, if this functionality exists then it should be a "first class" image type, not just there as a fallback when a image fails to load from a URL. You're not preventing anything with this restriction, just making the CSS unnecessarily more complex:

div { content: image(blue); }   /* what, I can't do this?!?! */
div { content: image("about:invalid", blue); }   /* fine, I'll do this instead */

Finally, while a generated solid-color image is a nice idea for anyone creating test-cases, the apparent goal (preventing background-color leak-through under a translucent background image while still setting a background if the image is missing) is pretty specific and could probably be achieved in an easier way. The example from the current draft:

body      { color: black; background: white; }
p.special { color: white; background: image("dark.png", black); }

could perhaps be achieved with a "final" (or maybe "stop") ident after the last image in the background stack, to prevent the processing of any further layers in the background if it's successfully loaded. So you could do something like this:

body      { color: black; background: white; }
p.special { color: white; background: image("dark.png") final, black); }

Whether that's an improvement or not largely depends on whether there's any other useful purpose for these solid-color images.

[tabatkins]

You'll have to specify the width and height too;

No, it's just a dimensionless image, same as an SVG with no width/height/viewBox attributes. It thus stretches to fill the painting area.

In addition, if this functionality exists then it should be a "first class" image type, not just there as a fallback when a image fails to load from a URL.

That definitely already works. image(blue) is totally valid per the syntax, and does what you expect it to do.

Finally, while a generated solid-color image is a nice idea for anyone creating test-cases, the apparent goal (preventing background-color leak-through under a translucent background image while still setting a background if the image is missing) is pretty specific and could probably be achieved in an easier way.

That's the primary goal, yes, but there are other use-cases for being able to declaratively generate solid-color images, such as for filter inputs; SVG has the <solidColor> filter element specifically for this reason.

could perhaps be achieved with a "final" (or maybe "stop") ident after the last image in the background stack, to prevent the processing of any further layers in the background if it's successfully loaded.

The primary use-case applies to many more properties than just 'background-image'. We'd have to figure out some way to apply this approach to all of them, including places that take a single <image> rather than a list. image(), on the other hand, automatically works everywhere that takes an image, and the fallback behavior is a natural extension of the existing "provide multiple URLs" fallback behavior.

[faceless2]

Sorry Tab, my error. A dimensionless image makes sense and I had missed that url was optional in the syntax.