feat(dom): toContainHTML

[JDOM10]

Added toContainHTML matcher

[KeylaMunnoz]

Hey @JDOM10 this looks great! I have just a small observation. I’m wondering if using a raw .includes() on outerHTML might end up being a bit brittle for developers using the matcher. Since it's a strict string comparison, differences in formatting could easily cause tests to fail even when the HTML is structurally identical, for example::

• Single quotes vs double quotes (class='foo' vs class="foo")
• Extra spaces or newlines in the test string
• Different attribute ordering (which browsers/JSDOM sometimes serialize differently)
• Tag case sensitivity (like <span> vs <SPAN>)

Do you think this is something worth looking into? Maybe normalizing both the expected HTML and the actual HTML before comparing them, maybe by parsing them through a dummy element first? Let me know what you think! 😸

[KeylaMunnoz]

Hey @JDOM10 ! Great progress here! I just have one small follow-up comment.

I feel like right now the comparison is asymmetric because the expected HTML goes through normalizeHtml, but this.actual.outerHTML is compared raw. So, both sides are not processed by the same rules, which could cause subtle mismatches in environments where outerHTML serializes differently than JSDOM does (e.g. a real browser).

So, to fix this I would recommend normalizing both sides before comparing:

normalizeHtml(this.actual.outerHTML, this.actual.ownerDocument)
  .includes(normalizeHtml(htmlText, this.actual.ownerDocument))

I think this would ensure the same rules are applied to both the actual element and the expected HTML string, making the comparison truly symmetric. Let me know what you think :)

[JDOM10]

Hey @KeylaMunnoz !

Wrapping outerHTML in normalizeHtml just re-cleans something already clean → same result, extra work. And the "real browser" worry doesn't happen because normalizeHtml uses this.actual.ownerDocument — the element's own document. So it's always the same environment on both sides; they can't diverge.