Children of p are not indented properly in 1.11.0

Description

Children of p are not indented properly in 1.11.0.

Input

The code looked like this before beautification:

<p>
    <ul>
        <li>sadas</li>
    </ul>
</p>

Expected Output

The code should have looked like this after beautification:

<p>
    <ul>
        <li>sadas</li>
    </ul>
</p>

or

<p></p>
<ul>
    <li>sadas</li>
</ul>
<p></p>

Actual Output

The code actually looked like this after beautification:

<p>
<ul>
    <li>sadas</li>
</ul>
</p>

Steps to Reproduce

1. Beautify code.

Environment

OS: Win, Linux

Settings

Defaults

[bitwiseman]

As an added point, not having an option to revert to the old formatting is not just a theoretical point either. The difference can be seen in the rendered html. If you look at this jsfiddle, you can see that CSS that applies to the p element contents does not apply to the ul even though from the text you might think the ul was “inside” the p element.

// css
p {
  background: green;
}

// html
<p>
    Hello
</p>
<p>
    <span>
        Hello again
    </span>
</p>
<p>
    <ul> 
        <li>Hello all!</li>
    </ul>
</p>

By indenting the ul element, the beautifier has been indicating that the ul is a child of the p element, which it absolutely is not.

[bitwiseman]

@HitkoDev I understand that you’re upset at this fix. It produced an unexpected change to your formatting.

I’m sorry, but up until 1.11.0 the elements were not properly nested, they were incorrectly nested in a way that appeared reasonable. Now they are correctly nested in a way that is surprising until you dig into it.

This fix was noted in the change log. The change log doesn’t highlight your scenario, but that is not really surprising given that it’s not valid html.

Understand, if there were any scenario in which this syntax were valid, I’d be in complete agreement with you. I have just spent several hours looking for any scenario in which the input you provided is valid html, but I can’t find one. I was thinking this might be valid in xhtml, but even there it is not: http://xstandard.com/en/articles/xhtml-reference/p/#p-contains . In xhtml, the ul still cannot be a child of the p so the result is the same as in html. (The only scenario I can find is if you are writing plain xml).

The project does follow semantic versioning to the extent that is reasonable in this area.

We use major version to indicate API compatibility. This project has never made API incompatible changes. There are a number of options that have been retained for backward compatibility.

The question then is what is the definition of “backward compatible” when it comes to formatting output? If we say any change to output is not backward compatible" then every change will be a new major version. That would actually less informative for the consumers of this library - they would not know whether a release is API compatible or not.

We use minor versions to indicate significant formatting fixes or added features. We use patch versions to indicate small bug fixes formatting fixes or added options that cannot cause any side effects.

We do not make spurious changes the output, but output for a given input MAY change for minor or patch versions. For changes that fix formatting errors (making the output more accurate), we turn those on by default and may or may not provide the ability to turn them off. We only do this only when the formatting was strictly incorrect. All other changes should be added as formatting options, which must be off by default such that the default formatting of valid input doesn’t change whenever a feature is added.

Best effort is made to handle invalid inputs in a reasonable way as well, but that is not a priority.