[css-content][css-pseudo]::before and ::after a void element

[AndySky21]

Is it possible to add before and after pseudo elements to void elements with a string / attribute content? If no, why?

[SelenIT]

Wouldn't it be useful also to define the behavior of ::before and ::after for void and (especially) replaced elements more specifically, with regard to the current behavior of the browsers? E.g., all browsers currently support these pseudo-elements for hr (and hr::before { content: "\2727\2003\2003\2727\2003\2003\2727"; } is widely used in the new design of W3C specs themselves), although this element is defined as void in HTML. Also, almost all browsers don't apply them to regular img elements, but do apply for broken imgs (https://bitsofco.de/styling-broken-images/). Since regular and broken images differ in their browser Shadow DOM structure (at least in Blink browsers), maybe the behavior of pseudo elements also could be described in Shadow DOM terms?

[xgqfrms-GitHub]

https://lists.w3.org/Archives/Public/public-css-archive/2016Oct/0358.html
https://lists.w3.org/Archives/Public/public-css-archive/2016Oct/0358.html

hr::before { content: "\2727\2003\2003\2727\2003\2003\2727"; }

what's this mean \2727\2003\2003\2727\2003\2003\2727 ???
Are they Unicode charset ???

[Crissov]

Yes

hr::before {content: "✧  ✧  ✧" /* U+2727 White Four Pointed Star, U+2003 Em Space */;}

[xgqfrms-GitHub]

thanks for reply!

[fantasai]

Closing per @SelenIT's reply in #625 (comment)

FWIW: Replaced elements replace all the content of the element, including ::before and ::after pseudo-elements, that's why it doesn't work on them. When images are rendered as their alt text, they're no longer replaced.

[equinusocio]

This issue should be updated since almost all browsers allows (for some reason) pseudo-elements on input[checkbox] and input[radio]

[SelenIT]

Replaced elements replace all the content of the element, including ::before and ::after pseudo-elements, that's why it doesn't work on them.

Shouldn't this great explanation be somewhere in the spec itself, probably near the definition of ::before and ::after in [css-pseudo-4]? The current situation, where CSS2.x just "doesn't fully define" the behavior of them with replaced elements, and the only place clearly disallowing them seems to be the note in [css-content-3] in the section about a rather specific case of the replaced elements, is often confusing for authors.

Also, there are still some inconsistencies between replaced element definitions in CSS and in HTML. For example, the HTML spec lists all form controls except <input type="image"> among non-replaced elements, but [css-images-3] contains a phrase "some types of replaced elements, such as form controls". I'm afraid that these inconsistencies still often lead to confusion about the status of the form controls (and whether they should support ::before/::after or not).

[gsnedders]

Reopening based on @SelenIT's comment above; while @fantasai can assert that's the case we:

1. don't seem to have a normative requirement making it so, and
2. don't have any tests for this.

[fantasai]

The normative requirement is in the statement that

When their computed content value is not none, these pseudo-elements generate boxes as if they were immediate children of their originating element, with content as specified by content.

But I added an extra statement about this anyway, since it seems to be a point of confusion.