-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to prefer void tags over self closing tags. #5246
Comments
I don't think we need option. I think we should print this as in source code, i.e. if you have Why:
|
I think it's good that Prettier takes a stance here since this is something that programmers easily could have unnecessary debates over. |
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. |
@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.
You would need to remember it any way. I don't see why you would stop doing it. |
You're mistaken, see #5098 (comment) |
|
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:
|
Using the option
<input
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="1"
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="2"
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="3"
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="4"
longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong="5"
><span>something</span>
<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. |
@michaeljota FYI, I tried it on parse5 and it takes the first one as well. |
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. |
Missing duplicate attribute issue is fixed in a3ec5a6. |
Comment from #5098 (comment) 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. (I am currently looking for anyone that is willing to loan me their time machine.) Many style guides discourage self-closing void tags: Google, jQuery, Drupal, codeguide.co. (Counterexample: W3Schools, WordPress) <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 even permitted. Back then it was SGML, where the syntax for a start tag can be I don't anyone's goal here is supportting HTML4, but anyway, most style guides don't use self-closing tags.
I think that as it stands the HTML parser will make a subpar XML formatter. If I am writing XML (including XHTML), I would expect that
becomes
|
From the w3 html5 syntax document here
So, there self-closing elements, and void elements are two separate things. I really would like for prettier to have this option, but I don't have any idea how to do it properly, but to have a know list of the void elements, but also for valid foreign elements that can be self-closing. Update: I ended in the the w3 document from the reasoning from Drupal to drop the self-closing elements. |
Yes, "self-closing" elements technically are only foreign elements (i.e. elements in certain XML namespaces). Void elements (area, base, br, col, embed, hr, img, input, link, meta, param, source, track, wbr) are HTML elements without closing tags. Since these affect parsing, they are defined as a part of the syntax section. HTML5.2, 8.1.2 "Self-closing void elements" colloquially refers to the practice, first permitted in HTML5, of writing void elements as if they were self-closing foreign elements.
Any HTML5 parser (e.g. parse5) already has to know the list of self-closing elements, and properly detect foreign elements. Nothing new here. There's no question of feasibility, only a question of desire of whether prettier should support the Google, jQuery, Drupal, etc. style guides. |
Prettier makes the very notion of style guide obsolete. Why care about this relic of the passing era of manual formatting? |
As I said, there is enough people using void elements, enough companies using void elements, to at least make an option for it. I'm sorry, I get why you are against options, but this is a new parser, and a lot of people, and big companies, are using void elements, because they are void elements. I don't see how this is different from the basic options to format Javascript. Those opinions where already there. As I see it, is the same thing here. |
Read this issue tracker to learn the difference. There happened a long battle over each of those options. They have been added as a result of strong pressure from the community, not because of speculative attempts to foresee what people will want. So let's cross this bridge if we come to it. |
I see. Well, I guess I just wait until you get real feedback after this gets implemented. Thank you. |
Imo this is exactly the kind of discussion I do not want to have with coworkers and Prettier should just do what it does right now without an option. We should optimize for modern code, not old syntax, and there are arguments in favor of self-closing regarding readability and compatibility with XML. Now just let people write however they want and Prettier format it to self-closing on save, with no time wasted discussing it. |
I just ran the updated prettier on my html files and it converted my HTML5 |
@snebjorn |
Compatibilty with an entirely different language is an argument!? In that case, consider that self-closing tags are incompatible with the last major version of HTML, HTML4. |
@snebjorn If you want to at least be able to chose, up vote the main issue. With enough votes I'm sure this will eventually land. 👍 |
@lrusso Prettier won't add more options, see https://prettier.io/docs/en/option-philosophy. |
💯 Another potential solution I've been thinking about: |
The reason behind the twisting1 is implementation simplicity:
Footnotes
|
Hello everyone, a developer just wrote a plugin that takes cares of this requirement that the Prettier team doesn't want to implement: Before I was using patch-package for adding this required code, but the plugin is much better and cleaner 👍 I hope it can be useful for someone else 👍 |
This Meta vs Google culture war is making me go mad. Can the prettier team please stop goofing around? JSX != HTML && XHTML != HTMLJake said it best. JSX is not HTML. XHTML is not HTML. HTML is HTML. github:whatwg/html is HTML. In HTML the |
It feels like this issue has become a sort of hill the devs are going to die on. Regardless of all the comments, the evidence the Prettier is creating code the violates standards (from standards authors themselves), and possible resolutions, they simply will not respond, engage or otherwise even countenance a discussion. |
one of the maintainers did actually try picking this up last time the issue made its rounds, but seems they never got around to it (sosukesuzuki). fisker also tried to do this in a PR long ago, but was rejected at the time by the rest of the maintainers iirc. opinions have likely changed since then, though (since the ecosystem has too). a while back, i created another issue for tracking the specific proposed fix (as opposed to this issue which is more of a discussion now, and no longer titled correctly since we don't want an option). we can't really expect a maintainer to understand this thread anymore, it is too long (or to keep track of it). so you are still right in a way, it is unlikely to go anywhere without one of the maintainers dedicating a large chunk of time to it. |
Are there other examples where Prettier explicitly goes against the spec of the language that it is formatting? I would have thought that following the language spec would be a primary requirement for Prettier, so I am kinda dumbfounded by this issue not being welcomed. |
Instead of proposing an option, why not simply change the function to comply with the standard? |
Already tracked elsewhere in a separate issue fyi. This issue is specifically for adding an option and seems unlikely to result in anything given how old it is now. I forget the issue number but changing the behaviour has been raised there instead |
The Hate will flow in, but it will take many more months, before Prettier is "defeated". this is an forever-issue already, the maintainers dont care, and they think they are above the law - above the ecosystem. Just switch to Biome today, it's not worth to keep track of their "progress". |
Seeing as this is the issue specifically requesting a new configuration option, I'm going to restate my comment from the other issue: Fixing this from plugin-land is really difficult (I've attempted it and struggled with nasty edge cases because the plugin APIs don't really support doing anything like this). So I am asking once again: Is the Prettier team open to a PR that would enable this alternative formatting behind a config option? Changing the behavior outright is a hugely disruptive breaking change, so it seems like an opt-in approach is warranted. I'm happy to try implementing it.
It's tracked in #15336 |
sorry, but what do you think prettier is? POSIX? HTTP? I honestly don't see how a couple more options could hurt, just compare the amount to eslint options. ryan once said that things that are so perfect they "feel cute" are always regretted down the road. |
In the "Option Philosophy" page, Prettier lists a few examples of options that are "easier to motivate":
They also mention this caveat at the very end:
It seems to me that this issue is precisely a compatibility issue and not a request for a formatting-related preference:
Note An argument can be made that there should be two separate issues on the topic of self-closing syntax: one issue for how to format void HTML tags, and a separate issue for how to format non-void HTML tags. If that's desirable, I'll happily open new issues to keep those conversations isolated. I would love to hear from a Prettier maintainer whether they agree that this rises to the level of a compatibility issue that warrants an option. Or — if this is something that Prettier should change without adding an option, I'm happy to continue the discussion in #15336. And please, let's keep this conversation well-reasoned and civil. No matter how old this issue is, or how frustrated you are about whatever, no amount of fist-shaking is going to help make progress. This issue is still Open, after all 😄 |
Well said @awmottaz. The reason why I'd like this option is that every time prettier runs, it introduces validation errors into my pages that are flagged by other tools. It's really annoying to have to choose between well formatted code and code that actually validates. The only "viable" workaround is to write a mini script that runs after prettier and fixes the syntactic damage it introduces so that pages validate properly. ...or to switch to Biome once that actually supports CSS. |
For new posters: This is from 2018 with no response from the maintainers. Forget it. I posted https://beautifier.io/ here before with some flags to get it quite close to prettier. It's not some 'opinionated' bullshit, and does JS/CSS/HTML. Not a kewl new kid on the block, but it works well. There are many others, too. It's funny to see this thread being active still, but maybe it's time to unsubscribe. |
I've been subscribed to this thread for over 4 years, just for entertainment, and it's still worth it. |
There are bugs like this on every project out there. "Small" stuff that is a complete deal breaker for a number of users. It makes sense on corporate projects as everyone is trying to push some new blockbuster feature to get a promotion. But it's harder to understand on open source projects. Sometimes "papercuts" bleed a lot more than expected. |
What were the flag combinations that you suggested? I don't see them above.
What other options do you recommend? @junaga has suggested Biome but as far as I can tell, it doesn't support CSS yet. |
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:
Output:
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:
# Options: --prefer-void-tags=true
The text was updated successfully, but these errors were encountered: