markup formatting - cost to overall structure readability very high

Hi,

i am fully aware of Prettier’s option philosophy, but I still wanted to point something out that bugs me a great deal and that is that Prettier does not seem to acknowledge at all that there could be different format requirements for different languages/scenarios. I will try to give a small example of what I mean:

When you jump to a function in Java, you usually want to actually read the full code - Prettier is great for that!

Things are so very different when you are writing/reading markup (lets say HTML) though. One example of a div with multiple attributes (angular directives, style classes, aria-attributes and a data attribute). Prettier 2.7.1 Playground link

--parser html
--print-width 120

Input:

<div  ngIf="ability?.length > 0 && ! loading" myCustomDirective  data-cy="nav-header"
  class="col-lg responsive-input-wrapper d-flex align-items-center"
   tabindex="0" role="tooltip"  aria-label="Primary">
...

Output:

<div
  ngIf="ability?.length > 0 && ! loading"
  myCustomDirective
  data-cy="nav-header"
  class="col-lg responsive-input-wrapper d-flex align-items-center"
  tabindex="0"
  role="tooltip"
  aria-label="Primary"
>
  ...
</div>

Expected behavior: When reading HTML Code you are very rarely interested in all individual attributes. Far more often you are working on something where the general structure is more important than perfect readability of attributes. The Problem is that Prettier’s styling comes at a great cost to the readability of the overall structure. I’ve discussed this with multiple colleagues and we ended up agreeing that Prettier ends up creating HTML code that is actually were hard and frustrating to work on. It’s nice for simple examples, like a div with 2 attributes, but get’s very ugly quickly in more complex scenarios.

Coming back to the example: You can’t even fit 3 of those “vertical-space-monstrosities” on your actual screen! Working on the structure (e.g. change styles / classes) requires excessive scrolling and is very frustrating.

I think our biggest problem is with the “print width” - basically there are only 2 possible outcomes: a) the statement fits within the print-width - it’s collapsed into a single line (no matter if we wanted to break them up with newlines, but that’s another story) b) the statement doesn’t fit into the print-width: now it switches into “every attribute on a new line” mode There seems to be no option for any middle ground. The input-example above is an example of a possible middle ground. It adds manual linebreaks like so: a) Angular directives and other dynamic stuff go into the first line b) classes and styling go into the second line c) aria stuff in the third line

With that it is still reasonably easy to read attributes (especially since you know where to look for them) but you can still see and comprehend much more of the overall structure at once. I am not saying that Prettier should do THAT automatically, but is it really not possible to use sensible line-breaks, while still using Prettier? Why only the extremes? Please give us an option to let Prettier honor our linebreaks.

While I don’t agree with the options philosophy I do understand it. But doesn’t it go a bit TOO far? What the optimal code-style is is of course heavily opinionated - but formatting everything the same (Code and Markup) while completely ignoring the different requirements you have in reading the two seems a bit questionable to me personally.

Best regards, Mario

[fisker]

It not clear to me what’s expected.

[matrium0]

I would expect some options to prevent blowing up every html element to 12 lines- because as I mentioned this greatly reduces the readability of the overall structure - for the sake of improved readability of every single attribute (which unlike the structure you rarely need when editing markup code like HTML).

I would expect an option to either honor my newlines (as long as each line fits within the print-width) OR an option to prevent the “newline for each argument once print width is reached”.

The optimal code-style (let’s say it exists) between code and markup is vastly different and Prettier just bluntly styles markup the same as everything else - which leads to very hard to maintain HTML code