Add an option to prefer void tags over self closing tags.

[michaeljota]

Update:

I have change my opinion on this, and I don't think I require this any more. If this is ever implemented I would probably use it, but I really don't mind this behavior at all. If you want to read more, I wrote a post in dev.to

---

Original post:

Prettier 1.14.3
Playground link

# Options (if any):

Input:

<input type="button">

Output:

<input type="button" />

Expected behavior:
I would like an option to prefer void element tags over the current implementation of self-closing element tags. I understand why is this the default behavior, as this is xml compatible, but several style guides suggest the usage of void tags as they are valid HTML5 tags. As I understand in the option philosophy, if there is enough usage from developers there is a justification to add the option.

Style Guides:

• https://google.github.io/styleguide/htmlcssguide.html#Document_Type
• http://codeguide.co/#html-syntax
• http://www.codestyle.co/Guidelines/html
• https://github.com/gocardless/html-style-guide

# Options:
--prefer-void-tags=true

<input type="button">

[alexander-akait]

I don't think we need option. I think we should print this as in source code, i.e. if you have <input type="button" /> print this as is.

Why:

1. Compatibility with XHTML.
2. It is out of scope prettier, here should be used linter to avoid HTML errors.

[lydell]

I think it's good that Prettier takes a stance here since this is something that programmers easily could have unnecessary debates over.

[thorn0]

It's about readability, not XML/XHTML. The moment you see a self-closing tag, you understand it's void. Otherwise you have to remember which tags are void. I'd prefer Prettier to remember this for me.

[michaeljota]

@evilebottnawi As you can see in the link, that's not what is currently happening.

@thorn0 The current reason is not about readability, but compatibility with XML. Still, as I pointed in the issue, there are many style guide that suggest the usage of void element tags, even Google Style Guide suggest it.

Otherwise you have to remember which tags are void.

You would need to remember it any way. I don't see why you would stop doing it.

[thorn0]

The current reason is not about readability, but compatibility with XML.

You're mistaken, see #5098 (comment)

[michaeljota]

@thorn0

A slash at the end of the tag can prevent us from such ambiguity and also support XHTML.

[ikatyang]

Both readability (no ambiguity) and XHTML compatibility are the reason why I think self-closing is better than void.

And it'd be worse if it comes to sensitive whitespace, considering there's a void element with a super long opening tag:

• prefer void over self-closing

  <input
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
  ><span>something</span>

• prefer self-closing over void

  <input
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
    longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong
  /><span>something</span>

[michaeljota]

Using the option --html-whitespace-sensitivity=ignore, the output is legible regardless if is void or self-closed.

• Input

<input
  longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="1"
  longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="2"
  longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="3"
  longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="4"
  longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="5"
><span>something</span>

• Output: (Assuming void)

<input
  longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="1"
>
<span>something</span>

BTW: As you can see, attributes with the same name are being ignored after the first one. I don't remember what's the behavior for all the browsers, but I think that at least Chrome actually just take the last one.

Playground link

[ikatyang]

@michaeljota FYI, I tried it on parse5 and it takes the first one as well.

[michaeljota]

But, should it? Anyway, I don't think this is a big issue you can't actually have multiple attributes with the same name. I don't think it matters if it ignores the others or take the last.

[ikatyang]

Missing duplicate attribute issue is fixed in a3ec5a6.