[css-content] content: "" should probably generate no text nodes

[emilio]

... because an empty text node would generate a baseline. Here's a test-case that shows the difference on Chromium (because Chromium has a bogus optimization that prevents an empty text node from having a layout box unless editable).

https://drafts.csswg.org/css-content/#strings is not particularly clear on what exactly the generated DOM would look like for content: "". Right now browsers differ but not generating a text node seems reasonable behavior, and we'd be willing to align Firefox with other browsers assuming the spec is updated to be explicit about this.

This came up in https://bugzilla.mozilla.org/show_bug.cgi?id=1855583

cc: @dshin-moz, @tabatkins, @fantasai

[dbaron]

Hmmm. I'm not sure about your assertion that an empty text node should generate a baseline. I don't think CSS should care about text node boundaries -- from a CSS perspective the rendering should be the same no matter how many adjacent text nodes the same text is split into. And I think it follows from that that an empty text node shouldn't affect the rendering.

[Loirooriol]

https://drafts.csswg.org/css-display-3/#intro

If the sequence contains no text, however, it does not generate a text sequence.

So if no text sequence (a.k.a text run) is generated, the baseline is not affected.

[emilio]

Hmm, yeah, thanks for catching that, I didn't find that piece of text :)

I was talking about existing browser behavior (all browsers seem to generate a baseline for an empty text node, if you coerce them to generate a text box).

But yeah I guess the spec is clear, and all that's left is really filing / fixing browser bugs. That said more clearly state the expected generated content would be great IMO.