Stop modification of br tag

[milne-dev]

When I pass <br> through the sanitizeHtml() is there any way to keep it from changing to <br /> ?

Or for other tags that may be similiar..

Thanks!

[mathieumg]

<br> is not valid whereas <br /> is. What is your use case?

[simison]

<br> is perfectly valid HTML, <br/> valid XHTML. ;-)

http://w3c.github.io/html-reference/syntax.html#void-element

Optionally, a "/" character, which may be present only if the element is a void element.

[boutell]

As long as htmlparser2 doesn't offer a way to sniff out whether the original tag had a / or not, sanitize-html will continue to use its internal list of void elements to decide whether to use /.

But even if it did, I'm not sure I would change this. <br> may be acceptable in HTML, but <br /> is always 100% valid as both HTML and XHTML. It's just cleaner and it does not change the meaning of the code in any way.

[milne-dev]

For large deployments that store a lot of user generated html, it is favorable to keep the data size as low as possible.

[omerts]

@boutell I am having a similar issue with an image tag. It is totally breaking my functionality since I am working with innerHTML attribute which returns the html like it is in the browser's DOM. Chrome strips out self closing tags, which causes html that I pass through html-sanitize to be inconsistent with my innerHTML. Consistency is critical for me, since I am changing the html by selection indexes, and if the sanitize html changes it, indexes are offset.

[matiishyn]

I have same issue here
Please, Stop modification of br tag

[boutell]

There is no support upstream in htmlparser2 for determining which syntax was used to close tags. This is unlikely to happen at least until a new, bc break version of sanitize-html that depends on a different html parser module. Which is likely eventually, because htmlparser2 is not receiving much maintenance, but it doesn't guarantee the library we choose will support this either.

[dman777]

I am hitting this issue with quill. I don't think quill likes <br />

[gastonyte]

Hello, Thank you for this library.

I'm also a user of Quill and I'd find it helpful to have an option to disable the addition of a slash for <br> tags.

I wouldn't say "it's just cleaner", but "this is one of the possible correct solutions".

For those interested in a solution to this particular problem, I've made it possible in my fork:

To achieve this, define the selfClosing option as an object. The keys of this object should be the tag names, and the value should be a truthy or falsy value. If the value of a specific tag has the property voidTag set to true, the library will not insert the space and the slash.

type SelfClosingOptions = Record<string, boolean | { voidTag: boolean }>

type MyIOptions = Omit<sanitizeHtml.IOptions, 'selfClosing'> & {
  selfClosing?: SelfClosingOptions | string[] | undefined
}

const sanitizationOptions: MyIOptions = {
  allowedTags: ['p', 'strong', 'em', 'u', 's', 'blockquote', 'ul', 'ol', 'li', 'br'],
  allowedAttributes: {},
  selfClosing: {
    br: {
      voidTag: true
    }
  },
}

const cleaned = sanitizeHtml(
  value,
  sanitizationOptions as sanitizeHtml.IOptions
)

[boutell]

These are really two separate features:

1. "Preserve it the way it was" ("stop modification," as the title says)

We can't easily do this because of the way the upstream module gives us the information.

2. "An option to not use the /"

Sure, that would be fine as long as the default doesn't change unexpectedly. @gastonyte would you like to create a PR for your feature?

[gastonyte]

Hi @boutell, I didn't know if this feature was wanted or not, so I just made the modification in a fork to be able to use it in my app, but if it's something you would like to see integrated into your library, it is with pleasure that I will create the PR =)

[boutell]

Yes, supporting this via a flag sounds great! My objection was to the original request in which the original presence or absence of a / would be preserved, simply because I don't think we have access to that information.