Upstream the innerText spec #1678
Conversation
From https://rocallahan.github.io/innerText-spec/ with no normative changes except adding [CEReactions] to the IDL. Fixes #465.
| <code>select</code>, and <code>video</code> — but not <code>button</code>) are not rendered | ||
| by CSS, strictly speaking, and therefore have no CSS boxes for the purposes of this algorithm.</p> | ||
|
|
||
| <p class="big-issue">This algorithm is amenable to being generalized to work on a <span |
annevk
Aug 17, 2016
Member
"a ranges" -> "a range" | "ranges"
"a ranges" -> "a range" | "ranges"
| <li><p>Return the concatenation of the string items.</p></li> | ||
| </ol> | ||
|
|
||
| <p class="note">Note that descendant nodes of most replaced elements (e.g. <code>textarea</code>, |
annevk
Aug 17, 2016
Member
comma after e.g.
comma after e.g.
| these steps:</p> | ||
|
|
||
| <ol> | ||
| <li><p>If the element is not <span>being rendered</span>, return the same value as the |
annevk
Aug 17, 2016
Member
@domenic and I started using "this element" (or equivalent) in other algorithms. I think that would be a clearer way to refer to the object on which the IDL attribute is defined.
@domenic and I started using "this element" (or equivalent) in other algorithms. I think that would be a clearer way to refer to the object on which the IDL attribute is defined.
| <li> | ||
| <p>Compute a list of items each of which is a string or a "required line break count", a | ||
| positive integer, by applying the following recursive procedure to each child node | ||
| <var>node</var> of the element in <span>tree order</span> and concatenating the results. |
annevk
Aug 17, 2016
Member
Make this end in parenthesis?
Make this end in parenthesis?
zcorpan
Aug 17, 2016
Author
Member
Hmm I suppose " and concatenating the results" should be removed here.
Hmm I suppose " and concatenating the results" should be removed here.
zcorpan
Aug 17, 2016
Author
Member
Hmm, no this should still be there. Each child produces a list, and we want to concatenate those lists into one...
Hmm, no this should still be there. Each child produces a list, and we want to concatenate those lists into one...
| <var>node</var> of the element in <span>tree order</span> and concatenating the results. | ||
| (Intuitively, a "required line break count" item means that a certain number of line breaks must | ||
| appear at that point, but they can be collapsed with the line breaks induced by adjacent | ||
| "required line break count" items, reminiscient to CSS margin-collapsing.)</p> |
annevk
Aug 17, 2016
Member
This looks like a note, mark it up as such and avoid normative requirements?
This looks like a note, mark it up as such and avoid normative requirements?
| of <var>node</var> and concatenating the results (producing a list of items).</p></li> | ||
|
|
||
| <li><p>If <var>node</var>'s <span>computed value</span> of <span>'visibility'</span> is not | ||
| 'visible', return <var>items</var>.</p></li> |
annevk
Aug 17, 2016
Member
then return*
then return*
| 'visible', return <var>items</var>.</p></li> | ||
|
|
||
| <li> | ||
| <p>If <var>node</var> is a <code>Text</code> node child of an <code>rp</code> element, return |
annevk
Aug 17, 2016
Member
then return*
then return*
annevk
Aug 17, 2016
Member
This happens a few more times.
This happens a few more times.
| only removed if the line is the last line of the block, or it ends with a <code>br</code> | ||
| element. Soft hyphens should be preserved. <ref spec=CSSTEXT></p></li> | ||
|
|
||
| <li><p>If <var>node</var> is a <code>br</code> element, append a string containing a single |
annevk
Aug 17, 2016
Member
then append
then append
| <li><p>Delete any string items whose strings are empty.</p></li> | ||
|
|
||
| <li><p>Delete any runs of consecutive "required line break count" items at the start or end of | ||
| the list.</p></li> |
annevk
Aug 17, 2016
Member
This should presumably do some starts with matching? We only add "required line break count of ..." after all.
This should presumably do some starts with matching? We only add "required line break count of ..." after all.
zcorpan
Aug 17, 2016
Author
Member
I don't follow.
I don't follow.
annevk
Aug 17, 2016
Member
The string being added is "required line break count of 2" / "required line break count of 1", not this string.
The string being added is "required line break count of 2" / "required line break count of 1", not this string.
zcorpan
Aug 17, 2016
Author
Member
Ah, I see. Those items are not strings. They are integers, basically. I suppose it could be made less confusing...
Ah, I see. Those items are not strings. They are integers, basically. I suppose it could be made less confusing...
|
|
||
| <p>Returns the element's text content "as rendered".</p> | ||
|
|
||
| <p>Can be set, to replace the element's children with the given value, but with linebreaks |
annevk
Aug 17, 2016
Member
line breaks
line breaks
| steps:</p> | ||
|
|
||
| <ol> | ||
| <li><p>Let <var>document</var> be the given element's <span>node document</span>.</p></li> |
annevk
Aug 17, 2016
Member
this element's
this element's
| <li><p>Let <var>fragment</var> be a new <code>DocumentFragment</code> object whose <span>node | ||
| document</span> is <var>document</var>.</p></li> | ||
|
|
||
| <li><p>Let <var>input</var> be the new value being assigned.</p></li> |
annevk
Aug 17, 2016
Member
"the new value being assigned" -> "the given value"
"the new value being assigned" -> "the given value"
|
This looks okay. The only thing I'd consider changing further is making the recursion less declarative. Have that be some algorithm that is invoked for each child and also put the result in a variable of some kind the rest of the algorithm uses. Will let @domenic make the call on that. |
|
Yeah, it could use some more cleanup. Possibly also switch to iterative traversal instead of recursive? But I think the current state is OK to merge and I can fix more later. |
| @@ -11962,6 +11974,175 @@ interface <dfn>DOMStringMap</dfn> { | |||
| </div> | |||
|
|
|||
|
|
|||
| <h4>The <code data-x="dom-innerText">innerText</code> IDL attribute</h4> | |||
domenic
Aug 17, 2016
Member
I wonder if a better title might be something like Manipulating an element's "as rendered" text? It seems to me like other section titles usually don't talk about a specific IDL attribute. I don't feel strongly though.
I wonder if a better title might be something like Manipulating an element's "as rendered" text? It seems to me like other section titles usually don't talk about a specific IDL attribute. I don't feel strongly though.
zcorpan
Aug 17, 2016
Author
Member
It's a bit of a mix currently. Having "innerText" in the heading makes it easier to find. But if we also add outerText we can maybe change the heading at that point.
It's a bit of a mix currently. Having "innerText" in the heading makes it easier to find. But if we also add outerText we can maybe change the heading at that point.
| <p>Can be set, to replace the element's children with the given value, but with line breaks | ||
| converted to <code>br</code> elements.</p> | ||
|
|
||
| </dl> |
domenic
Aug 17, 2016
Member
Should we add a warning about how developers usually want to use textContent instead?
Should we add a warning about how developers usually want to use textContent instead?
zcorpan
Aug 17, 2016
Author
Member
I don't know, it's not clear to me that is usually true. For getting, innerText seems a lot more useful if you want the text but not the contents of scripts and don't want formatting of the HTML source to affect the given text. For setting, you would have to use <pre> but you might want spaces to collapse or don't want monospace font, or you could use <p> with white-space: pre-line (or so) but then you rely on CSS to preserve presumably important line breaks.
textContent is gives more consistent results cross-browser, though.
I don't know, it's not clear to me that is usually true. For getting, innerText seems a lot more useful if you want the text but not the contents of scripts and don't want formatting of the HTML source to affect the given text. For setting, you would have to use <pre> but you might want spaces to collapse or don't want monospace font, or you could use <p> with white-space: pre-line (or so) but then you rely on CSS to preserve presumably important line breaks.
textContent is gives more consistent results cross-browser, though.
|
|
||
| <p class="note">Intuitively, a <i>required line break count</i> item means that a certain number | ||
| of line breaks appear at that point, but they can be collapsed with the line breaks induced by | ||
| adjacent integer items, reminiscient to CSS margin-collapsing.</p> |
domenic
Aug 17, 2016
Member
s/integer items/required line break count items?
Spelling is "reminiscent"
s/integer items/required line break count items?
Spelling is "reminiscent"
| list of items.</p></li> | ||
|
|
||
| <li><p>If <var>node</var>'s <span>computed value</span> of <span>'visibility'</span> is not | ||
| 'visible', then return <var>items</var>.</p></li> |
domenic
Aug 17, 2016
Member
I guess this is the same concern as the factoring thing @annevk mentioned, but saying "return" inside a getter and that not being the result of the getter is pretty confusing. "Let the result of these substeps be items and abort these substeps"? Meh...
I guess this is the same concern as the factoring thing @annevk mentioned, but saying "return" inside a getter and that not being the result of the getter is pretty confusing. "Let the result of these substeps be items and abort these substeps"? Meh...
zcorpan
Aug 17, 2016
Author
Member
Yeah... I went with your suggestion for now but it's not great.
Yeah... I went with your suggestion for now but it's not great.
|
|
||
| <li> | ||
| <p>If <var>node</var> is a <code>Text</code> node child of an <code>rp</code> element, then | ||
| return a single string item containing the text of <var>node</var>. |
|
|
||
| <li><p>If <var>node</var>'s <span>computed value</span> of <span>'display'</span> is | ||
| <span>'table-cell'</span>, and <var>node</var>'s CSS box is not the last | ||
| <span>'table-cell'</span> box of its enclosing 'table-row' box, then append a string containing |
domenic
Aug 17, 2016
Member
<span> around 'table-row'?
<span> around 'table-row'?
|
|
||
| <li><p><span data-x="concept-node-append">Append</span> the result of <span | ||
| data-x="create an element">creating an element</span> given <var>document</var>, | ||
| <code>br</code>, and the <span>HTML namespace</span>, to <var>fragment</var>.</p></li> |
domenic
Aug 17, 2016
Member
No comma after HTML namespace, I think
No comma after HTML namespace, I think
|
LGTM. I think the original commit message is a bit outdated so I'll let you merge and write up a commit message. Also probably want to reference #1679 |
|
I assume there will be tests for this in wpt. |
|
@smaug---- there were tests in wpt already, and I have submitted these PRs to update them so far: |
From https://rocallahan.github.io/innerText-spec/ with no normative
changes except adding [CEReactions] to the IDL.
Fixes #465.
@Ms2ger @rocallahan