Is there a CSS box for text node content?

[npm1]

I'm not sure what the right venue is for asking this question - apologies if this is not it.

In w3c/element-timing#33 @bzbarsky points out that text nodes do not have a "border box". In the Element Timing API, we want to use a box which represents the space occupied by a text node. However, I'm not sure if there is any way to obtain that from CSS. I think it would be better from CSS instead of relying on font-specific concepts which will be hard to describe and might not be efficient to implement. Thanks in advance!

[kojiishi]

Good point. I think the best one is "the content area of the text run", see:
https://drafts.csswg.org/css2/visudet.html#inline-non-replaced

As the spec above says, it is not defined, and the results vary by browsers/platforms, but it gives the box the UA uses to layout the line on that platform.

[bzbarsky]

Text runs are not "non-replaced inline boxes" either, though...

[kojiishi]

Oh, good point too, you're right. The section name is old and not accurate, but "the content area of the text run" is still useful for this case, no? I think CSS specs use it in a few places already, such as in text decorations.

[bzbarsky]

Using the "content area of the text run" would make some sense, yes (with the obvious caveat that the text can paint outside that content area, etc). It would be best if this content area were clearly defined somewhere, esp if specs are using it already.

[AmeliaBR]

I think the definition you're looking for is the root inline box of the block container, as defined in CSS Inline Layout 3:

which is an anonymous inline box that holds all of its inline-level contents. The root inline box inherits from its parent block container, but is otherwise unstyleable.

However, note that this box isn't associated with individual DOM text nodes. If you have been manipulating the DOM in a way that you have multiple consecutive text nodes, they are merged for all CSS layout. I'm not sure if that's relevant for the API you're working on.

[npm1]

It sounds to me like a root inline box could contain content besides text, so it might not work for block containers that contain text and additional content. @kojiishi has suggested using 'the union of the content area and glyph bounding boxes', which seems reasonable to me. Any objections to that terminology?

[bzbarsky]

Do you want to include ink overflow in your box or not?

[npm1]

I think we'd like to, yes, since that corresponds to what the user sees.

[fantasai]

Can you explain what you're trying to do?

[npm1]

Currently, Element Timing computes an intersectionRect by looking at 'border box' of text nodes[1], but that's not a thing so we need to change the description. Is there a CSS box describing the amount of space occupied by a text node?

The suggestions above were:

• Use content area of the text run. It seems reasonable, albeit not really well defined anywhere.

• Skip text altogether and instead use the root inline box of the block container. This could be much larger than what we want if there's content besides text in the container.

[1] https://wicg.github.io/element-timing/#sec-report-text

[fantasai]

@npm1 I still have no idea what you're trying to do. Why are you trying to key off text nodes instead of elements?

[npm1]

For a given set of text nodes, we want to express the smallest rect that contains the space occupied by those nodes within the viewport. We don't key off of elements because elements can contain more than just text and hence it seems to me that any rects from elements will be larger than what we want. Perhaps this is a wrong assumption...

The set of text nodes that are grouped together is determined by looking at the containing block: https://wicg.github.io/element-timing/#sec-modifications-CSS. That seems hand-wavy too.

[frivoal]

Would there be something wrong with considering that each text-run which is not the sole child of an inline box is wrapped in an anonymous inline box (which would then have a content area, a border box, and all the other things boxes have)?

This seems consistent with https://drafts.csswg.org/css-display-3/#block-container:

Since a block container contains "only inline-level boxes participating in an inline formatting context, or contains only block-level boxes participating in a block formatting context", then either text nodes are inline-level boxes (which means they are boxes, and you can talk about their border box), or they are thus implicitly wrapped in anonymous inline boxes (in which case you can talk about the border box of those).

As far as I can tell, the presence of these anonymous wrappers is non observable, so defining them into existence should cause no issue, but it gives us some well defined concept to talk about in cases like the one raised by @npm1.

(In the original comment, speaking of the content box or border box would then be identical, since in the absence of selectors that can target those boxes, the padding and border width would always be 0.)