Diff tests do not track line break changes

[kptdobe]

adobe/theblog#416 revealed that line breaks have changed which was causing issues in the consuming code (not necessarily good code). Even worst, the different behaviour was introduced by a change in a third-party module.
Diff tests should have detected the line break changes.

cc @MarquiseRosier

[trieloff]

Really? Line breaks are not relevant to the DOM in most cases, so I wouldn't pile one bad decision on another.

[MarquiseRosier]

@trieloff and @kptdobe let me know what the verdict is; but I agree with Lars; what I added to build the diff tests only checks for difference in node values, # of children, content.

But there's some normalization code that makes white space not really matter, i'm very certain that this is the reason why white space change wouldn't be detected; if i'm remembering correctly!

[tripodsan]

Really? Line breaks are not relevant to the DOM in most cases, so I wouldn't pile one bad decision on another.

most of the times... yes. but there are edge cases, e.g. between block elements.
also see https://medium.com/@patrickbrosset/when-does-white-space-matter-in-html-b90e8a7cdd33

[trieloff]

And in pre…

The diff test should test significant DOM differences. If our DOM diff misses the cases @tripodsan outlined, let's fix it, but don't change the definition of the test to become about string equality.

[MarquiseRosier]

@kptdobe mind pointing me to the change that caused the break? I believe it was an update to word2md?

[kptdobe]

Documented here: adobe/theblog#416 (comment)

The main issue is that we use "text" as reference for entries lookup which requires a lot of filtering (remove potential styling, line breaks...). In this specific case, a trim was required in the consuming code and this seriously broke the site without us noticing it.

I am not saying we should block the deployment of a new hlx version because of new line breaks introduced but we should analyse the impact before hitting the publish button.