"Applies to: all elements" should mean the property applies to ::before and ::after

[dbaron]

I thought there was text somewhere that says that "Applies to: all elements" means that it applies to elements and to the ::before and ::after pseudo-elements (or similar for "Applies to: block-level elements", "Applies to: elements that establish block formatting contexts", etc.).

However, I can't find any such text.

It's possible that the text belongs in css-pseudo, although I tend to think it might belong where we define the "Applies to" line (see also speced/bikeshed#617), or in both places.

[Loirooriol]

The current approach is so confusing. The text says "all elements", the tooltip says "Includes ::before and ::after pseudo-elements", and the link points to https://drafts.csswg.org/css-pseudo/#generated-content.

The tooltip info should appear as text, and only the part that mentions pseudo-elements should link to https://drafts.csswg.org/css-pseudo/#generated-content.

[fantasai]

@tabatkins Mind noting what edits you had in mind?

[tabatkins]

An explicit anchor to point to that talks about how tree-abiding pseudos are counted as "all elements" along with all the real elements (rather than just pointing to the general section on generated content).

[fantasai]

@tabatkins Well, it's not all 'tree-abiding' pseudo-elements, only :before/:after... But maybe a section explaining specializations of applies-to for pseudo-elements, sure.

[fantasai]

Added a dfn for “applies to” to css-cascade, and added a note about what “all elements” means wrt pseudo-elements. This gives us an anchor to point at.

@tabatkins Thinking about also adding

(When a property does not [=apply to|apply=], this means it has no formatting effect on that box or element.)

to css-cascade, but debating a bit whether to add it in parentheses or not, and whether to add it before or after the flex example. Thoughts?

[frivoal]

The precise effect of "applying" or "not applying" tends to vary a fair bit. The statement you wrote is generic enough that it's probably fine in all cases, but I wouldn't add it, as I am not sure it helps more than it hurts when it comes to gray zones and other ambiguities.

For instance, css-text has a bunch of things that apply to inline boxes. If you try and apply them to block boxes, it inherits into the (possibly anonymous) inline boxes, and has an effect that way. This is not in contradiction with the statement you made, since indeed, there is no effect on the block box, and its only through inheritance that anything happens, but the statement does not shed any light on this situation.

Another one would be writing-mode and text-orientation, which don't apply to various table parts, yet still influence the calculation of font relative length units on these same elements through the computed value. Still not necessarily a contradiction if you're strict about it, but not really helping either.

[fantasai]

@frivoal Wrt the first point, this is the Cascading and Inheritance module, we should be able to assume you understand the difference between applying to a box and inheriting to descendants.

Wrt the second point, the font properties have similar issues. They only apply to text, except insofar as the affect the font-relative units. I think that's a separate issue we can file, about how we want to handle such things.