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
[labs/ssr] Binding to textarea results comment node errantly added inside textarea #3663
Comments
We need a special case for the "raw text element" set ( The hydration code already supports adding a node after an element (as opposed to the first child) and looking at the previous sibling first (before the parent) to handle the case of void elements like lit/packages/lit-html/src/experimental-hydrate.ts Lines 351 to 355 in 65df149
If we disallow bindings within raw text elements, then a fix would be as simple as skipping to the end of the raw text element and adding the node marker after the close tag. Not sure if that's viable ( We need to see a part marker for the node before any other bindings, otherwise the part/value order won't agree. Perhaps we could get away with saying you can either bind to a raw text element's properties/attrs or to its child content, but not both? It seems like supporting both would require a big change to either use an attribute rather than a comment marker for identifying property/attribute/element bindings (and can't use the current comment-based TreeWalker) 👎, or move the comment marker ahead of the element, which requires buffering the open tag 👎 , or rearrange parts during hydration somehow 👎 . |
I suspect we really do want to keep a comment-only system, but we should measure. I wonder how expensive it is to do a qSA for raw text elements? I think moving the marker to be in front of the node is an interesting option. I don't see how buffering is an issue... In SSR we know what tags have bindings after template prep, add in hydration we'll know the next tag has bindings. This seems good as you can't validly have bound tags inside a raw text element, so the comment will parse as a comment is all valid templates. |
Ah right, I was thinking it affected the streaming side, but you're right we can work it out during template prep. Concretely, during template prep we'd need to insert a |
I tried a quick fix for this and it was pretty chill (re-arranging the opcodes so cc @augustjk |
Which package(s) are affected?
SSR (@lit-labs/ssr)
Description
Server rendering a
<textarea>
with a binding in property/attribute/element position results in a comment node being added inside the textarea content, which is rendered as plain text rather than being parsed as an HTML comment.Reported by user
Levi
in Discord thread: https://discord.com/channels/1012791295170859069/1073542653402157076Reproduction
When server-rendering the following template using
@lit-labs/ssr
:A comment node shows up inside the textarea:
Workaround
Avoid binding to the textarea node.
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
@lit-labs/ssr 3.0.1
Browser/OS/Node environment
Any
The text was updated successfully, but these errors were encountered: