Closed claytonrcarter closed 7 months ago
Currently done intentionally as it manually manages Prettier's html-whitespace-sensitivity
option. The current challenges (and reason it manually adjusts this) is when some setting combinations produces output like this:
<a target="_blank" href="/arbitrary-path/to-a-file"
>Lorem ipsum dolor sit amet, consectetur</a
>
The layout engine produces quite a few temporary HTML tags in the background that this really confuses. Definitely wouldn't mind improving this and respecting that setting, but will take some thinking
Currently done intentionally
OK, I see.
Definitely wouldn't mind improving this and respecting that setting, but will take some thinking
Any pointers on where in the codebase to look at this, just as a jumpstart? I changed the html-whitespace-sensitivity
locally and basically everything exploded, so I couldn't focus in on any particular area. Not that I'll be helpful in improving things, but I'd like to at least poke at it a bit. Respecting the intent of the input markup feels like an important improvement.
This adds a test for a couple of cases where the plugin is formatting markup in a way that changes the layout. For example, some (all?) cases of things like
<a ...>foo</a>.
are being formatted asWhich – depending on CSS – changes the rendered content in the browser because of the added whitespace around
foo
and.
The two tests I added are both taken from (obfuscated) examples I came across while running this plugin on our codebase at work, so they're nominally real-world examples. 😆 I just added assertions to see if the blade plugin produced identical output to the core prettier HTML parser/formatter, and both are failing.
As noted in #90, I'm new around here, so it's possible that this is a known issue, or is being done intentionally, but these surprised me so I thought I'd report them. Thank you!