[CSS] single line property formatting #5948
Comments
lydell
added
status:needs discussion
|
For me it is very unreadable. Also you need add new newlines before add new property, It is very uncomfortable. Also some properties can have very long values and it will be inconsistently: .static { position: static; }
.bg { background: very very very very very very very very very very very very very very very very many and long values; }To .static { position: static; }
.bg {
background: very very very very very very very very very very very very very very very very many and long values;
} |
|
I agree with @o-t-w, there is cases when we don't want three lines for small declarations. @evilebottnawi's point is a bit less relevant, for Stylelint rule Please be open minded. |
Because Prettier is an opinionated code formatter.
The issue is open :) |
|
"Because Prettier is an opinionated code formatter." |
How? It is break your code? It is just spaces/newlines |
|
@evilebottnawi Well if I didn't care how code looked I'd leave it as an unformatted mess rather than using Prettier in the first place. What I mean is that I dislike this formatting so much that I would rather go through the pain and tedium of manually formatting all my CSS rather than using Prettier 😖. Please don't make me do that! What is the benefit of not making this configurable? |
It is formatted well, just leave formatting for prettier, it is readable and looks good and i don't think we should change behavior.
|
|
On that matter, it seems clear that Prettier (or the team behind it) offers an opinion and if we don't agree, we don't use it at all for CSS. Period. I personally agree with almost everything with the Prettier's JavaScript opinions, I use and love it for that! But for CSS, those opinions are not compliant with the stylelint-config-standard and the default value of In the end, I understand that Prettier is opinionated by nature, but I think opinions are made to be discussed, not to be imposed by a small group of maintainers (even if their work is amazing, it's not the matter here, keep going), that's the beauty of open-source. Maybe a solution is to hold a vote for that kind of best practice to see what is the community's opinion. 🤔 I agree that options are maybe not the solution for Prettier, but the opinions have to represent the majority. Thanks for allowing this discussion 😄 |
|
Okey, we need investigate all popular styleguides, if somebody has time feel free to do it and put information here, personally i don't worries about spaces and newlines (within a reasonable), so we can revisit our output |
|
Using both single-line declaration blocks and multi-line declaration blocks within the same stylesheet is fairly common practice no? Typically if the declaration block only contains a single declaration, I might prefer to keep it on a single line. Apart from saving space, the real advantage is that it can help readability of declarations that follow a repeating/similar pattern. Example Input: Output: I don't think this is something that should be made configurable either, but I wonder if others think there is a place for single-line CSS declaration blocks in Prettier. Isn't this somewhat similar in nature to #4765? |
|
This is beneficial means of CSS(like) beautification. As a proof of concept try the compressed-css option of Pretty Diff to play around with a vaguely similar idea. This option has proven wildly popular with my users and would benefit Prettier users as well. |
|
Prettier allows JS oneliners like: var debug = ({ message, stack }) => console.error({ message, stack });
configure({ port: process.env.PORT }).catch(debug);Overall, condensing micro statements helps maintain code. Lets me see all necessary logic on one screen, keeping multiple terminals open. Allowing the same for CSS would be nice. |
|
Anyway you can use stylelint-prettier and setup stylelint rules to fit this in one line, it is not hard |
|
Prettier is much lighter, and the point is to be internally consistent and not customize. I've been setting up stylelint, but every project using Prettier can benefit from the single line CSS rule. Will try to implement once I'm done with my current backlog. |
|
What about this case: .mt7,
.mt-standard {
margin-top: 16rem;
}or .mt7, .mt-standard { margin-top: 16rem; } |
|
@evilebottnawi Selectors do belong each on own line IMO: .mt7,
.mt-standard { margin-top: 16rem; } |
|
Not sure it is good idea, it can potential hard to read |
|
Yep is there a way to fix this? Before: After |
|
+1 here, I develop website since 15 years, single line CSS formatting, in the era of ultra wide screen is far far more quick and easier that the 1 property per line formatting. Still don't understand how we can work with 3 visible selector (barely more) on a single screen. |
|
I've just installed Original: /* prettier-ignore-start */
.item1 {grid-area: header;}
.item2 {grid-area: menu;}
.item3 {grid-area: main;}
.item4 {grid-area: right;}
.item5 {grid-area: footer;}
/* prettier-ignore-end */After formatting: /* prettier-ignore-start */
.item1 {
grid-area: header;
}
.item2 {
grid-area: menu;
}
.item3 {
grid-area: main;
}
.item4 {
grid-area: right;
}
.item5 {
grid-area: footer;
}
/* prettier-ignore-end */I really hoped using the |
|
I would give anything to have the option to allow for a single line css declaration. 😄 |
|
How about format it like |
|
I would love to write a PR that changed it so that Prettier did Fisker's formatting. Let me know if there is interest? |
Suggestion for implementationInline single-attribute-declarations: when they're within the print-width. Remove semicolons: when Leave selectors as is Git diffs:
|
No, it is create more problems than fix it, try to implement it, as I written above, we can't solve this issues separately.
No options, pelase read option philosophy
What should developers who don't like this style should do? I want to close the discussion on this issue because it turned into a controversy. You constantly accuse me of the non-constructiveness of the conversation, but you do it yourself, I show you examples and problems, you just keep arguing.
Didn't I do that? Please read my posts above, I provide you all the problems, and potential future problems, like selectors, multiple properties, nested selectors, nested media query (less/scss) and many of other. I even suggested that you try to implement this to see all the problem places. @robert-j-webb This is true, but only when you have no alternative, here we have alternative without additional problems, used already in many projects. |
|
Also you already can achieve this using |
Hence, the temporary option for early adopters.
Does this principle or metric apply to developers who dislike the existing handling of single declarations? Shouldn't we weigh the pros and cons of both sides and not just the status quo?
Sorry, no, and I explained why, when I pointed out why the popularity of TailwindCSS is fallacious and irrelevant. If you disagree, feel free to explain why.
The controversy was there from the start, I merely verbalized what others had expressed through countless confused smileys. Apologies if I come off aggressive or personal. This is not my intention and despite me sounding like a square, I have nothing but love and appreciation for the you and the Prettier team. We're all here because we care. ❤ |
|
@evilebottnawi could you provide an example of how to achieve inline declarations with |
We don't have RFC for this, one temporary option mean every developers want to have owns temporary options
We cannot meet the needs of everyone, some are willing write JS like: {
color: 'red',
otherValue: 'blue'
}Why we respect it? We have chosen the most popular style and contains the least number of problems
Open source code of other popular CSS frameworks, if you still not believe me
I understand this perfectly, but understand us, we cannot support all possible styles, this will turn the project into a garbage and create more problems. Our default style doesn't even have a big problem with readability. I have already said above and more than once that both styles are good, but the choice was made.
Sorry wrong project, you can use https://github.com/hugomrdias/prettier-stylelint, example of setup you can find in the README |
I do believe you, but prevalence does not equal preference. This is just an iteration of the same false-cause, bandwagon, black-or-white fallacy. It has already been refuted in #5948 (comment). If you disagree with the rebuttal, feel free to explain why. If we upvote inlined-single-attribute-declarations (ISAD), our votes are discarded as non-indicative because we represent a group biased towards ISAD, Yet if we use Prettier and are stuck without ISAD, you argue that projects are indicative that we don't want ISAD. I don't need to point out the irony. I honestly believe most people would prefer single line declarations for single attributes and the only reason this isn't reflected in public projects is because the most popular formatter to this date doesn't provide the option. In other words, You can't measure the popularity of A vs B, while only providing option A. 🙂 |
At one time we held a vote A vs B (twitter/github) and A won. I do not want to continue debate about popularity. Unfortunately, there is no place for such formatting in the prettier. Why?
|
You continue to use it as an argument, but you won't acknowledge or even debate the fallacies.
It can be done without new options
A) You don't have to
Are these questions aimed at my proposal or a strawman? I already suggested that selectors were left as is.
That's a supposition based on yet another false-cause, bandwagon, appeal to popularity.
How would this work? What are the drawbacks?
This is a slippery-slope. You don't have to consider all possible preferences to consider one.
This statement blatantly ignores every testament and vote in this thread. I asked the question on our Routify Discord and while the sample is small it aligns with votes given in this thread. @evilebottnawi thanks for your replies. For me this wasn't about getting single line declarations at any cost, but to give the original proposal a fair trial, weighing the pros and cons objectively and coming up with the best solution for all. At this point, I don't think that will happen. Good luck with it. 👍 |
Collect metrics from github, I spent enough time in developers CSS pipeline (postcss), CSS in webpack, stylelint and other popular tools. You refuse to believe me, I suggest you collect metrics, but instead you keep arguing.
How?
These are the basic principles for formatters
I repeat once again, try to implement it to see the whole range of problems, I offer you actions, you offer words, we cannot talk about it. I tried it several times and apart from a lot of problems I got nothing. I don't argue here just to argue, I show you problems. This problem cannot be resolved without solutions to these problems. You would have been convinced of this long ago if you had listened to me and saw it yourself.
Please stop being toxic, and start the discussion constructively, you just ignore my words that we collected metrics, did polls and discussed it, use the search.
Please read the readme. It is not hard.
Where there are two, there will be three, and then there will be four and more. It was thanks to the prettier that I changed my style in due time, not because I want it, but because it will be for everyone.
And I asked facebook and they prefer the second one, who is right?
I don't understand you:
I have repeated many times that a universal formatter is difficult, and you need to start using it with a change of mind. We need to sacrifice our own preferences in favor of general preferences. It's not easy. But this is what will allow us in the future not to have problems with formatting, to forget problems about newlines, spaces, commas/etc and enjoy writing code. |
|
Just my two cents, but like @robert-j-webb, my agency has found Prettier to make JS universally better and more readable. When it comes to CSS though, we have had to actually just disable it for all CSS languages because it almost universally makes it less readable than the un-prettified CSS. It's just not better. I love the idea of an opinionated formatter, but that comes with the price of making sure the opinions are the right ones. In this case, it looks like there's at least a discussion to be had. I don't really understand why there seems to be such backlash against entertaining a possible improvement? |
Please stop say -
Where is no negative, I gave constructive arguments in favor of complexity and another new problems with supporting one-line declarations. It is thanks to such comments that it becomes difficult to evaluate all the work done, so that you would answer me if I said that your work in "custom place in your source code of project" is terrible, without giving any constructive examples? I don't think you would like it |
|
@evilebottnawi If not evident by my last post, I have resigned from this discussion because we have major disagreements about what constitutes concepts such as metrics and fallacies - or at least whether fallacies are valid points. So let me round it off with saying:
You may have good points, but as a person with autism, I have to trim the proverbial fat first in order to only focus on the valid points. Your argumentative style is very different from mine and I probably should have realized sooner that we wouldn't be able to reach a common ground or perspective for our discussion. I'm sure we both gave it our best and I welcome you to visit our Routify Discord for a friendlier chat, if you're ever so inclined. It's public. 🙂❤ |
It is already popularity (github and twitter polls) + readability (both styles is good) + maintenance cost (new problems will be cost time for developers) and etc. I write about it above.
The converse is also false here. Prevalence can equal popularity or preference.
It was discussed with many developers a long time ago. Please use
From me:
You make statements like this with your own desire.
And others.
I suggested that you try to implement this and see the problems, but you keep ignoring me. You refuse to believe me and at the same time refuse to try and see problems your own eyes. This is a vicious circle from which there will never be a way out. Perhaps you expect the other person to do this for you. If you want to have a constructive dialogue, stop ignoring me. Note, I have not closed the issue and did not say that this will not be implemented, I just pointed out potential problems and demonstrated them. I showed you how to achieve what you want. I show the cases that we will have to solve together, because if we do not solve them, we will make the code even uglier, is that what we want? I said why this particular style was chosen. And many, many more. |
|
Everybody talk about lot of things except the original issue. I red the prettier philosophy and understand that the purpose of it is to give one master formatting to rule them all, so, with fewest option possible. Overall, I think it's a good approach. But for CSS, I also think it make sense to propose these 2 options. Only a simple choice : "Expanded" or "Compact". Expanded would be like this, and compact like that without any options to manage spaces between properties etc...., let's be opiniated about that small variations. But to me, CSS needs that 2 different way of writing that goes beyond just formatting. |
|
Prettier just did this to my css files and I don't know who can read this comfortably but I can't: html,
body,
div,
span,
object,
iframe,
h1,
h2,
h3,
h4,
h5,
h6,
p,
blockquote,
pre,
abbr,
address,
cite,
code,
del,
dfn,
em,
img,
ins,
kbd,
q,
samp,
small,
strong,
sub,
sup,
var,
b,
i,
dl,
dt,
dd,
ol,
ul,
li,
fieldset,
form,
label,
legend,
table,
caption,
tbody,
tfoot,
thead,
tr,
th,
td,
article,
aside,
canvas,
details,
figcaption,
figure,
footer,
header,
hgroup,
menu,
nav,
section,
summary,
time,
mark,
audio,
video {
margin: 0;
padding: 0;
border: 0;
outline: 0;
font-size: 100%;
vertical-align: baseline;
background: transparent;
}
article,
aside,
details,
figcaption,
figure,
footer,
header,
hgroup,
menu,
nav,
section {
display: block;
} |
|
@cseas I believe this issue only concerns formatting CSS declarations on a single line if they have a single property and would still fit within the print width. The formatting you and @FrederickEngelhardt appear to have a problem with is probably better described as single line selector formatting. Take a look at #1962 to see why Prettier formats selectors like this. I've been using Prettier for a while now and I've changed my stance on multi-line formatting. I actually find it easier to read and scan through a list of selectors like that and I appreciate the consistency of multi-line single property formatting. I think this problem comes up because we all have our own opinions on how code should look, format it the way we want ourselves, and then start using Prettier and react negatively when it changes things. Using Prettier in this way is backwards, but it's probably how we all start using it. Eventually you realise that Prettier takes care of those two things for you - you don't need to have an opinion on how CSS should look (or adopt/enforce formatting preferences from/onto other developers), and you don't have to format anything yourself. Just write a mess of code and Prettier will take care of it for you. But I completely understand the initial shock of seeing your code spread onto hundreds of extra lines. 😅 |
|
@cseas and @FrederickEngelhardt , check this link: https://prettier.io/docs/en/ignore.html , you can ignore that part of selectors or something else in css by writing : /* prettier-ignore */ , before, like this: /* prettier-ignore */ |
While I appreciate the ideal here. In this case it's more like: Write a nicely formatted piece of CSS and prettier will make it a much less readable and maintainable (though consistent) piece of CSS. |
But that's subjective isn't it? I felt exactly the same way before. I'd write my nicely formatted CSS, making sure my code was readable (for me), maintainable (by me), and consistent (with my own standards). Then I tried Prettier and watched as it mangled my code. It doesn't feel good, I get it. If you think it's objectively worse, then you could turn it off for CSS and maybe try another formatter? I'm not sure it makes sense to format all your CSS manually and then use a formatter too, unless you're just looking for it to catch a few small formatting mistakes for you? Imagine you were learning a new language and you had zero opinions on how the code should be formatted. You'd hit save and the formatter, maybe Prettier, would take care of it for you. You might blindly trust that the formatter was doing its best and the dev/s who coded it knew what they were doing. Or maybe you'd compare it to the formatting of other languages you have experience with and think it could be improved. If those improvements would make the formatter objectively better then they should totally be implemented. But if they're subjective like this CSS single line property issue right here, then you'll never satisfy everyone. Making it an option means spending time thinking about it, and essentially results in you inflicting your opinions onto others, or others inflicting their opinions onto you. It's also against the Prettier Philosophy. I don't personally feel like I am in any position to make informed decisions on how others should be formatting code (even if it's my preference), so I'm happy to trust Prettier and its contributors who spend their time on these issues and think about these things for us. But I get your frustration. I thought this way was better, then I changed my mind, but honestly I don't mind either. So at least if this was ever implemented, we would both be happy! 😁 |
Yes, it is. But just because it's subjective doesn't mean there's no value in trying to choose the better of two behaviors (most people prefer chocolate ice cream over garlic ice cream). After all, prettier is literally that, choosing a particular opinion about how code should be formatted. Just because prettier chose to format CSS in particular ways in the past doesn't mean every choice was optimal. It seems like the CSS formatting of prettier could use some tweaking (as evidenced by all the people here chiming in over the years). There are plenty of arguments for why single-line properties are a good idea, but the arguments against are mostly hand-wavy (it'll be hard) or slippery slope (allowing this change will force us to allow more changes). Regarding adding it as an option, that seems like a battle the community will lose as the team behind prettier is staunchly anti-option, so I vote for just making single-line-property declarations the way. I'm suspicious that their "options == more decisions and more things to fight about" stance is ignoring the reality that no options often means people make decisions and fight about adopting prettier at all. |
Which I didn't disagree with... that's literally what we are all doing here on this issue. However your original comment didn't seem to add anything new, it just felt like you were venting your frustration. That's fine, it shows you're in support of the change, but things like
are unlikely to convince anyone that single line property formatting should be implemented, and presenting it as fact is just misinformation. I was trying to help you understand why my stance had changed, and what i meant by
which you seemed to have an issue with.
That's great, but there's also people who would vote against it. It doesn't solve the issue unfortunately. The majority of people looking at this issue want single line property formatting. They see a problem that needs fixing and expressing their thoughts here is the best way to go about it.
Then it might be a good idea to collect these arguments and contrast them in an unbiased fashion (there are valid reasons against), to make a stronger argument for why this should be implemented. |
|
Thanks for taking the time to reply thoughtfully.
You're right my comment didn't add much and was meant as more of a rebuttal to your similarly general statement that prettier takes a mess and makes it better.
"you voted, but that doesn't solve anything, you should express your thoughts" I believe I did express my thoughts and my vote.
True, that would be the most likely way to get what I'm after, but I don't want to spend the time. I don't care quite enough about css formatting and have very little faith that the maintainers would be convinced by arguments. I already feel guilty about taking up your time and the time of others in this thread. Sorry! |
|
You're right, my statement was fairly general, but it was supported a bit by the preceding statements I'd made. It was an attempt to help others see formatters from a different angle and hopefully ease the pain, which I know I felt when I started using Prettier. Haha I have nothing against your vote or your thoughts! That's the best way this issue will get resolved. I meant that implementing single line property formatting right now doesn't really solve the issue, and that the comments here are probably a little one-sided because most of us are looking at this issue for the same reason.
That's entirely understandable! And there's no need to feel guilty at all, it was an interesting exchange, and your comments generated a bunch of reactions in favor for this issue. So thanks! 😊 |
|
Two years after, and no agreement? So sad. 😄 |
However, I've been a developer for over 15 years, and I can confirm that this is the best way to write css. |
|
Why not just add it as an option and let people have one-line rules who want it? |
|
another proof that an opinionated garbage is only as good as the opinion is shared |
and others
I am re-raising this issue.
I am currently working on a CSS utility library. Almost all the classes have a single CSS property, yet they are all formatted by Prettier to take up multiple lines. For a single property, this is a massive waste of space and far less readable.
e.g. here is some code from the relatively popular [Tachyons library](e.g.: https://github.com/tachyons-css/tachyons/blob/master/css/tachyons.css):
Here's is what it looks like after using Prettier:
It is clear to me which one is preferable! Please reconsider.
The text was updated successfully, but these errors were encountered: