Prettier: HTML TODOs

[ikatyang]

This issue tracks HTML issues that should be done before the public release.

---

Please take a look at #5259, which should address this issue.

---

Try out the current experimental HTML support:

yarn add prettier/prettier
yarn prettier filename.html 

or preview playground in #5135.

---

| icon | description |
|-|-|
| ✔️ | merged |
| 👀 | in review |
| 🔜 | #5259 |
| 🏃 | WIP |

---

Features

• [x] support front matter
  
  
  
  • #5110
  
  
• [ ] support pragma
  
  
  
  • 🔜
  
  
• [x] unambiguous/XHTML-compatible output for void tags (e.g., <br />) (reason)
  
  
  
  • #5116
  
  
• [ ] html in js template literal (comment)
  
  
  
  • 🔜
  
  
• [x] whitespace-sensitive formatting (comment)
  
  
  
  • #5168
  
  
• [ ] recognize CDATA (comment)
  
  
  
  • 🔜
  
  
• template languages
  
  
  
  • [ ] format interpolation {{ js expression }} (comment)
  
  
  • 🔜
  
  
  • maybe support bracketSpacing? (no, it's not supported in JSX)
  
  
  • Angular
  
  
  • [ ] format attribute binding syntax (*ngIf, [target], (target), [(target)])
    
    
    
    
    
    • 🔜
    
    
    
  
  
  • [ ] format inline template (@Component({ template: `html` }))
    
    
    
    
    
    • 🔜
    
    
    
  
  
  • Vue
  
  
  • [ ] format attribute binding syntax (:class, v-if, v-bind:id, @click)
    
    
    
    
    
    • 🔜
    
    
    
  
  

Bug fixes

• [x] exclude comments from fragment detection (outdated)
  
  
  
  • #5100
  
  
• [x] remove extra trailing newline for <template> (repro)
  
  
  
  • #5127
  
  
• [x] add missing trailing newline for <style> (repro)
  
  
  
  • #5111
  
  
• [x] preserve HTML entities
  
  
  
  • #5119 #5127
  
  
• [x] preserve case-sensitive tags
  
  
  
  • #5101
  
  
• [x] preserve case-sensitive attributes
  
  
  
  • #5109
  
  
  • [x] non-HTML attributes should be considered case-sensitive (repro, comment)
  
  
  • #5135
  
  
• [x] support custom self-closing tags (repro)
  
  
  
  • #5117 #5127
  
  
  • [ ] disable custom self-closing recognition in --parser html and enable it in --parser vue (comment)
  
  
  • 🔜
  
  
• [x] do not format custom script (repro, comment)
  
  
  
  • #5132
  
  
• [x] no inconsistent output for 2+ attributes (repro, comment 1, comment 2)
  
  
  
  • #5134 #5168
  
  
• [x] force break tag if there're multiline attributes (repro, comment)
  
  
  
  • #5134 #5168
  
  

Chores

• [x] playground
  
  
  
  • #5105
  
  
• [x] switch to htmlparser2
  
  
  
  • #5127
  
  
• [x] rename --parser parse5 with --parser html
  
  
  
  • #5127
  
  
• [ ] update homepage

(If you report an issue here, I'll update the list and hide your comment to keep this thread clear.)

[StarpTech]

I faced with the same issues in https://github.com/Prettyhtml/prettyhtml and that's the reason why I maintain a fork of parse5 which is capable to handle all the special cases:

• [X] preserve case-sensitive tags
• [X] preserve case-sensitive attributes
• [X] preserve self-closing custom elements
• [X] preserve HTML entities
• [X] preserve leading newline in textarea and pre tags
• [X] disable foster parenting (moving tags out of tags where the tag isn't allowed but still useful in template language like angular etc...)
• [X] allow creating arbitrary HTML constructs with table elements and inside those without to strip them out.

This will cover most of the use cases. Prettyhtml is already used in production.

[alexander-akait]

@StarpTech can you take care to switch on fork? I agree what original parse5 is very bad for us purposes

[alexander-akait]

@StarpTech also i noticed you already have pretty tool for html (and templates based on html) https://github.com/Prettyhtml/prettyhtml, maybe we can union? Will be great have one tool.

[StarpTech]

can you take care to switch on fork? I agree what original parse5 is very bad for us purposes

Hi @evilebottnawi could you elaborate at first your purposes with the implementation? There is no agreement what the html formatter should exactly support. Look in the PR https://github.com/prettier/prettier/pull/4753#issuecomment-405822476 none HTML5 features like case-sensitive attributes, tags were declined from collaborators so I would like to know what're the plans?

... Prettyhtml/prettyhtml, maybe we can union? Will be great have one tool.

Yes, that was my first idea but prettier didn't follow the same goals. You wanted to provide a pure HTML5 formatter. Now my formatter is ready and already in production. It would be great to help anyway. I can take care of the parse5 fork and can assist you on your PR's.

[suchipi]

@StarpTech I'm sorry for the miscommunication, but I think we want to be able to format Angular, glimmer, etc eventually- what goals of ours are not aligned with prettyhtml?

Sorry I didn't sort this out sooner. I saw your comment back then but didn't look into the details about why our team decided to take a different approach.

[StarpTech]

@suchipi thanks for the clarification 👍 Could you add it to the issue description?

what goals of ours are not aligned with prettyhtml?

As a whole, it's almost the same but I'm working according to the HAST specification and can use all the tools around it which makes code more readable and maintainable but the biggest point is that the job is done and I don't want to investigate a second time. But it would be great when prettier could win from my efforts. As I said above I can help out with the parser and can provide useful test-cases.

[StarpTech]

@evilebottnawi @suchipi Perhaps it's a good idea to change to a more XML-like parser like https://github.com/fb55/htmlparser2 in order to respect all the different none HTML5 compliant use-cases and without to change any content. The parser would have the same interface. It already provides options for case-sensitive tags and decoding etc...

While parse5 is great it will always focus on HTML5 spec correctness. I could fix most of the use-cases but a parser without all these knowledge would be easier to maintain.

[resolritter]

When trying to use the current master branch version (79d510cf31ff9d09304e3bb54bc81160b384ec2b) and --parser parse5 in the file below, I get the following behavior:

https://github.com/skyronic/vue-spa/blob/master/src/App.vue

1. The content inside of <template> seems to be indented, however an extra newline is added before the closing tag every time I run the command.
2. The newline before the closing <style> tag is removed.

Before running Prettier:

<template>
  <div class="app">
    <div class="header">
      <header-bar></header-bar>
    </div>
    <div class="page">
      <router-view></router-view>
      <div class="help-text">
        <p>Vue.js 2 Single Page App (SPA) Example with vuex and vue-router.</p>
        <a href="https://github.com/skyronic/vue-spa">View Source Code</a>
      </div>
    </div>
  </div>
</template>

<script>
import HeaderBar from '@/components/HeaderBar'
export default {
  components: {
    HeaderBar
  },
  name: 'app'
}
</script>

<style>
body {
  font-family: "HelveticaNeue", "Helvetica Neue", Helvetica, Arial, sans-serif;
  color: #333;
}
.app {
  display: flex;
  flex-direction: column;
  width: 100%;
}

.header {
  border-bottom: 1px solid #b3b3b3;
  width: 100%;
  padding: 30px 50px;
}

.page {
  width: 100%;
  padding: 30px 50px;
}

.help-text {
  margin-top: 20px;
  font-size: 12px;
}
</style>

After running prettier on the file - notice the extra newline before </template> and the missing newline before </style>:

<template>
  <div class="app">
    <div class="header">
      <header-bar></header-bar>
    </div>
    <div class="page">
      <router-view></router-view>
      <div class="help-text">
        <p>Vue.js 2 Single Page App (SPA) Example with vuex and vue-router.</p>
        <a href="https://github.com/skyronic/vue-spa">View Source Code</a>
      </div>
    </div>
  </div>

</template>

<script>
import HeaderBar from '@/components/HeaderBar'
export default {
  components: {
    HeaderBar
  },
  name: 'app'
}
</script>

<style>
body {
  font-family: "HelveticaNeue", "Helvetica Neue", Helvetica, Arial, sans-serif;
  color: #333;
}
.app {
  display: flex;
  flex-direction: column;
  width: 100%;
}

.header {
  border-bottom: 1px solid #b3b3b3;
  width: 100%;
  padding: 30px 50px;
}

.page {
  width: 100%;
  padding: 30px 50px;
}

.help-text {
  margin-top: 20px;
  font-size: 12px;
}</style>

[ikatyang]

@jpsouzasilva Thanks! Updated the list.

[resolritter]

@ikatyang just a heads-up that even after https://github.com/prettier/prettier/commit/4a084c82a1a978da0725f52f34a8a6a00c264640, the newline is still added before the closing </template> tag, which is problem 1 described in https://github.com/prettier/prettier/issues/5098#issuecomment-422613008.

Problem 2 about the closing </style> tag seems to have been fixed.

[ikatyang]

@jpsouzasilva I haven't fixed that one yet, see https://github.com/prettier/prettier/issues/5098#issue-360547824 for the current progress, fixed items will be ✅.

[michaeljota]

It would be nice if this could also order the attributes. Maybe this could implement the Code Guide Style Guide for that.

Attribute order

HTML attributes should come in this particular order for easier reading of code.

• class
• id, name
• data-*
• src, for, type, href, value
• title, alt
• role, aria-*

Classes make for great reusable components, so they come first. Ids are more specific and should be used sparingly (e.g., for in-page bookmarks), so they come second.

Although, I see how this could let to an opinion debate really quickly, so if not, that's ok too.

UPDATE: A use case: Attribute order template

[alexander-akait]

@michaeljota not sure it should be do prettier

[ikatyang]

We don't do sorting, but we may expose some entries to plugins for transforming the AST before printing in the future, which should be suitable for your use case (i.e., sorting).

[StarpTech]

@ikatyang @michaeljota I would prefer to specify a fixed set of rules rather make everything pluggable because that would be the opposite of prettier philosophy right?

IMO Prettier should just format in a consistent way without any interpretation.

[michaeljota]

If you ask me, I prefer no to worry about rules or plugins, but to have a consistent format in all my files. As I do in JS. Sure, I don't like some things Prettier does, but I learn to not care, because its better to no think about it.

[michaeljota]

One thing to notice when preserving casing attributes, Angular (again) may need this attributes in html elements, so #5109 is not suitable for this use case.

Repo

Also, with that, I think that interpolations should be spaced. {{ [space] A real content [space] }}

Update: It also reproduce when using binding syntax:

Repo

Note: I understand as for now, it only checks if the tag is a custom tag or not, but attaching that scenario just to track it in the implementation

[michaeljota]

Using deploy from #5119:

Custom tags are not indented in the same line:
Repo

[fisker]

script with custom type should not formatted

playground

[ikatyang]

@StarpTech I personally agree that built-in sorting is great, but as a formatter we shouldn't affect the AST just like we won't sort object keys in js; they have the same meaning (in a sense) but their AST are different, and it's possible that someone relies on its order. It's not about the preference issue but for correctness, so I think having a plugin for it should be the right way to go.

[ikatyang]

@michaeljota Regarding https://github.com/prettier/prettier/issues/5098#issuecomment-422936906, could you provide an expected behavior? I'm not sure which part is wrong.

[michaeljota]

routerLink is being down casing. I think it's because you check if the element is an standard element, but maybe it would be useful to check if the attribute is standard itself.

[ikatyang]

@michaeljota I meant this indentation issue:

Using deploy from #5119:

Custom tags are not indented in the same line:
Repo

The casing issue is already added to the list:

non-HTML attributes should be considered case-sensitive

[michaeljota]

Oh! Sorry. I'm in the phone, and was pointed to the wrong one. If you notice the div with the very long class, the closing tag is placed next to it because there is yet space. But the custom element is not. And actually even with a space of separation, the closing tag will be indented below the opening tag, even if there is space, as currently in example.

[StarpTech]

@ikatyang this is what I said. In no language we provide a plugin system. Why should we make for html an exception? Use prettier for simple and consistent formatting and other tools for what ever you want. Let's focus on formatting.

What're the next plans? Do you accept the parse5 fork? The current implementation to support case-sensitive tags is more like a hack.

[ikatyang]

@StarpTech I meant a general interface not only for html, but it's still a concept and not sure if we should do so.

We'll switch to your fork in #5117 and #5119 for custom self-closing tags and HTML entities, but the case-sensitive part is still buggy in the fork so we're not going to enable that option until https://github.com/prettier/prettier/pull/5101#issuecomment-422031540 is fixed.

[thorn0]

👍 for switching to htmlparser2. It's much faster and optionally supports non-standard things like case sensitivity and self-closing tags. Unlike parse5, it doesn't parse tag soup exactly as browsers should do according to the spec, but I don't think this is really important. In fact for Prettier, this behavior of parse5 might be even undesirable because not all HTML(ish) files are supposed to be parsed by the browser, so I can easily see how it'll become a problem very quickly.

E.g. compare how this code

<table><tr></tr><my-component></my-component></table>

is parsed by htmlparser2 (astexplorer) and by parse5 (astexplorer).

Update: okay, I see this is fixed in @StarpTech 's fork. Still, what are the benefits of using the fork compared to htmlparser2?

[StarpTech]

@thorn0 I agree we should give both a try. All the issues you mentioned are already fixed in my fork of parse5.

[thorn0]

So what was your motivation to make the fork instead of simply using htmlparser2?

[ikatyang]

Sounds like htmlparser2 should be easier to use, and those pseudo nodes in parse5 is indeed undesired, I'll try it later.

[StarpTech]

@thorn0 for my implementation it was necessary because I build my formatter according to a specification hast and with the ecosystem rehype around it which rely on that parser.

Update: okay, I see this is fixed in @StarpTech 's fork. Still, what are the benefits of using the fork compared to htmlparser2?

• htmlparser2 does not mark self-closing tags in his AST
• Parse5 uses spec-compliant tokenizer under the hood but due to the fact that we want to support derivations like Angular, Vue this argument is discussable but even angular or vue are very close to HTML5. There are also many frameworks which are 100% HTML5 spec compliant e.g Svelte, Polymer, Riot.

[StarpTech]

I have no experience with the htmlparser2 but if it can cover all cases I would definitly go with this.

[thorn0]

@StarpTech Thanks for the clarification. Those are valid points.

[michaeljota]

Checking #5116, about self closing elements, I have to say in HTML5 the closing tag is optional and in several style guides is disencouraged. So maybe is OK to close those is XML kind of files, but not in valid HTML5 or HTML5 templates.

[ikatyang]

@michaeljota Can you share some links for those style guides? I'm curious why it's disencouraged. I think self-closing tags (<meta />) are better than void tags (<meta>) since you can clearly understand its structure without understanding if the tag is void.

[abdonrd]

Can we expect support for HTML in JavaScript template literals?

Very simple example of how to create a Web Component with LitElement (with lit-html under the hood):

import { LitElement, html } from '@polymer/lit-element';

class MyElement extends LitElement {
  static get properties() {
    return {
      mood: { type: String }
    };
  }

  constructor() {
    super();
    this.mood = 'happy';
  }

  render() {
    return html`
      <style>
        .mood { color: green; }
      </style>

      Web Components are <span class="mood">${this.mood}</span>!
    `;
  }
}

customElements.define('my-element', MyElement);

More complex examples (check render() functions):

• web-padawan/lit-components: /packages/button-base/lit-button-base.js
• Qiskit/qiskit.org: /src/components/app-shell.js

[web-padawan]

Related to the above comment: there is this plugin with partial implementation:
https://github.com/sgtpep/prettier-plugin-html-template-literals

[krumware]

+1000 for inclusion of template literals!

[StarpTech]

This thread gets bigger and bigger. Let's focus at first on HTML only.

[michaeljota]

It maybe better to discuss all the possible use cases here, before it gets merge. For instance, it the parser needs to be changed to handle components templates, it would be better do to it before this lands a release.

[michaeljota]

@ikatyang Well, I know there is not a good popular one about HTML, but I would add those I know.

• http://codeguide.co/#html-syntax (This is actually the one I get from)
• http://www.codestyle.co/Guidelines/html
• https://google.github.io/styleguide/htmlcssguide.html#Document_Type
• https://github.com/gocardless/html-style-guide

[michaeljota]

But maybe some frameworks need self-closing elements over void elements, but the top popular right now, Vue and Angular, parse valid HTML5, so they would be good with it. I exclude JSX because is not valid HTML5.

[ikatyang]

🤔 @michaeljota It seems all of them did not describe the reason behind it, they just said _"don't use it"_.

• http://codeguide.co/#html-syntax, http://www.codestyle.co/Guidelines/html:
  > Don't include a trailing slash in self-closing elements—the HTML5 spec says they're optional.
• https://google.github.io/styleguide/htmlcssguide.html:
  > Although fine with HTML, do not close void elements, i.e. write <br>, not <br />.
• https://github.com/gocardless/html-style-guide:
  > We don’t include a forward-slash on void elements

[StarpTech]

It maybe better to discuss all the possible use cases here, before it gets merge. For instance, it the parser needs to be changed to handle components templates, it would be better do to it before this lands a release.

Exactly, but please only use cases about formatting. JSX has nothing to do with formatting rules. If you want to handle JSX you have to extract it first and then format it so it doesn't belong to this thread.

But maybe some frameworks need self-closing elements over void elements, but the top popular right now, Vue and Angular, parse valid HTML5, so they would be good with it.

Don't start theoretically discussions. As soon as it's possible in Angular, Vue we have to support it.

I exclude JSX because is not valid HTML5.

Handling of case-sensitive attributes, tags are not valid HTML5 too but we need to support it.

[StarpTech]

@ikatyang thre reason is simple because it's optional and standardised. Less characters, less space, one rule -> conisistency.

[thorn0]

Less characters, less space ≠ more readability

[StarpTech]

@thorn0 I only answered his question it wasn't related to prettier.

[michaeljota]

@StarpTech Ok then. If you are only supporting what you know that you are supporting, then just valid HTML5. I know JSX is something else, I just mention it.

@ikatyang Yes, they does not seems to have a rationale, but the rationale that @StarpTech shows seems to be it.

[web-padawan]

One note regarding closing tag: please consider the fact that Custom Elements can not be self-closing, see w3c/webcomponents#624

[michaeljota]

Still, empty components are not the same as self-closing or void components. So, no every empty component should be formatted as a self-closed (or void) component, as @web-padawan said, custom webcomponents can not be either of those.

[VinSpee]

question about the following code:

<p 
  class="
    foo
    bar
    baz
  "
>
  Hello world!<BR> This is HTML5 Boilerplate.
</p>

I often write html this way when listing a tonne of properties and class (like when using tachyons or tailwind). Prettier does this to the formatting:

<p class="
    foo
    bar
    baz
  ">
  Hello world!<br>
  This is HTML5 Boilerplate.
</p>

I don't understand the logic behind this formatting - is this expected?

[michaeljota]

@VinSpee I think is trying to put all in one line (if you remove the new lines the intention is more clear). Seems that attributes values are not being formatted.

[ikatyang]

@StarpTech

@ikatyang the reason is simple because it's optional and standardised. Less characters, less space, one rule -> consistency.

@michaeljota

@ikatyang Yes, they does not seems to have a rationale, but the rationale that @StarpTech shows seems to be it.

Standardization also means complexity, we all know that <meta> is a void tag, but what if they introduce a new void tag that you've never seen before? You'll probably have to google it or just ignore it and assume it's a void tag, which does not look good to me. A slash at the end of the tag can prevent us from such ambiguity and also support XHTML, which looks like a win-win to me.

[ikatyang]

@web-padawan

One note regarding closing tag: please consider the fact that Custom Elements can not be self-closing, see w3c/webcomponents#624

We probably have to introduce an option for such compatibility issue, maybe --no-html-custom-self-closing.

[ikatyang]

@michaeljota

Still, empty components are not the same as self-closing or void components. So, no every empty component should be formatted as a self-closed (or void) component, as @web-padawan said, custom webcomponents can not be either of those.

Please note that this is a parsing issue not printing, we won't change empty tags (<X></X>) into self-closing (<X />) or void (<X>) tags, we only transform void tags into self-closing tags, which is valid.

[ikatyang]

@VinSpee

<p class="
    foo
    bar
    baz
  ">
  Hello world!<br>
  This is HTML5 Boilerplate.
</p>

I don't understand the logic behind this formatting - is this expected?

It's a bug, I've added it to the TODO list.

[michaeljota]

I think that is Prettier encounter any self closing or void component in a HTML file, should be formatted consistently. (My preference is void, but consistent is fine). I don't think it should have a list of void elements. Just format the input file.

[ikatyang]

We probably have to introduce an option for such compatibility issue, maybe --no-html-custom-self-closing.

Actually, do Angular/Vue recognize custom self-closing tags (i.e., do they treat empty tags <X></X> and self-closing <X /> differently)?

[michaeljota]

Angular does need the empty tag for custom elements, and it won't support void tags as they are not in the custom elements standard. I'll check on Vue later tomorrow, if no one has investigated.

[urbantrout]

I would love to see twig support! ❤️

[michaeljota]

As PHP is part of a plugin, maybe it would be better to extend that plugin to handle those use cases. Don't you think? @urbantrout

[urbantrout]

I didn't know that there was a PHP plugin. Cool!

Either your solution or a dedicated plugin-twig. I guess since prettier is only a tool for formatting it doesn't matter that Twig is based on PHP. But I have absolutely no clue about the architecture of prettier and its plugins.

[sorianog]

Is there a weighted prioritization list for the TODOs?

[evanfuture]

It seems like the biggest problem being faced here is that many frameworks use html as the file extension when they actually interpret it as something more hybrid than that.

NativeScript, for example, in its Angular flavor, cannot handle self-closing tags. But with Vue those are preferred where possible.

So, auto-conversion is probably something to be avoided, as helpful as it might be.

[michaeljota]

Looking for what @evanfuture said, seems that Vue can handle self closed custom components, but only in Vue single file components.

You can read more here:
https://vuejs.org/v2/style-guide/#Self-closing-components-strongly-recommended

That being said, I think this maybe an issue for the Vue parser, rather than the HTML parser. As currently Vue support is an on going work (#2097) I wouldn't see a problem if this does not support handling this edge cases.

So @ikatyang

| Framework | Void / Self-closed | Empty |
| -------------------------- | ------------------ | ----------------------------- |
| Angular | Just HTML standard | Require for custom components |
| Vue (Template) | Just HTML standard | Require for custom components |
| Vue (Single File Component) | Preferred | Discourage |

[ikatyang]

@urbantrout

I would love to see twig support! ❤️

I didn't know that there was a PHP plugin. Cool!

Either your solution or a dedicated plugin-twig. I guess since prettier is only a tool for formatting it doesn't matter that Twig is based on PHP. But I have absolutely no clue about the architecture of prettier and its plugins.

I think prettier/plugin-php should be more suitable for these php-related feature requests.

[ikatyang]

@sorianog

Is there a weighted prioritization list for the TODOs?

No, I just randomly pick one up and fix it.

[ikatyang]

@evanfuture

It seems like the biggest problem being faced here is that many frameworks use html as the file extension when they actually interpret it as something more hybrid than that.

NativeScript, for example, in its Angular flavor, cannot handle self-closing tags. But with Vue those are preferred where possible.

As I mentioned above https://github.com/prettier/prettier/issues/5098#issuecomment-423711753, if it's the case we may introduce an option for it.

So, auto-conversion is probably something to be avoided, as helpful as it might be.

We won't change empty tags into self-closing or void tags, see https://github.com/prettier/prettier/issues/5098#issuecomment-423711763.

[ikatyang]

@michaeljota

| Framework | Void / Self-closed | Empty |
| -------------------------- | ------------------ | ----------------------------- |
| Angular | Just HTML standard | Require for custom components |
| Vue (Template) | Just HTML standard | Require for custom components |
| Vue (Single File Component) | Preferred | Discourage |

Thanks! It seems we can disable the self-closing tag recognition in --parser html (.html) and enable it in --parser vue (.vue).

[michaeljota]

@ikatyang I just want to say thank you for all of this work. After all this time we finally will have HTML support and is thanks to you.

[michaeljota]

Playing with the #5134 notice a couple of things: repo

• Prettier is wrapping all the elements after finding an element that should be closed (either custom of standard)
  
  
  
  • Prettier should close an element right after the declaration.
  
  
• Whitespace in attribute values are not being reduced.
  
  
  
  • Maybe just respect new line characters?
  
  
• The multiline attribute is badly indented.
  
  
  
  • I don't know what is the expected case for that
  
  

[thorn0]

@michaeljota What do you call a component? Any non-standard tag? Why do you think Prettier should close them?

[michaeljota]

@thorn0 an element, sorry. I'll update the original comment.

Why do you think Prettier should close them?

As I understand from what @ikatyang said, Prettier would work in two modes

• For html it would disabled self-closing tag for custom elements. so if the input is <my-custom-element> Prettier should format it to <my-custom-element></my-custom-element>.

• For vue it would enable self-closing tag for custom elements. So if the input is <CustomComponent>, Prettier should format it to <CustomComponent />.

This is currently the desired behavior, as I can understand. The current behavior has some errors, including when the input are standard elements.

[ikatyang]

@michaeljota

@ikatyang I just want to say thank you for all of this work. After all this time we finally will have HTML support and is thanks to you.

Thanks. Also thanks to @evilebottnawi and @azz, I just continue their work.

[ikatyang]

@michaeljota

Playing with the #5134 notice a couple of things: repro

• Prettier is wrapping all the elements after finding an element that should be closed (either custom of standard)
  
  
  
  • Prettier should close an element right after the declaration.
  
  

As I understand from what @ikatyang said, Prettier would work in two modes

• For html it would disabled self-closing tag for custom elements. so if the input is <my-custom-element> Prettier should format it to <my-custom-element></my-custom-element>.

Disabling custom self-closing elements won't affect how we parse <my-custom-element>, <my-custom-element> is considered an open tag, every followed tags are considered its children if there's no close tag (</my-custom-element>).

Printing

<my-custom-element>something

as

<my-custom-element>something</my-custom-element>

is the desired output. We only transform void tags (e.g. <br>) into self-closing tags. Note that only these tags are considered void, that's why I think XHTML output is better.

The self-closing tag recognition only affects if <my-custom-element /> should be considered self-closing (enable) or open (disable).

• For vue it would enable self-closing tag for custom elements. So if the input is <CustomComponent>, Prettier should format it to <CustomComponent />.

Only if the input is an empty element (<CustomComponent></CustomComponent>).

• Whitespace in attribute values are not being reduced.
  
  
  
  • Maybe just respect new line characters?
  
  
• The multiline attribute is badly indented.
  
  
  
  • I don't know what is the expected case for that
  
  

If I remember correctly, the whitespaces in some attributes (e.g., title) are sensitive (i.e., not safe to collapse) but class is not the case. Does anyone know which attribute is safe to collapse whitespaces?

[michaeljota]

@ikatyang

Disabling custom self-closing elements won't affect how we parse , is considered an open tag, every followed tags are considered its children if there's no close tag ().

Printing

<my-custom-element>something

as

<my-custom-element>something</my-custom-element>

is the desired output.

I would understand that intention, but a common edge case that may be perceived as a misbehavior, what if I have some kind of autosave feature, and format on save, then I'm editing the html and create just the open element in a line, I would expect for the element closure to be created next to it, but this would actually create the closure element surrounding every element inside.

And this is not a _what if_ scenario. Is pretty common to have this settings enable (I don't have realtime autosave, but I do have the format on save)

[s-panferov]

Hi, I noticed that <![CDATA[ gets commented out after prettier.

[galki]

prettier is removing EOF newline only for html files. seems like a bug considering tslint eofline rule

[ikatyang]

@galki Could you share steps to reproduce?

[galki]

@ikatyang sure:

1. save the file (eof newline will be added by the _editor_)
2. execute prettier with the _extension_ - the eof newline is removed

---

editor: VSC
extension: Prettier - Code formatter
.prettierrc:

{
  "trailingComma": "es5",
  "singleQuote": true
}

html file: the content doesnt seem to matter (even just <div></div>)

[kachkaev]

@galki can you run prettier form the command line? can be an issue with the extension

[michaeljota]

Prettier doesn't support HTML yet. So it shouldn't be used to format those files.

[galki]

@kachkaev running prettier from the command line i get [error] No parser could be inferred for file: src\index.html which is similar to https://github.com/prettier/prettier-atom/issues/426

@michaeljota ok that makes sense, thanks

[michaeljota]

@galki that's because stable versions of Prettier does not have html support

[pauldraper]

The nice thing about parse5 is that is a very correct parser.

To preserve the case, use the fact that parse5 also gives the source locations of tags and attributes. I've looked into this before, and concluded it was possible.

[pauldraper]

Is there a bug for not wrapping text elements?

Repro

[michaeljota]

@pauldraper Seems to be fixed in latest of the #5168

Playground

Notice that Prettier are not using parse5 any longer.

[pauldraper]

On void tags:

I understand the desire for a more consistent syntax. Unfortunately HTML opted for its own bespoke SGML-ish syntax instead of XML.

Most style guides discourage self-closing void tags: Google, Drupal.

<input>
<input />

This may have to with reduced visual noise.

Or it may be related to the fact that until HTML5, self-closing tags were not permitted. In fact, HTML4 was SGML, where the syntax for a start tag can be <div/ and the ending tag is / (e.g. <div/my content/), meaning self-closing tag is <div// (SHORTTAG NETENABL IMMEDNET). Thus <input /> was actually <input>&gt;, except that everyone did HTML4 differently and the whole thing was a dumpster fire.

I don't anyone's goal here is supportting HTML4, but anyway, most style guides don't use self-closing tags.

[michaeljota]

@pauldraper There is a issue about that discussion #5246. You should comment there.

[ikatyang]

Opened #5259 to address these TODOs, feedbacks welcome.

[lipis]

Should we keep this TODO list updated as well?