Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.innerText doesn't add \n newlines like browser does #344

Closed
devinellis opened this issue Jan 28, 2022 · 5 comments · Fixed by #574
Closed

.innerText doesn't add \n newlines like browser does #344

devinellis opened this issue Jan 28, 2022 · 5 comments · Fixed by #574
Assignees
Labels
bug Something isn't working high priority

Comments

@devinellis
Copy link

First, let me say thanks for your work on HappyDOM, I'm really happy with the performance. I'm using it to feed Mozilla's Readability library to extract articles from HTML documents.

Steps to Reproduce

document.body.innerHTML = '<div>The <strong>quick</strong> brown fox</div><div>Jumped over the lazy dog</div>'
document.body.innerText

Returns
The quick brown foxJumped over the lazy dog

Expected (Firefox and Chrome)
The quick brown fox\nJumped over the lazy dog

I verified this behavior in Chrome and Firefox. As far as I can tell, they do it for block level elements.

This is causing things like <li> lists to get merged together. My temporary fix is to append a whitespace to every text, but this still creates runon sentences with no break.

Another inconsistency is how newlines within the HTML are handled:

document.body.innerHTML = '<span>The quick brown fox</span>\n<span>Jumped over the lazy dog</span>'
document.body.innerText

Returns
The quick brown fox\nJumped over the lazy dog

Expected
The quick brown fox Jumped over the lazy dog

Logically, the \n is treated as whitespace and not specifically a newline (i.e. word-wrapped code doesn't mean it should be rendered with the same breaks)

@capricorn86 capricorn86 added bug Something isn't working high priority labels Jan 29, 2022
@devinellis
Copy link
Author

Checking in on this. I just confirmed this is still happening on v3.1.1. It turns out that my workaround is causing some unintended behavior. Maybe my use-case is not very common so no one else has noticed this issue.

@capricorn86
Copy link
Owner

Hi @devinellis! 🙂

Thanks for reporting!

I am not able to reproduce this bug. I have compared Happy DOM with Firefox and I get the same result between them. Am I missing something? 😅

@devinellis
Copy link
Author

Feel free to close. I have switched to using linkedom for my use-case.

@capricorn86
Copy link
Owner

capricorn86 commented Jul 4, 2022

Too bad to hear that Happy DOM couldn't help you with your case.

I believe I understand the problem now. I assumed that "innerText" for <body> behaves the same as "innerText" for other elements, but it seems like they behave differently. I tested with a <div> element.

 var div = document.createElement('div');
 
 div.innerHTML = '<div>The <strong>quick</strong> brown fox</div><div>Jumped over the lazy dog</div>';
 document.body.innerHTML =  '<div>The <strong>quick</strong> brown fox</div><div>Jumped over the lazy dog</div>';
 
 // Outputs: "The quick brown fox\nJumped over the lazy dog"
 console.log(document.body.innerText);
 
 // Outputs: "The quick brown foxJumped over the lazy dog"
 console.log(div.innerText);

@capricorn86
Copy link
Owner

capricorn86 commented Jul 6, 2022

Actually, it is not the <body> element that behaves different. It should just render it differently if it is connected to the document or not.

@capricorn86 capricorn86 self-assigned this Jul 6, 2022
capricorn86 added a commit that referenced this issue Sep 28, 2022
…etComputedStyle(). Improves support for HTMLElement.innerText.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working high priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants