fix: preserve line feed character references in attribute values - #18691
Open
giaBaoJS wants to merge 1 commit into
Open
fix: preserve line feed character references in attribute values#18691giaBaoJS wants to merge 1 commit into
giaBaoJS wants to merge 1 commit into
Conversation
|
Install the latest version of pnpm add https://pkg.svelte.dev/svelte/c/5a40c98d5d5e70e3134d5afa892a565bf17cd2e0Open in Note This PR is from a fork. A maintainer must approve approve each commit before it can be built and installed. |
🦋 Changeset detectedLatest commit: 5a40c98 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #15555
<span title="A
B">currently renders with a space instead of a line break, so there is no way to get a newline into an attribute value using a character reference.
works, andtitle={'A\nB'}works, but the LF entity silently loses the newline.Why it happens
decode_character_references()already knows whether it is decoding an attribute value —is_attribute_valueis threaded in fromelement.js(true) andtext.js(false) — but the flag stops at the call tovalidate_code()on line 63.validate_code()unconditionally maps code point 10 to 32:That is correct for text content, where the line feed would be collapsed along with the surrounding whitespace anyway, but an attribute value is not whitespace-normalized, so the collapse is simply lossy there.
The fix
Pass
is_attribute_valuedown tovalidate_code()and skip the collapse when it is set. Nothing else changes: every other code point takes the same path it did before, and text content still collapses.Changes
1-parse/utils/html.js: threadis_attribute_valueintovalidate_code()and guard the LF collapse with ittests/parser-legacy/samples/convert-entities-line-feed: AST snapshot pinning both halves —<p title="A
B">A
B</p>parses todata: "A\nB"for the attribute anddata: "A B"for the texttests/runtime-runes/samples/html-entity-line-feed: the reported case end to end — hex and decimal LF entities ontitle, an LF entity in a prop passed to a component, and a©control to show ordinary entities still decodeTest plan
Reverting just the
html.jschange turns both fixtures red:The parser snapshot is deliberately the one that guards against over-fixing: in that diff only the attribute
datamoves, the textdatastays"A B". Replacing the guard with a wholesale removal of the LF rule flips the other half red instead, on the text node, so the fixture pins the behaviour in both directions.One thing I noticed while writing the runtime test but did not touch, since it is unrelated and predates this change: for text content the client backend inlines the raw source into the template (
$.from_html(\A B`)) and lets the browser decode it, so the DOM ends up with a real newline, while SSR emits the collapsedA B`. That client/SSR divergence is identical before and after this PR. Happy to open a separate issue for it if it is worth tracking.