[css-content] content property, <image> | <url> can be just <image>

[zcorpan]

https://drafts.csswg.org/css-content/#content-property

https://drafts.csswg.org/css-images-3/#typedef-image

Since <image> expands to <url> | ..., there is no need to include <url> as well when using <image> in the Value grammar.

[dauwhe]

fixed via cbdf6c6

[fantasai]

These were called out separately because the url could in theory be other than an image, e.g. a sound file.

[plinss]

Per the definition of <image>: if the <url> doesn't point to a valid image, then it needs to be handled as an invalid image, so, yeah, we explicitly need a <url> here for non-images.

Also the there are inconsistent uses of the term URI vs URL throughout the document, recommend they all become URL.

(edited to escape < as &lt; —@zcorpan)

[SebastianZ]

These were called out separately because the url could in theory be other than an image, e.g. a sound file.

Could it be turned into a <non-image-url> then to make the difference clear?

@plinss Your comment misses the types. You need to code-format them to be displayed correctly.

Sebastian

[zcorpan]

Is there implementation interest in supporting sounds here?

[jonathanKingston]

I noticed this when trying to draft up how this would attach to the Fetch specification, ideally knowing the content type ahead of the request would be better here.

The issue with supporting sounds surely would require some clearer form of content negotation than just URL's right?

For example using URL modifiers as per the spec to be something like this:

content: url('myimg.png' content-type('image/png')),  url('mysound.ogg', content-type('audio/ogg')) / "fall back text";

Where anything else is assumed images.

For brevity the request types of fetch could be used instead:

content: url('myimg.png' type('image')),  url('mysound.ogg', type('media')) / "fall back text";

Also the <uri> is still present in <content-list> this should probably be changed to <image> right?

[tabatkins]

Yeah, lacking an actual definition of how we would content-negotiate non-image things, this should be specialized to <image> for now. It can be expanded to handle other types as we actually allow them, likely with specialized functions akin to image().