Prettier: [resolved] [HTML] allow corresponding option to jsxBracketSameLine

[bengry]

Note: Read this comment to make sure you’re up-to-speed on what this issue is and is not about: https://github.com/prettier/prettier/issues/5377#issuecomment-628213559

---

For React/JSX - Prettier has an option to allow tags to close on the same line as the declaration, rather then on a new line:
jsxBracketSameLine: true:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}>
  Click Here
</button>

jsxBracketSameLine: false:

<button
  className="prettier-class"
  id="prettier-id"
  onClick={this.handleClick}
>
  Click Here
</button>

With Prettier 1.15.1, at least for the Angular parser, there is no corresponding option, so all HTML is formatted like this:
Input:

<my-component class="wcd-flex-1 dialog-contents wcd-scroll-vertical"
              [foo]="bar">
</my-component>

Output:

<my-component
    class="wcd-flex-1 dialog-contents wcd-scroll-vertical"
    [foo]="bar"
>
</my-component>

Playground link

It would be nice to have a flag to set it such that the output of the above would be:

<my-component
    class="wcd-flex-1 dialog-contents wcd-scroll-vertical"
    [foo]="bar">
</my-component>

[michaeljota]

I don't think this is the same as you are requesting. JSX and HTML are two different things.

[j-f1]

Perhaps we should name it to angleBracketSameLine.

[bengry]

@michaeljota I agree they are different things, but in this regard they can be "collapsed" under the same option I think, as the behavior is largely the same. @j-f1's suggestion for the name (change?) emphasis it.

[matt328]

I don't think I've ever seen any markup language with the closing brackets on a separate line. I'd like to see angleBracketSameLine or some equivalent.

[aboyton]

The reason I personally write the closing bracket on the next line is that it makes it much simpler to work out what's an attribute and what's content.

<my-component
  foo="bar"
  moo="cow">
  Now some text
  It's really not clear where the text started
</my-component>

compared to

<my-component
  foo="bar"
  moo="cow"
>
  Now some text
  It's much clearer where the text started
</my-component>

It also matches what people do in code and so we found it pretty simple to get our company to all adopt the coding style.

[bengry]

@aboyton good point. But what about when you don't have content?

<my-component
  foo="bar"
  moo="cow">
</my-component>

Or is it still:

<my-component
  foo="bar"
  moo="cow"
>
</my-component>

Or something else entirely?

[aboyton]

<my-component
  foo="bar"
  moo="cow"
></my-component>

Is what I do to reduce vertical space (or just put it all on one line).

[SungwonKim]

It also happens on Vue template. Closing bracket on the next line or same line is not important for this issue. Prettier provides this feature as an option for JSX but not for Angular or Vue.

[stewwan]

would be awesome to have that JSX option for any kind of html parser

[dousybox]

Case 1: When I fold the tag vscode folded the start tag itself,
not include the end tag.

Case 2: When I put > back to the previous line, the fold is include the end tag.

There are two fold tag in Case 1, fist one is fold start tag itself, second one is fold the end tag.
VS Code was right, but I think the Case 2 is best for me.

It will be better, if there is a switch like TagBracketSameLine option for any kind of html parser.

[Carniatto]

For me this is the most annoying prettier formatting. Specially in Angular it prefers to break lin on the bracket instead of on attributes.

[stephen-dahl]

my team is fine with

<div
    id="bar"
    class="foo"
><div>

but hates

<div
    id="bar"
    class="foo"
> 
    content
<div>

[matt328]

@stephen-dahl agree. The angle bracket hanging out there on its own line is never going to catch on. I've tried for the last month, but my mind still sees it as an error or a typo. IMO, js-beautify has solved the html formatting problem. Until prettier gets its stuff together, I'll be using that for my html.

[JonathanAlumbaugh]

