Introduction
Prettier is the best formatter you could have right now, and it currently support a wide range of web programming languages, JavaScript, Typescript, Flow, JSX, JSON, CSS, SCSS, Less, GraphQL, Markdown, YAML and more recently it added support for template languages as well, HTML, Vue and Angular.
I was really exited by that feature, and actually help out testing and giving early feedback when the PR was open. It was cool to test something I wanted so much, and help to give it shape. Although, something was bugging me since the first time I try it: void elements was changed to self-closing elements.
Void elements vs self-closing elements issue.
This was largely discussed, and one of the main arguments the Prettier team had was the fact that self-closing elements was XML-compatible, but prettier itself doesn't support XML as is. Since I notice, I try to strongly express my opinion on this, after all, Prettier is an opinionated code formatter. I open an issue to give support to an option because I was against this behavior. Several guide styles about HTML recommend void elements to be expressed as is, because after all, the closing tag will be ignored by the browser, and it could lead to potentially annoying, but really unlikely, bugs.
And then I use it
However, since I was the one who push my team to use Prettier as a formatter, I went ahead and implement the upgrade. It was almost 5 months ago, with the version 1.15. In 5 months I've been working every day with templates, and components, and I have to say: I don't notice it.
I just use the formatter and have forgot about it. I don't remember if it is void, or self-closed, and so far I haven't found any noticeable misbehavior. The browser does actually ignore the closing tag, and that's all.
However, an automatic formatter had bring so many advantages to my work. I literally spend zero time moving the attributes up and down, trying them to fit one line, or giving them a new line when I want to. All the files have exact the same format, reading HTML have become so much easy.
And this is the win. It doesn't really matter this little details, when you have a consistent source base. You can add any number or properties, and Prettier will manage how to handle them.
Give it a chance
I've read people in the issue, complaining about the closing tag hurts their eyes, or because their team won't accept this as their style guide is giving the opposite advice, and this post is for you all: Do yourself a favor, and use Prettier as is right now. In a couple months you won't notice. I promise. You will gain so much, compromising for so little, it is worth.
This applies for the closing tag in a new line thing. Funny story, the JSX option was added by Facebook because they use it the other way Prettier was doing it in that moment.
The end
This is all. This was just a quick post about how I changed my opinion about Prettier formatting on HTML. I hope you like it. I promise I will writing a little bit more for now on.
PS: If you are curious, the issue I name here are: Prettier#5246 and Prettier#5377. But here are more issues regarding the current style of the HTML formatting.
Top comments (4)
This is simply not good enough as an argument. "After awhile, you'll forget about it... trust me." It's not HTML5 compliant and breaks W3C validation checks. That's the problem, and it's a big one. Prettier has millions of downloads a year which makes me think that Prettier is contributing to the ongoing problem of bad HTML markup and lack of compliance.
OMG! I appear on a W3C document about void elements validation. You make my day. Thanks!
PS: If you are using plain HTML in your project, go ahead, turn off Prettier, and use another tool to format your files. In my case, I still don't care, first and mostly because I don't use plain HTML, it has always been part of some framework or library, and because of that as long as Prettier prints the compatible format with that, I'll be ok. It's not like I don't care about standards, but more like I don't use standard HTML where I use Prettier.
Patting yourself on the back being mentioned by the W3C doesn't impress me. Who cares? The argument still stands. It kind of bewilders me how much developers want to get on this hill and die on it for their love affair over
/>.Because Prettier IS automated, there should be no reason why it can't adhere to the standard. If you want xhtml correctness with its opinionated formatting, great. You want html5 spec with its opinionated formatting, great. It doesn't offer that, and forces this. Maybe it's because it's hard for them to do at this stage, which suggests that Prettier wasn't written to adhere to standards in the first place. Luckily I was able to find a plugin that works appropriately for the HTML5 spec and passes W3C validation checks using Prettier. But, this should be a non-argument. Standards matters. The browser may hide badly formatted HTML but I don't find that an excuse to willingly write bad HTML5 because you just gotta have that
/>.In my case we're definitely using a framework but we require strict ADA compliance and on that list to ensure ADA compliance and optimal browser parsing, we're creating templates that then get migrated over into a complex framework. It must pass checks, it must build, it must adhere to the spec through validation, it should be as accessible as possible. If I use a plugin that breaks that process, I'm going to start eying why and I found this can of worms.
As I mentioned, you are free to use what you want.