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

x-text doesn't work with SVG elements #734

Closed
philippbosch opened this issue Aug 28, 2020 · 10 comments · Fixed by #736
Closed

x-text doesn't work with SVG elements #734

philippbosch opened this issue Aug 28, 2020 · 10 comments · Fixed by #736

Comments

@philippbosch
Copy link
Contributor

I have an SVG image that is embedded in an HTML page inside an Alpine component. As part of the SVG there's a text element that I would like to bind to some Alpine data. Unfortunately, x-text does not seem to work for SVG elements.

Example

I believe this is because x-texttries to set .innerText on the element, but SVG elements, or at least <text> don't have an .innerText attribute.

Something like this could work:

-     el.innerText = output
+     if (el.hasAttribute('innerText') {
+       el.innerText = output;
+     } else if (el.hasAttribute('textContent') {
+       el.textContent = output;
+     }

It's not the most elegant solution, but unless somebody has a better approach, I can put together a PR for this.

@HugoDF
Copy link
Contributor

HugoDF commented Aug 28, 2020

That seems like a reasonable PR.

Make sure to include a test.

I don't know how exactly JSDOM works but I think it doesn't implement innerText correctly so you might have issues there

@ryangjchandler
Copy link
Contributor

@philippbosch If you don't fancy doing a PR for this, I'll take a look on Sunday.

@philippbosch
Copy link
Contributor Author

Oh, I‘ll happily put together a PR. But thanks!

@SimoTod
Copy link
Collaborator

SimoTod commented Aug 29, 2020

Would we have issues if we always set textContent?

@ryangjchandler
Copy link
Contributor

Would we have issues if we always set textContent?

I don't think so tbh, it should be fine. There are some differences in the behaviour of the two properties but I can't see any major problems.

@philippbosch
Copy link
Contributor Author

That was my first thought as well. What made me shy away from that approach was that the other x-text test were failing. But that might be a limitiation in jsdom which maybe doesn't update innerText when textContent is changed.

But yeah, I can definitely look into using textContent always. I found this article which covers the differences between the two. I guess I'll start with writing some more tests first.

@SimoTod
Copy link
Collaborator

SimoTod commented Aug 29, 2020

No worries, it was just to satisfy my curiosity. :)

@philippbosch
Copy link
Contributor Author

No, you're totally right, @SimoTod!

Turns out that jsdom does not implement innerText at all, so the existing tests are not very helpful. We are simply testing if we can set a variable on an object … 

I'm gonna change the implementation of x-text and also the tests to use textContent instead. I'm fairly sure it will be fine, like @ryangjchandler said, because the differences between innerText and textContent are mostly about reading and not about writing the value.

@philippbosch
Copy link
Contributor Author

So, this PR is getting a lot more complex when we swap innerText for textContent. But I still think it‘s the right thing to do.

jsdom has a pretty robust implementation of textContent but none at all of innerText. That means all tests that currently test something on innerText are not very realistic. Also, textContent – in jsdom and browsers – is always a string. So tests like this one need to be changed to expect "0" instead of 0:

expect(document.querySelector('span').innerText).toEqual(0)

I‘m going through all the tests and will update the PR tomorrow or on Monday.

@HugoDF
Copy link
Contributor

HugoDF commented Aug 30, 2020

Scary changes ☹️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants