rocallahan / innertext-spec Goto Github PK

I think the spec needs to define why the following DIV has an empty textContent (more clearly if this is already covered)

<div>
    <select><option>X</option><option>Y</option><option>Z</option></select>
</div>

I think the <option> descendants of a <select> should be able to return their text, just like <button> can. (See note about replaced elements in the section on Getting innerText.)

According to bug 1290937 this is required for web compatibility, and both Chrome and Edge apparently support it. (I didn't test Edge personally.)

In addition, once the <option> elements support innerText, the only reasonable behavior (IMO) for the parent <select> is to return the concatenated list of innerTexts of its children.

In bug 1290937, we're fixing Gecko to implement these changes (and updating the web-platform tests accordingly).

(Blink currently returns empty for the <select>'s innerText, even when it returns the actual text for an <option> within it, but I've filed a Chromium issue about that.)

Can you provide innerText javascript implementation that takes a HTML (as string), or a root DOM node and outputs the innerText?

Maybe you could add a test for successive <pre> items? E.g:

<pre>line1</pre><pre>line2</pre>

The reason is that while Firefox (46.0a1) gets this correct (IMO i.e. a single newline between the texts) when it comes to innerText, it puts two newlines between them when doing a Copy. So adding a test would I think help clarify what the "correct" behavior is

As rendered, an explicit newline at the end of a block collapses with a "required newline". Consider

<div>line1<span>&#xA;</span></div><div>line2</div>

This is rendered (in my experience) with no blank line in between.

If you want to model this, perhaps tweak the specification a bit. For example replace item 5 by:

For each remaining run of consecutive "required line break count" items calculate the maximum of the values in the "required line break count" items. Subtract one if the previous item is a string that ends in a newline. Replace the run with a string consisting of that many newline characters.

or by:

Replace each remaining run of consecutive "required line break count" items with a string consisting of as many newline characters as the maximum of the values in the "required line break count" items, subtracted by one if the previous item is a string that ends in a newline.

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.