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

Extra <br /> tags in information screen item preview #717

Closed
wwqrd opened this issue Apr 20, 2021 · 3 comments
Closed

Extra <br /> tags in information screen item preview #717

wwqrd opened this issue Apr 20, 2021 · 3 comments

Comments

@wwqrd
Copy link
Contributor

wwqrd commented Apr 20, 2021

On the information screen multiple new lines for a text block are shown as
tags in the item preview. This is stripped when rendered in Interviewer (preview), and also parses correctly into a new line in the rich text editor. Seems like something the rich text serializer is doing.

  • Update the preview (in the list in architect) to match the render settings in Interviewer
  • Update the serializer to remove this behaviour?
@wwqrd
Copy link
Contributor Author

wwqrd commented Apr 27, 2021

react-markdown escapes html intentionally for security reasons. remark-slate serializes multiple line breaks into
tags.

Options are:

  • Add html support to react-markdown (security implication with malicious protocols)
  • Strip <br> tags from the serialized output (will cause mismatch between <RichText> preview and actual markdown output)
  • Replace <br> tags in output with something that react-markdown supports. It's not clear if there is something suitable; double spaces only work when used in conjunction with copy.
  • Update the slate instance to prevent multiple line breaks (may seem like broken behaviour to user)

@jthrilly
Copy link
Member

I don't think we should be generating <br /> tags from slate, so my first preference is to prevent that. Maybe we could replace them with empty paragraphs that contain a single (escaped) space. This would require updating the empty node detection.

Failing that, I think stripping them and accepting the mismatch between the editor and the output is the thing to do.

@rebeccamadsen
Copy link
Contributor

I think this was resolved in #728. Or at least I can't replicate this now.

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

No branches or pull requests

3 participants