I'm trying to figure out how to get things between braces/brackets on the same line while using prettier and this is the closest related issue I can find, how would I get this

            { rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' },
            { rel: 'stylsheet', type: 'text/css', href: 'https://unpkg.com/vue-plyr/dist/vue-plyr.css' },
            { rel: 'stylesheet', href: 'https://maxcdn.icons8.com/fonts/line-awesome/1.1/css/line-awesome-font-awesome.min.css' },
            { rel: 'stylesheet', type: 'text/css', href: 'https://use.typekit.net/rbp5ahp.css' }

instead of this (which is happening whenever I save)

            { rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' },
            {
                rel: 'stylsheet',
                type: 'text/css',
                href: 'https://unpkg.com/vue-plyr/dist/vue-plyr.css',
            },
            {
                rel: 'stylesheet',
                href:
                    'https://maxcdn.icons8.com/fonts/line-awesome/1.1/css/line-awesome-font-awesome.min.css',
            },
            {
                rel: 'stylesheet',
                type: 'text/css',
                href: 'https://use.typekit.net/rbp5ahp.css',
            },

[j-f1]

There’s not an option for that. If you just have that kind of thing once in your codebase, you can put a // prettier-ignore comment before the array to stop Prettier from changing it.

[DanielHabenicht]

Until it is fixed you can just disable prettier for .html files and use the standard formatter while keeping your other files pretty:

{
"editor.formatOnPaste": true,
"prettier.singleQuote": false,
"prettier.trailingComma": "none",
"prettier.disableLanguages": ["html"],
"editor.formatOnSave": true,
"editor.rulers": [110],
"html.format.wrapAttributes": "force",
"html.format.enable": true,
"html.format.wrapLineLength": 110
}
From: https://github.com/prettier/prettier-vscode/issues/182#issuecomment-438966521

[vort3xxx]

My team won't let me adopt prettier for angular html templates because of this one.

[oswaldofreitas]

when you have 47 thumbs up in an issue it's a signal that it's important for the community

[oswaldofreitas]

This is really bothering me, I can't even work in my project with that new line just for a ">", it makes my code horrible and hurts my eyes :)

Seems like others are having the same issue:

https://github.com/vuejs/vue-cli/issues/3078

I think when there is an impasse of how should be the correct looking, an option to configure that would be great to attend everyone.

btw, I LOVE what Prettier does to my javascript!

[krokofant]

It's a bit hard to enforce using prettier when issues like this exists.

[michaeljota]

It's a bit hard to enforce using prettier when issues like this exists.

It's actually not hard at all. You just need to focus coding, and leave Prettier alone with the formatting. Is easier than you think.

[vort3xxx]

It's actually not hard at all. You just need to focus coding, and leave Prettier alone with the formatting. Is easier than you think.

I'm sure that mentality works great for small, authoritarian teams, but when you have to convince 80 other engineers to adopt a new tool and it doesn't pass their sniff test because the code it produces looks way different than the code they've been writing forever, then the conversation goes nowhere.

Tool selection is often a social tug of war on larger teams where the toolmaster gets stuck respecting some accidents of history in order to gain adoption.

[oswaldofreitas]

a new option similar to jsxBracketSameLine would save us so much time on waiting and discussing.

Also, code style is pretty like when you get a new keyboard, you need some time to adapt your eyes to it and I personally don't want to waste time with this since I've been working for a long time with the same code style, unless it's something really necessary or worth to change

[gjbianco]

While I agree with the mentality of "let the formatter handle formatting", this particular configuration is already an option. This request is to extend it to other similar markup.

[lysla]

Please do add this option for .vue files, I really wanted to give Prettier a try and this lonely brackets all around my code are really giving me a hard time!

[michaelsogos]

Hi, any news about it?

Also my team hate > on a new line. Also we are working with VUE and VETUR extension but JSX options doesn't apply.

[oswaldofreitas]

when you have 47 thumbs up in an issue it's a signal that it's important for the community

wow, it's now 67 and counting! Unfortunately no responses from the prettier team?

[alphabt]

This thread is just full of thumb ups

[krokofant]

Anyone dare to provide a pull request? 🍰

[kodmis]

Please, add this option for .vue files

[y4n6]

How many people choose js-beautify-html？

"vetur.format.defaultFormatter.html": "js-beautify-html", "vetur.format.defaultFormatterOptions": { "js-beautify-html": { "wrap_attributes": "force-aligned" } },

[goat67]

Please add this for html files this is a deal breaker for our team we will not be implementing to bad liked it otherwise.

[marekrewers]

I'm also looking forward to this. Current behavior stops me from using it.

[alexander-akait]

/cc @vjeux what do you think?

[stephen-dahl]

maybe deprecate old option renaming to have 1 option apply to all the html like languages (html, xhtml, jsx, ect)

[vjeux]

@evilebottnawi Sounds reasonable to add an option for it since we're already doing it for JSX.

[phifa]

Will this work for .html and for .vue files? Currently I have to disable prettier whenever I work on vue files.

[krokofant]

@phifa You could set .vue files to be handled by another parser, like the html one.

https://prettier.io/docs/en/configuration.html#setting-the-parser-docs-en-optionshtml-parser-option
https://prettier.io/docs/en/options.html#parser

[mkapiczy]

+1

I just can't be convinced that's a desirable way of formatting the code:

Input:
<template><p></p></template>

Output:

<template
  ><p></p
></template>

[michaeljota]

@mkapiczy You can configure the html spacing to ignore. This is not about that, but about the closing tag when you have multiple properties in the element.

[phifa]

@krokofant no that will not work since I want my script and style tags to be formatted by prettier.

[vaynewang]

@mkapiczy You can configure the html spacing to ignore. This is not about that, but about the closing tag when you have multiple properties in the element.

This is useful for solving mkapiczy's problem.

[vaynewang]

Is it Need today 「vaynewang [e-mail]」在 2019年4月26日 週五，上午10:30 寫道：
…
@mkapiczy https://github.com/mkapiczy You can configure the html spacing to ignore. This is not about that, but about the closing tag when you have multiple properties in the element. This is useful for solving mkapiczy's problem. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5377 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AKIVS7JSFMATN46VZQ2YAHTPSJSL5ANCNFSM4GCMT42A .

yes. format Vue template or html template (not react JSX) , need that config.

[mkapiczy]

That helped, thanks. Still supporting the original issue tought

[phifa]

The folding issue in VS Code is a real problem like @dousybox pointed out.

[Devil-Cong]

What's the situation now?

[clabough]

For me, in some cases, it's even worse.

<div class="col">
    <component [(value)]="value"
    ><component2
      >text</component2
    ></component
    >
</div>

[lydell]

@clabough It sounds like you might be looking for the html-whitespace-sensitivity option.

[clabough]

@lydell Yes, I'm aware of that setting, but in the documentation, I do not know why the ending > gets wrapped.

<!-- <span> is an inline element, <div> is a block element -->

<!-- input -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>
<div class="voluptatem architecto at">Architecto rerum architecto incidunt sint.</div>

<!-- output -->
<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>
<div class="voluptatem architecto at">
  Architecto rerum architecto incidunt sint.
</div>

Why is

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>

any different than

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span>

Perhaps it's trying to align < and > vertically, but that's not a whitespace issue.

[craigcosmo]

what's going on here? are we gonna fix this sh*t or not?

[meteorlxy]

In Vue SFC, I hope to:

• enable/disable prettier for <template>, <script> or <style> blocks
• format custom blocks of particular language by prettier

For this purpose, I create eslint-plugin-prettier-vue to handle .vue files

[michaeljota]

@meteorlxy I don't support the opinions on formatting any more, but that's a great work. Thanks for sharing. If you don't want to, just don't use it.

[qpxtWhite]

@lydell Yes, I'm aware of that setting, but in the documentation, I do not know why the ending > gets wrapped.

<!-- <span> is an inline element, <div> is a block element -->

<!-- input -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>
<div class="voluptatem architecto at">Architecto rerum architecto incidunt sint.</div>

<!-- output -->
<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>
<div class="voluptatem architecto at">
  Architecto rerum architecto incidunt sint.
</div>

Why is

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>

any different than

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span>

Perhaps it's trying to align < and > vertically, but that's not a whitespace issue.

@clabough @lydell I have the same question
Playground Link
Why the ending > of the second button is in new line

[lydell]

@qpxtWhite What buttons are referring to?

[qpxtWhite]

@lydell
I'm using Vue parser, and the parsed vue template is not expected

Playground Link
In the sample, the first "custom-button" is good, and the second "custom-button" is ugly!

[lydell]

@qpxtWhite I see, thanks. Doing the unusual break between </tag and > allows having the closing tags on different lines:

<template>
  <div>
    <my-custom-button @click="handleButtonClick" type="primary">{{
      buttonName
    }}</my-custom-button>
    <my-custom-button @click="handleButtonClick" type="primary"
      ><span class="btn btn-lg btn-primary btn-elevated"
        >start</span
      ></my-custom-button
    >
  </div>
</template>

<script></script>

<style></style>

vs:

<template>
  <div>
    <my-custom-button @click="handleButtonClick" type="primary">{{
      buttonName
    }}</my-custom-button>
    <my-custom-button @click="handleButtonClick" type="primary"
      ><span class="btn btn-lg btn-primary btn-elevated"
        >start</span></my-custom-button>
  </div>
</template>

<script></script>

<style></style>

[GitGangGuy]

I just started using prettier and I've setup my config file and got really annoyed when I realized I could not stop prettier from moving my html tag-ending brackets to the next line. I'll be moving to beautify in vscode until you guys get your ** together. Formatted code looks gross with Prettier, I can't believe the people here have been waiting a year and 152 likes without any official response yet. Yikes!

[DanielHabenicht]

@GitGangGuy

"Prettier is an opinionated code formatter."

--> It's not a bug, it's a feature. 🎉

[Carniatto]

@DanielHabenicht It's also open-source supported by the community and build for the community or not? adding this option would make it easier for some teams to use it.

[lydell]

@Carniatto It is a difficult line to walk – see the Option philosophy.

[stephen-dahl]

@lydell I think this issue has reached an appropriate amount if interest to get a response saying that prettier is willing to look at options to implement the requested change or closing the issue with a brief explanation of the reasoning.

My proposal is to rename the option jsxBracketSameLine to htmlBracketSameLine and have the option cover jsx and html. deprecate jsxBracketSameLine and remove it in the next major version.

Or heck, if we dont want the option how about changing the default? I would be surprised if more people want the current behavior than want this behavior.

either way this issue needs closed or to move to next steps.

[craigcosmo]

the author dont do this becuase of technical issue? Or it's his belief?

[stephen-dahl]

I believe the underlying html formatter has the option for this, so it is mostly a design decision that needs to happen.

[craigcosmo]

no who in their right mind want to make tag ending look crazy like that?

[DanielHabenicht]

@DanielHabenicht It's also open-source supported by the community and build for the community or not? adding this option would make it easier for some teams to use it.

Written Sarcasm is something I still have to develop. 😆 I am all for it! I hate the current Status and have prettier disabled in my projects for html files.

[lydell]

There is no “underlying html formatter”. Prettier uses its own stuff. As far as I know, there are no technical limitations to the placing of the closing >. Also note that Prettier is run by a group of volunteers, not a single person.

Personally I think it makes sense changing jsxBracketSameLine to something that applies to both JSX and HTML. But right now we need to focus on getting the next release out.

The issue stays open. We’ve found that it has generally worked better to keep issues open for a long time than closing them.

[stephen-dahl]

There is no “underlying html formatter”.

Ok, I thought I read that there was somewhere above.

right now we need to focus on getting the next release out.

Makes sense, after the release what needs to happen to get a determination on this from the team? I'm sure that there are several that would be willing to do the work if it was approved.

The issue stays open. We’ve found that it has generally worked better to keep issues open for a long time than closing them.

ya I noticed that at the end of the Option philosophy after reading it again. I guess most people don't search closed issues.

[lydell]

@pwang2 That’s unrelated to this issue. You’re looking for --html-whitespace-sensitivity ignore:
Prettier 1.18.2
Playground link

--html-whitespace-sensitivity ignore
--parser vue

Input:

<template>
  <v-btn text small color="primary" class="my-4 float-right" f="f">Continue</v-btn>
</template>

Output:

<template>
  <v-btn text small color="primary" class="my-4 float-right" f="f">
    Continue
  </v-btn>
</template>

[mario-d-s]

I would love to introduce Prettier in our Angular codebase. But my teammates can't live with what it does to inline templates... Splitting them up into separate .html files is not always desirable and would be a rather big undertaking on the existing codebase.

I think the community have proven interest in this - anything blocking this change from being made?

[alb3rtuk]

Guys what’s happening, are we gonna fix this floating-bracket problem or not?

[jasonhibbs]

It’s not prettier until this is fixed

[alb3rtuk]

If someone here knows the underlying code and can point me in the right direction of where the fix needs to be made/applied/tested I might have time to make a PR. Depends on how much work is involved, I’m very busy with work.

[dalezak]

I agree with @mario-d-s, we really want to use Prettier in Visual Studio Code, but this floating bracket in Vue templates is terrible formatting. So we're looking for alternate formatters because we don't want it polluting our code.

[alb3rtuk]

I temporarily fixed it by making my printWidth: 500px. It gets rid of the floating brackets but it's not ideal because now all of your attributes are on a single line.

[oswaldofreitas]

I temporarily fixed it by making my printWidth: 500px. It gets rid of the floating brackets but it's not ideal because now all of your attributes are on a single line.

I did the same here with printWidth: 100

[tangdaohai]

I like htmlBracketSameLine feature。please support it 😭

[udyux]

This issue is now 357 days old, has 76 comments and 187 "upvotes" on the initial comment. Browsing through the thread, it seems clear that this feature would be very appreciated by a larger audience than only React developers.

The only progress made so far seems to be 1 of the contributors agreeing that it would be interesting but there's other stuff going on.

I've just started at a new position on a team that is rewriting their frontend in VueJS. They are currently using prettier and this problem has already come up. I'd prefer we continue with prettier but without any mention of a plan to adopt from the maintainers I don't know how long we'll wait. At this point it just seems a little careless.

[EduardsE]

I don't even understand how is this the default. How is the next line closing bracket more readable than the same line.

[pyrrhicman]

Okey Seems you all want it, I was searching for this that why jsxBracketSameLine won't effect in HTML
I want it too :( in the same line

[IMalaniak]

+1

[y4n6]

Our team has been focusing on this issue since one year ago.
We never give up.

[motorstreak]

Pulled my hair out trying to figure out if I was doing something wrong - as with the requestors above, makes no sense to orphan the closing bracket in HTML.

[thorn0]

@EduardsE It's explained here: https://github.com/prettier/prettier/issues/5377#issuecomment-438457597

Related (the same way to format delimiters is discussed for CSS): https://github.com/prettier/prettier/issues/7033

Why adding an option is not an option: https://github.com/prettier/prettier/issues/40

Finally, it's not clear at all how this can be implemented for inline elements, where whitespace can't be inserted after the closing bracket in the default whitespace-sensitive mode.

<span
  long-attribute-number-one="long-value-number-one"
  long-attribute-number-two="long-value-number-two"
  >some content here</span
>

[udyux]

Finally, it's not clear at all how this can be implemented for inline elements, where whitespace can't be inserted after the closing bracket in the default whitespace-sensitive mode

@thorn0 the same way _it is already implemented_ in JSX through jsxBracketSameLine, which is exactly what this issue is about...

Why adding an option is not an option: #40

I get that the whole point of Prettier is to limit variations in form. So why add an option for React developers? Furthermore, why not extend the option's scope to cover the rest of the community given how eagerly they want to adopt it?

We could go one step further by embracing the "no options" philosophy and eliminate the jsxBracketSameLine option altogether, setting the ~default~ only behaviour to having the closing bracket on the same line seeing as very few people have voiced their support for the current default.

@EduardsE _Personally_, I don't agree with the reason linked by @thorn0 (Comments that start with "personally" should be read as opinions, not reasons). The "flow" of indentation plays a huge role in how I read my markup in order to visualize the structure. Syntax highlighting takes care of identifying different types of entities as far as I'm concerned.

The only technical argument in favour of the "newline" format that makes sense to me is by comparing it to trailingComma where re-ordering/adding props (attributes) is less prone to syntax errors.

[thorn0]

@udyux HTML and JSX are not the same and have completely different rules regarding whitespace. That's something people here just prefer to ignore. If we do it "the same way", the same people that want this option now, tomorrow will return with complaints that Prettier breaks their code by adding whitespace to their spans and links. As for block elements, do you write JS? Does it look okay to you to format functions like in this comment? How is this different from this situation with HTML tags? BTW, the Prettier team admits that adding jsxBracketSameLine was a mistake. It indeed might get removed in the future.

[lordgreg]

Is this something the prettier developers are looking into? There are quite few things that are blocking the prettier usage completely. This one with JSX implementation being one but completely avoid HTML.

[leff]

HTML and JSX are not the same ..., do you write JS? Does it look okay to you to format functions like in this comment? How is this different from this situation with HTML tags? ...

So.. HTML and JSX are too different to share styles, but HTML & JS are similar enough? That doesn't sound right. Am I missing something?

[thorn0]

@leff https://prettier.io/blog/2018/11/07/1.15.0.html#whitespace-sensitive-formatting

[leff]

"important" whitespace and tags ending on the same line are not mutually exclusive. Especially since whitespace getting in the way is rare. It is an exception. I would much rather have those rare cases look a little weird (because I formatted them in some strange way to avoid spaces) than _every_ tag look awful, and html code folding to be broken all the time.

I realize that this is just a personal preference. But it's a strong one. And it's a shame that this one little thing must come between me and a library that otherwise does everything I want.

[thorn0]

"important" whitespace and tags ending on the same line are not mutually exclusive.

They're not if you're okay with this:

<span
  long-attribute-number-one="long-value-number-one"
  long-attribute-number-two="long-value-number-two">some content here</span>

and html code folding to be broken all the time

In which editor is code folding broken? In VS Code, it isn't.

[leff]

and html code folding to be broken all the time

In which editor is code folding broken? In VS Code, it isn't.

Wow, they must have fixed that in the last few months. It's still not great in vue-html.

[leff]

Oh, and I am very much ok with your example html. But my point is that 99.9% of the time I'm ok with this html

<span
  long-attribute-number-one="long-value-number-one"
  long-attribute-number-two="long-value-number-two">
 some content here
</span>

It's very rare that the whitespace matters. In apps with thousands of html files, I might need to care in one of them? Maybe. I have flexbox and grid now, so maybe not.

[thorn0]

@leff Good for you then. Sounds like you can use --html-whitespace-sensitivity ignore for your projects. But still it's not clear how --html-whitespace-sensitivity css or strict can be combined with the proposed option. And what are your thoughts on this point? E.g. in your last message did you intentionally use different indentation levels for the attributes and the content? Do you think it's a better way to separate them visuaully?

[udyux]

@thorn0 I only just noticed your collaborator tag. I'm sorry if this is a little blunt but try turning down the dismissive, passive-aggressive and slightly condescending overtone. It contributes nothing to the discussion and risks having your valid opinions taken less seriously. "Everyone is entitled to their opinion, even if its the wrong one" doesn't work very well outside of a punchline.

I do write a lot of JavaScript on a daily basis. I also write nearly as much HTML/Vue/JSX markup and CSS/SCSS. I feel comfortable surmising that no qualified UI developer will prefer to ignore the impact of whitespace sensitivity. What you might perceive as ignorance may just be experience telling us when to give it importance. For most these instances are rare.

The JS formatting in the comment you linked to is not very readable for a number of reasons, one of which is habit/convention. But as @leff has already mentioned there is no sense in comparing JavaScript syntax and style to HTML. Even less so when, only two sentences earlier, comparing HTML to JSX is dismissed on the basis that they are completely different.

I'm of the same opinion that whitespace sensitive situations are so few and far between that I'd much rather have some awkward looking code in those cases than to format everything based on an edge-case. I've found a way to disable prettier in Vue templates and have always had jsxBracketSameLine set to true and literally cannot recall an occasion where my formatting was a problem. However, readability is absolutely a problem for me when formatted with a newline.

As for "this point", if you use an editor that has syntax highlighting I feel that it is reasonable to assume that the difference in color/contrast will suffice.

I'm probably going to put this thread aside for a while as the vibe is no longer one of collaboration and emotions are starting to come into play, myself included. I hope that we can come together to figure this out in the long run, Prettier is an awesome idea very nearly perfectly executed. This whole issue, however, will be harder to swallow for UI developers like myself who spend as much time writing markup as we do JavaScript and struggle with the cognitive load imposed by the format.

Here's to hoping for an outcome, any outcome! 🥂

[thorn0]

@udyux That's some interesting feedback. I'm indeed annoyed by the fact that people read the option philosophy page and #40, but still keep insisting that their personal habits are more important than the project's philosophy.

I feel comfortable surmising that no qualified UI developer will prefer to ignore the impact of whitespace sensitivity. What you might perceive as ignorance may just be experience telling us when to give it importance. For most these instances are rare.

Are inline links rare? Whitespace-sensitive formatting is a critical feature of Prettier. One needs to be able to reformat a project with thousands of files without a fear that this might introduce whitespace errors. This probability can't be ruled out completely, as the display property can be changed via CSS, but Prettier tries its best to be a reliable tool here. I think it's important.

The only conclusion I can draw from here is that if the requested option gets added, there still will be cases (with --html-whitespace-sensitivity set to css or strict) where it won't be possible to write > on the same line as the last attribute. The result might look really inconsistent, but given that the proponents of this option request seem to not care about whitespace, probably it would make sense to allow it only with --html-whitespace-sensitivity explicitly set to ignore.

if you use an editor that has syntax highlighting

So, we have two ways to format code. One of them needs aid from syntax highlighting to be readable and the other one is fine as is (and also is more diff-friendly). Why prefer the first one?

[udyux]

@thorn0

it would make sense to allow it only with --html-whitespace-sensitivity explicitly set to ignore

I'm not trying to be sarcastic when I say you've solved it then. That makes perfect contextual sense and communicates relatively clearly to the user what the possible implications of using the option are.

keep insisting that their personal habits are more important than the project's philosophy

I agree, a big part of what makes prettier great is how it manages to filter out that noise, all thanks to this philosophy. But when this many developers collectively express support for the same syntactical format, some might call it convention.

personal preference < prettier < convention or at least thats what I thought the idea was.

Why prefer the first one?

Readability. HTML defines the structure. It is important to be able to mentally render the structure efficiently or assess if there are technical problems in the structure (eg. missing/wrong closing tag). For me, at least, code formatting/flow helps make this happen.

[thorn0]

@udyux

But when this many developers... some might call it convention.

How many is many enough? These developers can as well be just a vocal minority whereas those who are okay with Prettier's current formatting have no reason to come here and express their opinion. Conventions emerge, mutate and go. There once was a convention that element names should be written in uppercase. Who does that today?

at least thats what I thought the idea was

The idea is: good enough consistent and reliable automated formatting > lack thereof.

_So why choose the "Prettier style guide" over any other random style guide? Because Prettier is the only "style guide" that is fully automatic. Even if Prettier does not format all code 100% the way you'd like, it's worth the "sacrifice" given the unique benefits of Prettier, don't you think?_

-- https://prettier.io/docs/en/why-prettier.html

Readability. HTML defines the structure. It is important to be able to mentally render the structure efficiently or assess if there are technical problems in the structure (eg. missing/wrong closing tag). For me, at least, code formatting/flow helps make this happen.

I don't see how what you wrote is inherent to that specific formatting style. That style appears more readable to you only because you're used to it.

BTW, Prettier editor integration really helps with syntax errors. Once you see the formatting stopped happening upon save, you know there is a syntax error somewhere.

[stephen-dahl]

Just switch your team to react like I did then you don't have to worry about it :p

joking aside, back in September I had a conversation with @lydell asking for the prettier team to give a yes or no to this.

@lydell I think this issue has reached an appropriate amount if interest to get a response saying that prettier is willing to look at options to implement the requested change or closing the issue with a brief explanation of the reasoning.

My proposal is to rename the option jsxBracketSameLine to htmlBracketSameLine and have the option cover jsx and html. deprecate jsxBracketSameLine and remove it in the next major version.

Or heck, if we dont want the option how about changing the default? I would be surprised if more people want the current behavior than want this behavior.

the core of the response was

Personally I think it makes sense changing jsxBracketSameLine to something that applies to both JSX and HTML. But right now we need to focus on getting the next release out.

I understand the reasoning for leaving the issue open but still think that this needs a definitive response. Is there a process for reaching a final (for now) determination on these types of requests? If not one should probably be added. In the end we are arguing about preference and opinion, but lost argument is better than one that never ends or is ignored.

[alexander-akait]

I think we need twitter poll to make the final decision like. Will be great also ask developers about change default behavior, to find out how much this behavior is not very convenient.

/cc @prettier/core what do you think about it?

[lydell]

@evilebottnawi I don’t think we should make a Twitter poll: https://github.com/prettier/prettier/pull/3903#issuecomment-555112516

Personally I’m in favor of changing this option to cover all HTML-like syntax.

[alexander-akait]

@lydell i think we can implement htmlBracketSameLine right now and union jsxBracketSameLine and htmlBracketSameLine in future, in theory we can do it right now in next, but I'm afraid we don’t have enough time right now for this

[thorn0]

I'd like to remind that jsxBracketSameLine was added only because this was an easy way to get Prettier adopted inside Facebook. It was important for the project to get traction back then, but why do we need another such trade-off today? The potential interference of this option and --html-whitespace-sensitivity looks like a Pandora's box of problems to me. Keep it simple and resist adding configuration, anyone? What happened to that?

[alexander-akait]

@thorn0 sometimes the developers love ugly, and unfortunately we can’t ignore them, then there come moments like now, I fully support the rejection of extra/unnecessary options and even wanted to delete some of them in the future, but there are very holywar moments that we still have to take into account

[stephen-dahl]

@thorn0 what if prettier simply left the ending bracket alone.
let

<tag
  arg=value
>
  content
</tag>

and

<tag
  arg=value>
  content
</tag>

both exist. That should address your white space concerns, removes the need for an option, and lets both sides of this issue get their way. prettier can just look at if the > is on a new line or not and format accordingly

[stephen-dahl]

this might also allow you to get rid of the jsx option

[thorn0]

@evilebottnawi Developers have their opinions, Prettier is supposed to have an opinion too. This issue is not nearly as divisive as tabs-vs-spaces and semi-vs-no-semi.

BTW, just thought that it might be a natural process that in these days of frameworks like Vue and Angular, when tags have more attributes than they used to, there is a need for a clearer separation of the attributes and the content. And that's what Prettier's current style achieves.

@stephen-dahl It'd be a huge sacrificing of consistency. Prettier tries to keep as less of the original formatting as possible.

[udyux]

How many is many enough?

I'd like to remind that jsxBracketSameLine was added only because this was an easy way to get Prettier adopted inside Facebook

@thorn0 I feel like you've answered your own question here.

In other news, turns out my workaround in Vue templates was temporary. We've had to turn off Prettier for .vue files entirely. There are conflicts somewhere between the vue/recommended, airbnb and prettier eslint configs. We have prettier as the last reference under extends. Around one third of our files toggle between formats on a closing bracket every time the file is formatted. Both results trigger lint errors.

What this underlines is that prettier is almost never used alone and while eslint is not a formatter, it does try to fix errors automatically. We now need to make a huge sacrifice in consistency to preserve our lint configuration. We simply don't have the time right now to dive into debugging this sort of issue.

@stephen-dahl I recently switched jobs so I could stop working with React ;)

[lydell]

@udyux Maybe you forgot to add prettier/vue to the extends array? Also note that ESLint has a --fix flag that fixes many, but not all, problems.

[thorn0]

I think a good and honest response for issues like this might be: _We're not sure this is the right thing to do. If you really need this functionality, feel free to fork Prettier and publish your fork. If we see that it's used really a lot, we will consider a merge_.

Because we really are not sure, and how else can we measure the demand? ¯\_(ツ)_/¯

@udyux It was a completely different phase of this project, with completely different concerns.

We simply don't have the time right now to dive into debugging this sort of issue.

Yet, you're advocating increasing Prettier's configuration complexity so that people would need even more time to wrap their head around it.

[hansfelix]

Can't you give the same option? (React-jsx user have the option "jsxBracketSameLine" while Vue and Angular users not ) I don't think it's a inconsistency matter, It´s a matter to keep the same options in all the frames.

I hope to use this functionality in vue 😥

[jiankafei]

Perhaps we should name it to angleBracketSameLine.

Perhaps we should name it to “bracketSameLine” for all tag template, include jsx.

[nassimbenkirane]

For reference, the google html styleguide looks like this : https://google.github.io/styleguide/htmlcssguide.html#HTML_Line-Wrapping

<md-progress-circular
    md-mode="indeterminate"
    class="md-accent"
    ng-show="ctrl.loading"
    md-diameter="35">
</md-progress-circular>

After fighting a bit with this, we're going to use Beautify for now for html formatting. I hope this option is implemented and our team can use prettier for HTML soon.

To the maintainers and contributors : thanks for the great work 👍!

[tihomir-kit]

This is an inconsistency in prettier because it was react-focused. Other frameworks exist, and there is a clear problem with this feature which is not being addressed.

[sangeet]

I'm sorry to ask this question here. I'm using plain HTML and I want to have the angle bracket not take it's separate line

What I dont want :

<div
  class="flex items-center justify-center w-20 h-20 bg-red-500 rounded-full"
>
  <img src="images/SectionOne/icon-android.png" alt="" />
</div>
````

What I want :
```html
<div class="flex items-center justify-center w-20 h-20 bg-red-500 rounded-full">
  <img src="images/SectionOne/icon-android.png" alt="" />
</div>

I see that this is currently being discussed. Is there a way to change the settings current and not have it break down in a separate line? How can I disable this in the meanwhile?

[GlThibault]

I see that this is currently being discussed. Is there a way to change the settings current and not have it break down in a separate line? How can I disable this in the meanwhile?

There is no option in Prettier for this @sangeet. Your best option should be to use another formatter for HTML.

[danielehrhardt]

Something new here?
It would be really nice if we have that.

[devilyouwei]

We truly need angleBracketSameLine, from a vue developer

[otomeskhy]

Just read the whole discussion and switched to Beautify...

I mean, there is no reliable way to "measure the demand", some people don't care to dig more and just ditch Prettier for html/vue/ag files and that's it.

And if we're talking consistency, having that option for jsx and not for anything else is nothing short of funny.

[alexander-akait]

/cc @prettier/core Let's pay attention to this problem, it is very popular

[elesueur]

I'm also going to disable prettier's HTML formatting, until it produces formatting like presented in:

https://github.com/prettier/prettier/issues/5377#issuecomment-581673350

[tarponjargon]

We truly need angleBracketSameLine, from a vue developer

agree

[Gaabooo]

We definetly need angleBracketSameLine to avoid this:

<v-btn
  v-if="condition"
  >{{ bar }}</v-btn
>

edit: Added Expected Outputs and final comment.

Expected Output Option One:

<v-btn
  v-if="condition">
{{ bar }}
</v-btn>

Expected Output Option Two:

<v-btn v-if="condition">{{ bar }}</v-btn>

I think > should be appended to the end of the attributes and never alone.

[dylanmcgowan]

Hi, another Vue dev in pain here - please add angleBracketSameLine

edit: look how this a tag is formatted..

Prettier output - notice placement of the opening & closing >:

<a
      href="https://github.com/nuxt/nuxt.js"
      target="_blank"
      class="button--grey"
      >GitHub</a
>

Expected Output Option One:

<a
  href="https://github.com/nuxt/nuxt.js"
  target="_blank"
  class="button--grey"
>
  GitHub
</a>

Expected Option Two:

<a
  href="https://github.com/nuxt/nuxt.js"
  target="_blank"
  class="button--grey">
  GitHub
</a>

Either of those would be acceptable IMO. Why is the closing > getting exploded - why is that tag not whole? And what's up with the opening > ? That should be on its own line or appended to the end of the attributes. The markup is extremely illegible in its current state.

[lydell]

@Gaabooo and @dylanmcgowan Could you also show your expected outputs, please?

[dylanmcgowan]

@lydell updated my comment

[lydell]

@dylanmcgowan Thanks! I don’t think the proposed option here is what you’re looking for. It sounds like you’re looking for HTML Whitespace Sensitivity.

[Gaabooo]

@lydell edited my comment as well :)
It's exactly this:
https://prettier.io/docs/en/options.html#jsx-brackets

[lydell]

@Gaabooo Same thing with your “Expected Output Option One”. The placement of the > wouldn’t help there – you’re looking for HTML Whitespace Sensitivity.

[Gaabooo]

@lydell I'm looking for a way to have the > aligned correctly with the corresponding tag.
Already tried with HTML Whitespace Sensitivity but didn't solve the issue

[lydell]

@Gaabooo Ah, I see, you probably need HTML Whitespace Sensitivity _plus_ this proposed option.

[Gaabooo]

@lydell Exactly that ❤️

[MikeMitterer]

I thought this problem is solved for Vue with version 2 but it isn't :cry: Closing bracket for templates are still on a new line...

[Nightbr]

Our solution:

In your settings.json

"[html]": {
    "editor.defaultFormatter": "vscode.html-language-features"
  },

[katowulf]

@Nightbr any idea where would one put this in a Vue project? Doesn't seem to be a settings.json file.

[Nightbr]

The settings.json is for VS code. You can edit your global settings.json or in your project create it in .vscode/settings.json.

[emilyplusplus]

How is this still now fixed?? None of these proposed 'solutions' work for template tags in Vue components... :/

[danielehrhardt]

Please fix it!!

[oswaldofreitas]

wow, from Nov 2018 and not fixed yet, looks like the maintainers just don't care about our voice here

[EyePulp]

@oswaldofreitas That's pretty passive/aggressive snark if not sarcastic. I think a more gracious read is "you get what you pay for" and they probably have other priorities. Raising issues is fine, but acting entitled and hurt when an issue isn't addressed as fast as you like doesn't help anyone.

[Gaabooo]

Agreed. Just chill man, you can always take it out of your project. But you are not "entitled" to ask for anything, especially not being that rude. If you ask for something do it nicely especially when what you are getting is free volunteering work from others.

[karptonite]

Yes, I'd also like this feature incorporated, but those who put in the work can set their own priorities.

However, that the "needs discussion" status may be outdated. We have had a lot of discussion on this, and it might be time to decide either to put angleBracketSameLine on the list of features to implement (on the maintainers' timetable) or to decide that it is undesirable to expand the jsx rule to html for some reason.

[stephen-dahl]

Yes, I'd also like this feature incorporated, but those who put in the work can set their own priorities.

However, that the "needs discussion" status may be outdated. We have had a lot of discussion on this, and it might be time to decide either to put angleBracketSameLine on the list of features to implement (on the maintainers' timetable) or to decide that it is undesirable to expand the jsx rule to html for some reason.

lol said this back in september https://github.com/prettier/prettier/issues/5377#issuecomment-531866285

[karptonite]

@stephen-dahl Well, back in September, all focus was on getting 2.0 out. Maybe now there is finally bandwidth to revisit this.

[oswaldofreitas]

hey guys, sorry if I looked rude, but I wanted to say there is a big voice here asking this feature and I've read some comments in the past in this same thread from one of the maintainers saying something about number of people that are not adding their input here and could be way bigger than "us" (which asked the feature) and wouldn't want this, also there was a discussion about prettier shouldn't have options, so I thought it was just a disrespect with the ones which wrote here asking for this feature and didn't have any updates from the maintainers since from 2018 at least just to say "hey, this is in the roadmap, just wait a bit more since we're taking care of other things".

This is a pretty great lib though and I wouldn't like to remove it from my project just because a feature that I could wait to be added. What I would like actually is just to have more feedback in an interval shorter than 17 months.

[EyePulp]

@oswaldofreitas those are reasonable points, and it's understandable if you're frustrated by not seeing a response or fix after this length of time.

FWIW - I cleaned out my eslint config and found the minimal settings needed to prevent the particular issue I was complaining about inside my Vue HTML blocks. This doesn't solve the problem for everyone, but it does let me keep using prettier for html. "htmlWhitespaceSensitivity": "css" was probably the biggest part of it, and realizing that I didn't have all the plugins properly required & installed at the project level in my package.json. Using the OUTPUT tab under VSCode to see eslint errors made the debugging much easier.

// eslintrc.js
module.exports = {
    plugins: ['vue', 'prettier'],
    extends: ['prettier', 'plugin:vue/recommended'],
    rules: {
        'vue/no-v-html': 'off',
        'vue/attribute-hyphenation': 'off',
        'prettier/prettier': 'error',
        'vue/max-attributes-per-line': [2, { singleline: 10 }],
        'vue/html-closing-bracket-newline': 'off',
        'vue/html-indent': 'off',
        'vue/html-self-closing': 'off',
    },
};

// .prettierrc
{
    "trailingComma": "es5",
    "tabWidth": 4,
    "printWidth": 100,
    "singleQuote": true,
    "arrowParens": "always",
    "htmlWhitespaceSensitivity": "css"
}

// package.json
{  
   //...
    "devDependencies": {
     //...
        "eslint": "^6.8.0",
        "eslint-config-prettier": "^6.10.1",
        "eslint-plugin-prettier": "^3.1.2",
        "eslint-plugin-vue": "^6.2.2",
        "prettier": "^2.0.4",
    },
}

[oswaldofreitas]

@EyePulp thank you for your tips, what I've used that helped was the printWidth: 100 that's in your settings too

[brokenthorn]

So basically it happens with inline elements (according to CSS defaults) because white space is significant in those and adding a line break adds a space, inline, in the rendered output.

Here's some valid Prettier formatted code:

<!-- valid -->
<template>
  <div>
    <p v-if="request">{{ request }}</p>
    <p v-else class="error pa-2">
      Nu s-a găsit cererea de produs cu
      <code>ID={{ $route.params.id }}</code>
      !
    </p>
  </div>
</template>

If I don't want that extra space between the content between the code tags and !, I write this:

<!-- invalid -->
<template>
  <div>
    <p v-if="request">{{ request }}</p>
    <p v-else class="error pa-2">
      Nu s-a găsit cererea de produs cu
      <code>ID={{ $route.params.id }}</code>!
    </p>
  </div>
</template>

But Prettier complains:

So if I let it fix it, it produces this:

<!-- valid -->
<template>
  <div>
    <p v-if="request">{{ request }}</p>
    <p v-else class="error pa-2">
      Nu s-a găsit cererea de produs cu
      <code>ID={{ $route.params.id }}</code
      >!
    </p>
  </div>
</template>

I think this is ugly. The previous <code>ID={{ $route.params.id }}</code>! was much better.

Funny thing, even doing the following makes Prettier happy again:

<!-- valid -->
<template>
  <div>
    <p v-if="request">{{ request }}</p>
    <p v-else class="error pa-2">
      Nu s-a găsit cererea de produs cu
      <code>ID={{ $route.params.id }}</code> !
    </p>
  </div>
</template>

Notice the extra space before the ! that I didn't want. So either I'm happy, or Prettier is, but not both.

[i-nata]

In file '.prettierrc' use { "htmlWhitespaceSensitivity": "ignore"} it fixes this problem.

[brokenthorn]

In file '.prettierrc' use { "htmlWhitespaceSensitivity": "ignore"} it fixes this problem.

No, this does not fix the problem. That option comes with a warning. Basically that option says that you do not care about white space being something significant in inline elements. This ends up altering the intended rendered output. Please read this from the Prettier blog.

To save you some time, here's a quick explanation taken from that link.
Take the following HTML snippet:

<!-- <span> is an inline element, <div> is a block element -->

<!-- input -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>
<div class="voluptatem architecto at">Architecto rerum architecto incidunt sint.</div>

Prettier, without altering its default white space behavior, outputs this as:

<!-- output -->
<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>
<div class="voluptatem architecto at">
  Architecto rerum architecto incidunt sint.
</div>

Why? Because span cares about white space and includes it in the output, so if Prettier had formatted that span like this:

<!-- rendered output ALTERED, NOT INTENDED -->
<span class="dolorum atque aspernatur">
  Est molestiae sunt facilis qui rem.
</span>

That would have included the space(s) before Est and the space(s) after rem. including the newline and space(s) after that, into the span, space(s) that weren't there in the source, before reformatting.

div's a div... a block element, it ignores white space. No issues there.

I've change my mind about Prettier here thanks to to that blog post. In fact, it's doing the right thing. I was quickly back to loving it. 😁

[devansvd]

Any updates on this ? Very frustrating, desperately need this option. Pls consider.

[OdinTech3]

How do I get this same behavior working in vue components?

[milesje]

Also looking for a way to fix this in HTML template literals used in Polymer and LitElements.

[hege088]

I also absolutely need this feature for html.

[867380699]

+1

[TotooriaHyperion]

I finally understand why htmlWhitespaceSensitivity strict/css cause that ugly template format.

It's necessary because if you care about spaces in html, then you better to let extra spaces or (\n)s to be appear within the bracket so that the spaces in template won't disturb the real html.

So if you don't care about spaces, \n, \r in html, then use { htmlWhitespaceSensitivity: "ignore" }
If you really care about it, what prettier did with { htmlWhitespaceSensitivity: "css"/"strict" } is necessary and inevitable.

Remember don't be blind to those spaces in your template as what you did when using jsx. It's totally different thing. You should double check which spaces are necessary and which are not.

If you really want beautiful format and care spaces the same time, then put those necessary spaces or (\n)s into a span with {{}} and use { htmlWhitespaceSensitivity: "ignore" }.

Check the difference below. Then you would find it inevitable to keep bracket together with text node when formating a long single line html to multiple line with spaces in concern.

[karptonite]

@TotooriaHyperion Look at the initial post in this issue again to see an example of what we are asking for, in terms of formatting. It is possible to respect white space while putting (in some cases) a closing > on the same line as the rest of the closing tag, rather than at the beginning of the next line. To some of us, anyway, that makes the formatting less ugly.

[OdinTech3]

It also messes up code folding in vscode

[dinedal]

I'm not sure why this is a good formatting?

This is with { htmlWhitespaceSensitivity: "ignore" } set, BTW. Why can't the closing tag's > live with it?

[fipstree]

Please fix this. Currently it makes my code look more ugly than before formatting ... :-(

[OdinTech3]

What would it take for this to be fixed cuz @fipstree is right, the
formatting doesn't look great. Also don't even see the benefit of the
current formatting behavior.

On Thu, May 7, 2020, 4:07 AM fipstree [e-mail] wrote:

Please fix this. Currently it makes my code look more ugly than before
formatting ... :-(

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/prettier/prettier/issues/5377#issuecomment-625099478,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADMY5F7AHMJ4SWIU6J2ZMK3RQJT4NANCNFSM4GCMT42A
.

[adamJLev]

Am I going crazy or is htmlWhitespaceSensitivity: "ignore" simply not working? Is it actually working for you guys?

I am on latest (prettier 2.0.5) and even with that option, it transforms my html and puts > on a new line. What is going on?

Very simple reproduction code: https://codesandbox.io/s/prettier-ignoring-v4xe5?file=/index.html
Try reformatting that bit of html, hit save and boom its ugly again.

I thought it could be a Codesandbox quirk, but you will get the same result if you download the files and try the same locally. any ideas?

[frostbytedata]

htmlWhitespaceSensitivity: "ignore" does not seem to work in my codebase either.

[lydell]

@adamJLev @frostbytedata Can you reproduce your issue in the playground? :pray:

[adamJLev]

@lydell hi! yes here: https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAeARhAJgTwHwA6UABMalgJYBuRppYANgIYDOLAvASAGYQTE4mWLEy606MCjAZxOIdEwBOYknRYwcMuQFslAcwpQAtDAgAHJMQCMABjMAPANwq6xJRSZHm6OAznx1LkJVUgAJXwZ+AHcIRQYscVQAekoqYMSWMEUKMxhg1xkYYl5+dmIuEpcyJMzs3ODkzFxgkAAaEHNJaBZkUCVFCCiABSUEHpQmBiimHB729EUmMABrOBgAZTMlwz1kGEUAVzh2gAsYbQYAdROpOBYtsDh1salqKRxkEAo9KFi4Nq+UBYcEUMCGiz0umQ3EmwPaACsWPYAEKLFZrdZMbRwAAyhn+SBhDDhIER9nWOxkAEUDhB4NDYccQFtFMDFJ8zhcAWZsrBLhQsDATsgABw2do8iDAy6LMyfHl3EFUf7tACOtPg4PM4xArCMUDgcCwRoBijg6ooZvBTEhTAZxKZwO0FD2h0dlLgNLpBKJJJgTHQ-MFwqQACZ2vsmBQGDsAMIQbRQlB3ACsAIOwIAKgHxr6mVQjgBJKDG2DrLI5GAAQRL6w0MntwIAvk2gA

[lydell]

@adamJLev Thanks! That looks like expected to me. What do you expect the code to look like?

Edit: I get it. You want it to look like the input, right? If so – that’s currently not possible (and not what htmlWhitespaceSensitivity: "ignore" is supposed to do), and that’s what this issue is about. (Although some people are talking about line breaks in end tags </a\n> and stuff, which would be a different issue, but :shrug:)

[adamJLev]

with this setting htmlWhitespaceSensitivity: "ignore", I expect Prettier to stop trying to move closing angle brackets to its own line:

Basically the setting doesn't seem to be working. or am I missing something? (Edit by @lydell: See the comment just above ☝️ )

The real solution would to to have a jsxBracketSameLine type of setting that works with regular html/vue, but this would be a decent workaround for now.

[frostbytedata]

My playground seems to be exactly the same as @adamJLev so thank you for that explanation @lydell. I also read the blog post above about why prettier behaves this way with inline html elements. It can affect the way the HTML behaves, and I quickly realized how asking for this by default would be a mistake. However, it would be nice to have an option that must be explicitly enabled so those of us that understand this consequence, can use it to have the closing > bracket displayed as we would like.

I guess my mistake was I assumed using htmlWhitespaceSensitivity: "ignore" was that explicit setting, but it appears the behavior is not possible even with that set to "ignore". Am I misunderstanding?

[lydell]

Am I misunderstanding?

No, you are correct! "ignore" means “ignore the whitespace rules of HTML and always break lines and indent and format as much as you want” (where you=Prettier).

[adamJLev]

Got it, thanks for the explanation @lydell!

Hope jsxBracketSameLine-like functionality can be ported to work with html and vue as well soon, this is basically the only thing stopping me and many people from using prettier for their projects.

[lydell]

Is there a particular reason this is stopping you? Is it breaking tooling for you, or is it so visually annoying to your eyes that you’d rather have no automatic formatter, or something else?

[frostbytedata]

Sadly, for me and my team, it would be the latter. Thanks for your help though @lydell!

[dinedal]

@lydell OK, so it's pretty clear to me after reading the thread and seeing this issue and how it's handled that Prettier should just drop HTML formatting support because clearly you prefer to support React instead.

Look at this. This is _not_ properly formatted HTML. This is what Prettier outputs.

Here is a sane style guide for HTML: https://google.github.io/styleguide/htmlcssguide.html
Here is another one: https://www.w3schools.com/html/html5_syntax.asp

Show me a single style guide in which the below is advocated please.

</textarea
        >

[lydell]

OK, so it's pretty clear to me after reading the thread and seeing this issue and how it's handled that Prettier should just drop HTML formatting support because clearly you prefer to support React instead.

What do you mean? 😢

---

Yeah, having a line break inside an ending tag is super weird. I’ve been meaning to open an issue about that for a couple of days. Hopefully this is the kick in the butt I need to finally do it.

[adamJLev]

Please @lydell YES do it 🤗
If it was worth adding that flag for JSX, its certainly worth adding for normal HTML and vue!

My Vue code wants to look cute but it just cant, with that ugly hanging angle bracket in there.

Thanks!

[lydell]

Alright, here’s the issue about avoiding line breaks in end tags:

https://github.com/prettier/prettier/issues/8302

Note: This issue (#5377) is about the want to format:

<div
  id="main-content"
  class="home-section home-section--highlighted"
  data-binding="home"
>
  Some text
</div>

…like this:

<div
  id="main-content"
  class="home-section home-section--highlighted"
  data-binding="home">
  Some text
</div>

Like you can in JSX. But! You can still end up with a > on its own line for inline elements, since there’s no safe way to break lines otherwise (see the _start_ tags of the following two examples). (You can opt-out of safety via htmlWhitespaceSensitivity: "ignore".)

The new issue (#8302) is about avoiding line breaks in end tags. Instead of this:

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>

…you’d get this:

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span>

[adamJLev]

Thanks for claryifing @lydell , I was under the impression this is the same issue fixed at once.
But its a slightly different thing.

For the feature requested in this issue right here - I would propose calling this new option htmlBracketSameLine would make sense, and allow things to be consistent between JSX code and HTML code in the same codebase too which would be 👍 👍

[karptonite]

Is it likely that someone would want to format a code base with jsxBracketSameLine but not htmlBracketSameLine or vice versa? If not, as @j-f1 proposed, angleBracketSameLinecould cover both settings, and we don’t even have to increase the number of options. 😀

[nassimbenkirane]

@lydell thanks for responding to this issue 👍
I'm not sure what you mean by

You can opt-out of safety via htmlWhitespaceSensitivity: "ignore"

With the new issue (#8302), if you were to set this config (htmlWhitespaceSensitivity: "ignore"),
would this:

<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>

be transformed into this (as many people in this thread would like ?):

<span class="dolorum atque aspernatur">
    Est molestiae sunt facilis qui rem.
</span>

or is that the case that even with htmlWhitespaceSensitivity set to "ignore", the prettier team's preference goes towards adding a linebreak before the opening tag ?

[nassimbenkirane]

Sorry I should have read more carefully

@adamJLev Thanks! That looks like expected to me. What do you expect the code to look like?

Edit: I get it. You want it to look like the input, right? If so – that’s currently not possible (and not what htmlWhitespaceSensitivity: "ignore" is supposed to do), and that’s what this issue is about. (Although some people are talking about line breaks in end tags </a\n> and stuff, which would be a different issue, but 🤷)

[adamJLev]

Is it likely that someone would want to format a code base with jsxBracketSameLine but not htmlBracketSameLine or vice versa? If not, as @j-f1 proposed, angleBracketSameLinecould cover both settings, and we don’t even have to increase the number of options. 😀

That's true, even better!
Prettier team, Pretty please I beg you! haha. Let us bask in the same beautiful code that JSX users get. Based on what I see being done for JSX, its likely under 10 lines of code to achieve the same effect same for html.

(In case anyone else is curious: https://github.com/prettier/prettier/blob/master/src/language-js/printer-estree.js#L2269 )

Thank you.

[adamJLev]

Here's the 2 line code change to get this working by default anyone is interested:
https://github.com/adamJLev/prettier/commit/a0cd45b4cbea2039941f5cea0dccacf506b0fd2e

Its a ductape solution obviously and updating all the unit tests that expect the previous style, and making it configurable via options would take a lot longer, but hopefully the @prettier team will feel inclined to add this change properly into the project after people have been asking for it for 2 years now 😄

Feel free to install my fork and get actually pretty Vue/html files again:

yarn add "https://github.com/adamJLev/prettier#b0b0c28799d25c2c8a4c67fc1285f7e1183f6b9b"

I'll try to keep my fork up to date with upstream since i'll be using this for different projects myself too. 🤓

[frostbytedata]

Beastmode @adamJLev! Thanks!

[sergeyfilimonov]

@prettier please include @adamJLev solution in the next release

[tommcclean]

Concur with this thread; this is stopping me from using Prettier.