Read initial editor value from HTML content #1253
Merged
+52
−4
Conversation
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
3 tasks
|
@seanpdoyle 👍 could you please fix the conflicts? |
seanpdoyle
force-pushed
the
editor-preload-content
branch
8 times, most recently
from
81aebf6 to
fe85da1
Compare
|
I've opened #1255 to pass CI. Once that is merged, this should be conflict-free and ready. |
Prior to this commit, Trix editors used an associated input element to initially populate their content. This commit proposes to extend the behavior so that when an associated input element is absent, Trix will safely sanitize then load any HTML content inside a `<trix-editor>…</trix-editor>` tag. ```html <form …> <trix-editor>Editor content goes here</trix-editor> /form> ``` When a `<trix-editor>` element initially connects with both HTML content *and* an associated input element, Trix will *always* disregard the HTML content and +> load its initial content from the associated input element. Additional considerations --- This should not break Action Text compatibility, since Rails renders `<trix-editor>` elements through the [rich_textarea_tag][], which renders initial content into an `<input type="hidden">`. This change enables the migration toward rendering content directly *into* the `<trix-editor>` element as HTML content. [rich_textarea_tag]: https://edgeapi.rubyonrails.org/classes/ActionText/TagHelper.html#method-i-rich_textarea_tag
flavorjones
force-pushed
the
editor-preload-content
branch
from
fe85da1 to
c02eb60
Compare
|
I've merged the PRs to get CI green, and rebased this branch. @jorgemanrubia back to you for final review. |
|
Thanks @flavorjones and @seanpdoyle! |
seanpdoyle
added a commit
to seanpdoyle/rails
that referenced
this pull request
Oct 3, 2025
Problem --- The next release of [Trix][] will support integrating with `<form>` element submissions *without* an associated `<input type="hidden">` element (see [basecamp/trix#1253][] to learn more). The next release will also include support for `<trix-editor>` elements reading their initial value from their child content (see [basecamp/trix#1128][]). ```html <trix-editor name="message[content]"> <h1>hello world</h1> </trix-editor> ``` Similarly, [basecamp/lexxy][] (a potential Action Text-compatible successor to Trix) supports [configuring its underlying editor with content captured through the block passed to its form helpers][lexxy-block]: ```erb <%= form.rich_text_area :body do %> <lexxy-prompt trigger="@"> </lexxy-prompt> <% end %> ``` Proposal --- This commit proposed that all Action Text-related form tag helpers accept `&block` arguments. In the short-term, there are no real changes to behavior: the captured content will be stored in an `<input type="hidden">` element, and Trix will scrub and sanitize that content when it connects to the document. In the long-term, this change will provide an additional integration and configuration opportunity for Action Text-compatible WYSIWYG text editors. [basecamp/trix]: https://github.com/basecamp/trix [basecamp/trix#1253]: basecamp/trix#1253 [basecamp/trix#1128]: basecamp/trix#1128 [basecamp/lexxy]: https://github.com/basecamp/lexxy [lexxy-block]: https://github.com/basecamp/lexxy/?tab=readme-ov-file#general-setup
seanpdoyle
added a commit
to seanpdoyle/rails
that referenced
this pull request
Oct 3, 2025
Problem --- The next release of [Trix][] will support integrating with `<form>` element submissions *without* an associated `<input type="hidden">` element (see [basecamp/trix#1253][] to learn more). The next release will also include support for `<trix-editor>` elements reading their initial value from their child content (see [basecamp/trix#1128][]). ```html <trix-editor name="message[content]"> <h1>hello world</h1> </trix-editor> ``` Similarly, [basecamp/lexxy][] (a potential Action Text-compatible successor to Trix) supports [configuring its underlying editor with content captured through the block passed to its form helpers][lexxy-block]: ```erb <%= form.rich_text_area :body do %> <lexxy-prompt trigger="@"> </lexxy-prompt> <% end %> ``` Proposal --- This commit proposed that all Action Text-related form tag helpers accept `&block` arguments. In the short-term, there are no real changes to behavior: the captured content is treated the same way that a `value` argument or `:value` keyword argument would be. Trix will scrub and sanitize that content when its editor connects to the document. In the long-term, this change will provide an additional integration and configuration opportunity for Action Text-compatible WYSIWYG text editors. [basecamp/trix]: https://github.com/basecamp/trix [basecamp/trix#1253]: basecamp/trix#1253 [basecamp/trix#1128]: basecamp/trix#1128 [basecamp/lexxy]: https://github.com/basecamp/lexxy [lexxy-block]: https://github.com/basecamp/lexxy/?tab=readme-ov-file#general-setup
4 tasks
seanpdoyle
added a commit
to seanpdoyle/rails
that referenced
this pull request
Oct 3, 2025
Problem --- The next release of [Trix][] will support integrating with `<form>` element submissions *without* an associated `<input type="hidden">` element (see [basecamp/trix#1253][] to learn more). The next release will also include support for `<trix-editor>` elements reading their initial value from their child content (see [basecamp/trix#1128][]). ```html <trix-editor name="message[content]"> <h1>hello world</h1> </trix-editor> ``` Similarly, [basecamp/lexxy][] (a potential Action Text-compatible successor to Trix) supports [configuring its underlying editor with content captured through the block passed to its form helpers][lexxy-block]: ```erb <%= form.rich_text_area :body do %> <lexxy-prompt trigger="@"> </lexxy-prompt> <% end %> ``` Proposal --- This commit proposed that all Action Text-related form tag helpers accept `&block` arguments. In the short-term, there are no real changes to behavior: the captured content is treated the same way that a `value` argument or `:value` keyword argument would be. Trix will scrub and sanitize that content when its editor connects to the document. In the long-term, this change will provide an additional integration and configuration opportunity for Action Text-compatible WYSIWYG text editors. [basecamp/trix]: https://github.com/basecamp/trix [basecamp/trix#1253]: basecamp/trix#1253 [basecamp/trix#1128]: basecamp/trix#1128 [basecamp/lexxy]: https://github.com/basecamp/lexxy [lexxy-block]: https://github.com/basecamp/lexxy/?tab=readme-ov-file#general-setup
seanpdoyle
added a commit
to seanpdoyle/rails
that referenced
this pull request
Oct 4, 2025
Problem --- The next release of [Trix][] will support integrating with `<form>` element submissions *without* an associated `<input type="hidden">` element (see [basecamp/trix#1253][] to learn more). The next release will also include support for `<trix-editor>` elements reading their initial value from their child content (see [basecamp/trix#1128][]). ```html <trix-editor name="message[content]"> <h1>hello world</h1> </trix-editor> ``` Similarly, [basecamp/lexxy][] (a potential Action Text-compatible successor to Trix) supports [configuring its underlying editor with content captured through the block passed to its form helpers][lexxy-block]: ```erb <%= form.rich_text_area :body do %> <lexxy-prompt trigger="@"> </lexxy-prompt> <% end %> ``` Proposal --- This commit proposed that all Action Text-related form tag helpers accept `&block` arguments. In the short-term, there are no real changes to behavior: the captured content is treated the same way that a `value` argument or `:value` keyword argument would be. Trix will scrub and sanitize that content when its editor connects to the document. In the long-term, this change will provide an additional integration and configuration opportunity for Action Text-compatible WYSIWYG text editors. [basecamp/trix]: https://github.com/basecamp/trix [basecamp/trix#1253]: basecamp/trix#1253 [basecamp/trix#1128]: basecamp/trix#1128 [basecamp/lexxy]: https://github.com/basecamp/lexxy [lexxy-block]: https://github.com/basecamp/lexxy/?tab=readme-ov-file#general-setup
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.
Prior to this commit, Trix editors used an associated input element to initially populate their content.
This commit proposes to extend the behavior so that when an associated input element is absent, Trix will safely sanitize then load any HTML content inside a
<trix-editor>…</trix-editor>tag.When a
<trix-editor>element initially connects with both HTML content and an associated input element, Trix will always disregard the HTML content and +> load its initial content from the associated input element.Additional considerations
This should not break Action Text compatibility, since Rails renders
<trix-editor>elements through the rich_textarea_tag, which renders initial content into an<input type="hidden">. This change enables the migration toward rendering content directly into the<trix-editor>element as HTML content.