Add child text content and its change steps #466
Conversation
domenic
force-pushed
the
child-text-content-changed
branch
from
5e89547
to
863e685
Compare
Part of fixing whatwg/html#2752. The "child text content" concept was previously defined in HTML, but is being moved here.
domenic
force-pushed
the
child-text-content-changed
branch
from
863e685
to
3d71dad
Compare
This fixes #2752, where it was revealed that most browsers do not care about the textContent of a textarea, but instead about its child text content. That is, if you use the DOM APIs to insert a child element into the textarea element, its text does not show up for editing or as part of the value and defaultValue properties (even though it shows up in textContent). This moves to a model where textareas operate entirely on the child text content. This matches Blink and Gecko, and somewhat matches WebKit. This also fixes #2750, by using the newly-introduced "child text content change steps" hook introduced to DOM in whatwg/dom#466.
|
I think the change in "insert" at least is wrong if node is a |
|
Probably move the check into step 6? |
|
I think it would be good if @annevk reviewed this also. |
|
Does |
It should not, unless there are edge cases of normalize() that I am not aware of. My understanding is normalize() is basically figuring out the minimal set of text nodes to represent the exact same child text content, so the child text content will not change. I'll add a note to that effect. |
|
We should probably test that as normally even no-op changes trigger mutation records. And this is more than a no-op (although quite similar). |
|
Hmm, what kind of test do you mean? For the textarea case there would be no difference between running the steps, or not. Running the steps unnecessarily just updates the API value to be itself, which is unobservable. |
|
I guess if we don't have any endpoint where it can observed it does not matter. |
This fixes #2752, where it was revealed that most browsers do not care about the textContent of a textarea, but instead about its child text content. That is, if you use the DOM APIs to insert a child element into the textarea element, its text does not show up for editing or as part of the value and defaultValue properties (even though it shows up in textContent). This moves to a model where textareas operate entirely on the child text content. This matches Blink and Gecko, and somewhat matches WebKit. This also fixes #2750, by using the newly-introduced "child text content change steps" hook introduced to DOM in whatwg/dom#466.
This fixes whatwg#2752, where it was revealed that most browsers do not care about the textContent of a textarea, but instead about its child text content. That is, if you use the DOM APIs to insert a child element into the textarea element, its text does not show up for editing or as part of the value and defaultValue properties (even though it shows up in textContent). This moves to a model where textareas operate entirely on the child text content. This matches Blink and Gecko, and somewhat matches WebKit. This also fixes whatwg#2750, by using the newly-introduced "child text content change steps" hook introduced to DOM in whatwg/dom#466.
Part of fixing whatwg/html#2752. The "child text content" concept was previously defined in HTML, but is being moved here.
Probably shouldn't merge this until the corresponding HTML PR is ready and approved, in case there are some integration issues I missed out on, but I think this is reviewable as-is.
Preview | Diff