[css-text] Define "content order" for innerText

[zcorpan]

From whatwg/html#1679

Is "content order" for CSS boxes defined? (Step 2.5.)

https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute

If node is a Text node, then for each CSS text box produced by node, in content order, compute the text of the box after application of the CSS 'white-space' processing rules and 'text-transform' rules, let the result of these substeps be a list of the resulting strings, and abort these substeps. The CSS 'white-space' processing rules are slightly modified: collapsible spaces at the end of lines are always collapsed, but they are only removed if the line is the last line of the block, or it ends with a br element. Soft hyphens should be preserved. [CSSTEXT]

Is there anything that defines such an order?

Some tests in https://github.com/w3c/web-platform-tests/blob/master/innerText/getter-tests.js -- not sure if they are stressing this issue so much in particular though. I suppose the interesting cases are when a single Text node produces multiple CSS boxes and the order is weird? Bidi? Regions? Multicol?

cc @rocallahan

[upsuper]

Also is text in pseudo elements included? I suppose no (and I hope no). But it is not quite clear to me whether text inside pseudo elements are "CSS text box produced by node"...

[upsuper]

Oh, if node is a Text node. OK, then my comment above is a non-issue. Text node doesn't have pseudo element.

[zcorpan]

Right. There are 2 tests for generated content in wpt :-)

[fantasai]

We use the term “document order” a bunch, is that what's meant here? We don't have a formal definition of it anywhere, but I imagine that would go in Display, not Text. I'm guessing .innerText applying `text-transform` is a Web-compat requirement? :/

[zcorpan]

Isn't "document order" referring to order of DOM nodes, not order of CSS boxes?

I'm guessing .innerText applying text-transform is a Web-compat requirement? :/

I'm not sure whether it is, but apparently making it not apply would be difficult/hurt performance in implementation. See rocallahan/innerText-spec#2

[fantasai]

@zcorpan, Yes, it refers to the DOM nodes. If that's not what you want then... I'm confused. :)

[zcorpan]

The innerText algorithm iterates over CSS boxes. If a single Text DOM node generates multiple CSS boxes, what should the order be?

[frivoal]

Are you sure you mean boxes? I cannot think of any case where a single Text DOM node generates multiple CSS boxes. It may generate multiple box fragments, but that's a separate thing, and these are clearly ordered.

[tabatkins]

Yeah, a single text node always generates either 0 or 1 text runs, with no re-ordering beyond what the bidi algorithm does. (And at the level this algorithm is working at, I don't think they want the string to be bidi-reordered; they appear to want the source order. If they do want bidi-reordered text, they should just say that directly.)

So, this issues appears to be a no-op for CSS; there's nothing for us to define, the algo just needs to be be more specific (or less?) about what it wants.

[kojiishi]

a single text node always generates either 0 or 1 text runs

Curious, is this defined somewhere? At least Blink and WebKit generate any arbitrary number of text runs for a text node. We can change all relevant DOM APIs so that such text runs look like single to DOM APIs, but I wasn't aware it was defined so.

[Loirooriol]

@kojiishi From CSS Display,

each contiguous sequence of sibling text nodes generates a text run containing their text contents

So a text node will usually generate 1 text run, possibly shared with contiguous text nodes. But an empty text node or a text node inside display: none will generate no text run.

[kojiishi]

Thanks for the pointer!

[fantasai]

@kojiishi Note, what happens in your engine internally doesn't matter to CSS--you can store a single CSS-spec “text run” as however many objects you want, we're just defining here whether that bit of text exists in the render tree or not.