[css-content] Clearer syntax for alternative text for content

[dot-miniscule]

The spec states that alternative text can be supplied for CSS generated content with the following syntax:

.new::before {
 content: url(./img/star.png) / "New!";
}

While there is developer support for this feature, it is not obvious to the content author what the purpose of the alt text declared in style is for. This has led to the suggestion that wrapping the alternative text it in alt() would make the intended purpose much more obvious and meaningful:

.new::before {
 content: url(./img/star.png) / alt("New!");
}

It looks like this was originally discussed/considered, and it would be good to revisit this. I was unable to find any specific justifications as to why the alt() syntax was passed over in favor of what's in the spec so I'd just like to open it up to discussion now. Depending on the outcome of discussion, I'd be happy to draft a PR on the spec to update the syntax.

Concerns from TAG review of this syntax can be seen here: https://lists.w3.org/Archives/Public/www-style/2016May/0109.html

[Crissov]

A single textual alternative may also not always cut it.

.new::before {
 content: 
  /* preferred image */ url(sprites.svg#star) /
  /* alternative file format*/ url(star.png) /
  /* alternative emoji */ "\1F195" /
  /* alternative symbol */ "☆" /
  /* alternative text for TTS */ "New!";
}

It may be better to consolidate at least some of that functionality within the image() function introduced with level 4 of CSS Images.

[alice]

It definitely seems like image() could use some alt functionality.

Since not everybody will use image() in content, I think it still makes sense to have the feature described here, where an author may provide a single text alternative for a content property.

Should we file a separate issue for text alternatives for image()?

[AmeliaBR]

Regarding the alt() proposal: functions in CSS serve to transform data, not to label it. Most functions can be used in many different properties, creating a new data type.

The alt() wrapper might help a developer understand unfamiliar code, but once they are familiar with it, it will just become extra characters to type.

(And quite frankly, the main obstacle to developer familiarity right now is lack of browser support!)

Regarding Christoph's comment, to clarify: you are suggesting that alt text is conceptually another type of fallback, just like different image formats? That may be relevant for content, but not in general for images in CSS. How would a text fallback be used for background images or border images or mask images? So I think it's best to keep image fallbacks (the image() and image-set() functions) separate from alternative text (which is used for accessibility even when an image is displayed).

[fantasai]

+1 to everything @AmeliaBR said.

Wrt the other concerns in the linked message:

• We're not using a separate property because the alt value needs to cascade together with the non-alt value. This was explained earlier in the thread.
• We didn't want to use the comma-based syntax because we wanted to make it clear that this isn't a fallback value: alt text is used in conjunction with the rendered value. That's why we used a slash rather than a comma.