You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-text] Define "content order" for innerText #421
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]
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"...
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? :/
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.
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.
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.
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 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.
Activity
upsuper commentedon Aug 23, 2016
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 commentedon Aug 23, 2016
Oh, if node is a Text node. OK, then my comment above is a non-issue. Text node doesn't have pseudo element.
zcorpan commentedon Aug 23, 2016
Right. There are 2 tests for generated content in wpt :-)
fantasai commentedon Jan 9, 2017
zcorpan commentedon Jan 10, 2017
Isn't "document order" referring to order of DOM nodes, not order of CSS boxes?
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 commentedon Apr 19, 2017
@zcorpan, Yes, it refers to the DOM nodes. If that's not what you want then... I'm confused. :)
zcorpan commentedon Apr 20, 2017
The
innerTextalgorithm iterates over CSS boxes. If a single Text DOM node generates multiple CSS boxes, what should the order be?frivoal commentedon Mar 5, 2018
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 commentedon Mar 19, 2018
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 commentedon Mar 20, 2018
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 commentedon Mar 20, 2018
@kojiishi From CSS Display,
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: nonewill generate no text run.kojiishi commentedon Mar 20, 2018
Thanks for the pointer!
fantasai commentedon Mar 20, 2018
@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.