rendering strings with newlines is inconsistent on re-rerender #1080
Comments
|
We switched to use |
|
I'm switching it back (D1174395), but regardless, this is an innerText issue. Browsers that don't have textcontent (ie8) suffer |
|
looks like this was brought up in #923 |
|
Right, we should also do the right thing in IE8. |
|
jQuery empties then adds a text node. Relevant commits: jquery/jquery@866187f |
|
okay interesting. I'll do this for ie8 |
|
@jbonta I have a patch almost ready. |
reverts 23ab30f because the issue it fixed doesn't seem to be a problem anymore. textContent should be better for more things anyway, as the original 309a88b indicates. It should be faster because innerText requires layout. This also allows us to use strings with newlines in our rendered output and have confidence that they will render the same on subsequent re-renders. This is especially useful for es6-style backtick multi-line strings. This will be more consistent as textContent is supported almost everwhere so we won't have differing behavior between webkit and firefox. see #1080
|
@spicyj I'm curious if https://github.com/facebook/react/blob/master/src/browser/ReactDOMIDOperations.js#L144 is a simpler solution to the newline problem (for IE8), or if that only works for innerHTML. |
|
hmm interesting. We definitely want to preserve whitespace though. (because of |
reverts 23ab30f because the issue it fixed doesn't seem to be a problem anymore. textContent should be better for more things anyway, as the original 309a88b indicates. It should be faster because innerText requires layout. This also allows us to use strings with newlines in our rendered output and have confidence that they will render the same on subsequent re-renders. This is especially useful for es6-style backtick multi-line strings. This will be more consistent as textContent is supported almost everwhere so we won't have differing behavior between webkit and firefox. see facebook#1080
reverts 23ab30ff873fba816129cafa0c40112dd2ee990d because the issue it fixed doesn't seem to be a problem anymore. textContent should be better for more things anyway, as the original 309a88bcf62c1c64a2b91c0eb753c19209a425b2 indicates. It should be faster because innerText requires layout. This also allows us to use strings with newlines in our rendered output and have confidence that they will render the same on subsequent re-renders. This is especially useful for es6-style backtick multi-line strings. This will be more consistent as textContent is supported almost everwhere so we won't have differing behavior between webkit and firefox. see facebook/react#1080
On re-render, we sometimes use innerText. This causes inconsistencies in rendering whitespace. See demo:
http://jsfiddle.net/nbA2M/
We should make sure this doesn't happen.
The text was updated successfully, but these errors were encountered: