-
-
Notifications
You must be signed in to change notification settings - Fork 723
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
Documentation issue and question for custom elements #854
Comments
Hey there, thanks for filing this. I think you are right, either the result be different or the value should be set to false. From what I can see, this line needs changing, correct? https://github.com/cure53/DOMPurify/blob/main/README.md?plain=1#L243 It should be this, correct?
|
This is my guess too, based on what I observed. For the second point, I couldn't find anywhere in the documentation if it is expected that the DOM content of the custom element will be removed, or only the custom element markup. From what I test, it feels like only the markup is gone and the content is still there (might it be a content generated by the element itself! for example, after getting triggered by an attribute change), but I do not know if this is a specified behavior, or if I cannot count on it. |
Cool, will fix then, thanks.
I think this is currently expected behavior: https://github.com/cure53/DOMPurify/blob/main/src/purify.js#L291 |
Excellent, thank you for the reference! I missed it previously. |
I was trying to use the examples written in https://github.com/cure53/DOMPurify#control-behavior-relating-to-custom-elements and there is something I think is wrong documentation. The two last configuration look roughly the same, up to regex/predicate difference, yet they do not seem to return the same result (the
is
attribute is removed in the last snippet).I was wondering if it shouldn't be instead
I also notice that if the element
foo-bar
actually writes something (for example, it doesthis.textContent = "Hello"
when an attribute changes), even in strict default mode, then the value of the text content is still in the DOM, but not the custom element. Is this behavior expected, or is it simply undefined behavior ?The text was updated successfully, but these errors were encountered: