should the innerText getter require layout? #2
Description
As currently written the spec requires layout for only one reason: because a CSS ::first-line rule may apply text-transform, which affects innerText, and you need to know where that line breaks to know which characters get transformed. It might be a good idea to eliminate this requirement. (Note: currently Webkit/Blink don't support text-transform in ::first-line rules even for rendering; this is clearly an engine bug.)
The main reason to eliminate it would be to improve potential performance.
On the other hand, the spec is designed to reuse as much CSS machinery as possible, especially CSS box construction and white-space processing. The natural implementation approach is to also reuse as much of the engine CSS implementation as possible (and that's what I did in Gecko). That processing normally occurs during layout, and making it usable outside layout just for the purposes of innerText is probably not something engine developers would want to do. Even if the spec did not depend on layout, I'd still want to perform layout in Gecko so innerText can reuse the results.
The tension becomes more obvious if you consider concrete changes to eliminate the layout requirement. An obvious fix would be to say that ::first-line rules are not applied when computing innerText. But that would mean in Gecko we cannot use layout information any longer; we'd have to explicitly recompute some information to get different results for innerText, which would add significant complexity --- and might actually hurt performance in the case where the layout is already up to date.
Lacking concrete use-cases where innerText requiring layout has major performance impact, I opted for the simplest approach.