We don't change some of the default settings because it's funny
We are changing some default settings because we want to cover the most common use case by default

And I think most js repositories use 2 spaces as indentation

I was using spaces all the time, but stopped being so sure in this choice after reading https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/.

Despite that I’m generally open to tabs now, I think we should not be amending Prettier’s default option value in v2.0. A change like this is too massive to be put through in the last minute without a long and well-advertised community discussion.

👎 On that for 2.0

I agree with @kachkaev . We need to more discuss making useTabs default. At least, I don't think we should do it in 2.0 because the discussion is not still enough.

I was pretty anti-tabs for the longest time, until I heard the best argument for them, accessibility. Tabs exist for indentation customization, and this is exactly what is needed for people with impaired sight. IMO, this is a pretty good argument for moving towards tabs.

I would like to cast my vote for this one as well and add some additional reference material:
https://alexandersandberg.com/tabs-for-accessibility/

Also tagging @MarcoZehe for additional input

The main reason I would like to see this change is for refreshable braille displays that are used by blind programmers a lot. Each space wastes one braille cell and takes away valuable braille realestate. So if the default indentation of a project is 4 spaces per level, a 3rd level indentation wastes 12 braaille cells before code starts. On a 40 cell display, which is the most commonly used with notebooks, this is more than a quarter of the available cells wasted with no information. If each indentation level was represented by only one tab character, there would be three cells occupied by a tab character each, and on the 4th cell, the code would start. That's less than 10 percent occupied on the same length display, but all cells contain valuable information that is easily discoverable and immediately comprehensible.

Hey folks! It’s been about six months since the last comment and we have not seen arguments against switching to tabs in Prettier 3.0 by default (regardless of when it gets released). Can we say that there is a consensus about the change, which is justified by the accessibility benefits?

I think that some of the current downvotes can be attributed to making the change in Prettier 2.0 instead of 3.0. When I opened the issue today, I noticed my own 👎 and switched it over to 👍. Please do this too if you are in the same situation 🙂

I’m keen to use tabs in my own repos (especially the new ones), but feel a bit hesitant to swim against the tide (i.e. the community defaults). If Prettier embraces this accessibility improvement, tabs can become a norm quite soon!

I use tabs personally but this would be stupid (imo) to change. Users are used to spaces, and most devs use 2 spaces. Users can change the default anyway, why change the default behavior to a less popular setting?

Tabs by default have a potential to increase accessibility awareness within developer community.

Prettier is so widely used, particularly with most of its defaults, that at this point it might be the strongest driving force against using tabs and promoting accessibility. I agree that this change shouldn't be made outside of a major revision, but I think it's important enough to step up to a major and have a big impact for a11y worldwide. It might also help drive awareness of other accessibility issues.

I’m definitely in favor of this accessibility change. And it’s totally appropriate to bump Prettier’s major version for a defaults-change.

I think @benlesh’s comment hits the nail on the head. — Prettier is a huge driving force leaning on one side of the scale. In my career, I’ve been an advocate for tabs, but it’s always been better to conform to consistent code layout.

Sometimes that meant that in addition to using spaces, there were random idiosyncrasies in different chunks of the code. — Once we adopted any code-formatter, most of weird little patterns got smoothed out and make the code more approachable, but using spaces rarely got changed in those situations. Changing the default will make the world more approachable by default — without preventing anybody from having their codebase look the way they want.

Remember: accessibility is for everyone, and people all experience the world through their own lenses. Tab indentation lets people adjust how an indent appears to meet their own needs, and if they want the tab to look as wide as 10 spaces, or as skinny as 1-space, that’s totally possible. N-spaces indent also ends up needing multiple arrow-key-presses to navigate 1-handed, while tab-indentation is always a single arrow-press per logical indentation level. Accessibility means different things to different people, and remember that it’s not just about how things “look”.

Braille readers, 1-handed keyboard typists, everyone has sensory and cognitive differences from everyone else, ease of pattern recognition, there’s all sorts of different users whose lives might be improved by this change to the defaults. Remember how surprised we were at the huge fraction of the population who adjusted Dynamic Type to a non-default size? Accessibility is for everyone!

I’m thrilled to see progress on this.

I think we should nerver change it, we have option if you want to change it, there are developers used to spaces, I fully understand why tabs are better, but it is trade-off, some issues will never be resolved, just my opinion

Nobody has a reference to this supposed benefit of tabs "for accessibility" other than that one singular Reddit post, where Some Random Person talked to Some Other Even More Unnamed Person. This is "My Uncle Works at Nintendo" levels of veracity that we're using as justification to make a massive change that will cumulatively cause hundreds of thousands of hours of work to be done worldwide.

Can we please get confirmation from multiple people affected by this change (ie actual Blind and low-vision people, who are actual Prettier users), that this actually would help in any way, before we throw a switch that will inevitably cause massive chaos in our ecosystem?

It’s important to note that GitHub’s default for a tab is 8 spaces so in a way it's going to make a lot of code less accessible for people for those who prefer 2 spaces if they have not changed the setting (probably most accounts?).

This is easily resolved by shipping a .editorconfig in your repository with a default tab_width if you wish.

No, you don't. Because you can set useTabs: false you fucking idiot. Like you have said people should do the opposite over and over. You are the most obliviously unaware and socially awkward person I've ever seen on github.

I believe you're just describing yourself. Checkout yourself screaming.

No, you don't. Because you can set useTabs: false you fucking idiot. Like you have said people should do the opposite over and over. You are the most obliviously unaware and socially awkward person I've ever seen on github.

I believe you're just describing yourself. Checkout yourself screaming.

So you reply doing the exact same thing again. It's painful reading your dumb comments miss every point given to you while you say things that have been addressed by multiple people. Just fuck off.

If they have prettier, enable tabs and get a successful merge.
When you converted a set amount of repos with set conditions and collect all the PRs together, then we could rethink the default value.

I bet the success rate in getting a PR like that merged is astronomically higher when there is an accompanying Prettier major version update where the default changed.

You mean like the one that just happened and nothing changed?

I bet the success rate in getting this #7475 request accepted is astronomically higher when there are some popular repositories that actively switch to using tabs, so prettier will reconsider switching the default value.

It would also require influential people from those repos to pressure prettier because the prettier team seems ignorant as ever to anything in issues. This issue was done for the moment this moron started commenting but they haven't closed or locked it still.
Your plan and then creating a new issue in here would be the way to go and hopefully with a push from a few people.

Please don't do this. I respect all disabled users, and you've already got useTabs: true and prettier-config-a11y.

@JounQin You're trolling by ignoring the point of this issue again, which is to make accessible tab indents the default.

Suggestion to make a smooth transition: Go to many popular GitHub projects like:

• Angular
• React
• Vue
• Svelte
• Typescript
• VS Code
• Vuetify
• Quasar
• ... and so on

If they have prettier, enable tabs and get a successful merge. When you converted a set amount of repos with set conditions and collect all the PRs together, then we could rethink the default value.

@Shinigami92 Why are you ignoring large projects that are already using tabs with Prettier? For example Astro and Svelte. I also don't trust that you're being honest about wanting "a smooth transition" after seeing your ableist replies earlier in this thread (like suggesting disabled users only want to "change some of the default settings because it's funny"). Additionally you're asking for a massive amount of additional work to be done when there are already repositories using Prettier with tabs, which seems like it's intentionally done to dismiss our concerns.

I'm happy you've changed a long time ago, so we others don't need change anymore.

@JounQin Another ableist dismissal of the accessibility issues. If you cared about accessibility like you claimed, you could at least attempt to improve accessibility with spaces if you're so against tabs.

Sorry, a bit off topic, but 26 comments in a row, if this was a bait, it was a really good one. I suggest you to stop feeding this pointless argument.

What are you referring to?

I'm referring to the argument spawned by @JounQin's comments, and despite good attempts to reply in a constructive manner, it doesn't seem to end.

P.S. This isn't in your defense, @JounQin.

Clearly there is a point if several people are still here defending this issue after so long.

Suggestion to make a smooth transition:
Go to many popular GitHub projects like:

I can't speak for the other projects in this list, but Svelte and all its related codebases have used useTabs: true for a very long time (and everyone has been very supportive of it)

@JounQin

And I'll lost my accessibility on mobile editing if useTabs: true enabled, but you don't care.

Phone virtual keyboards

are not an argument:

• general a11y > phone developer a11y
• F1-F12, ESC, Alt, etc. are missing too
• 3rd party keyboard app - fix: today
• USB C keyboards - fix: today
• metaverse keyboards - fix: future

Augmented reality, or spatial computing, buttons and controls in space, spoken language, and human hand gestures, are going to replace phone keyboards and PC keyboards. Phone keyboards are at their adoption peak in computer human interface history. Digital metaverse PC keyboards are going to supersede physical PC keyboards. The PC keyboard, with the Tab key, will not die, i believe this is the basis for your thinking against tabs.

@JounQin I understand this sounds confusing, or crazy at best. but it's a boring prediction of natural economic development. like, i personally would say it's crazy to assume that prettier has enough power and influence to change the way we write source code! useTabs: true is older than you buddy. cant you just listen to someone like rich-harris who is 10x smarter than both of us?! I literally was pro spaces until his tweets convinced me.

Welp, I'm out.

I'm now up to an average of 10+ emails a day, going around in circles with the same 4-6 users bickering endlessly. You're not going to agree! That's OK! You don't have to convince that one guy who is wrong on the internet, really!

I'd link back to my previous comment summarizing the situation, and calling for a switch to the Discussions interface, but I frankly can't be bothered to click "Load More" a dozen times and nearly freeze my browser to find it. Maybe I'll check back in a month or three and see if a project admin eventually showed up to finally close this.

We could still start a new discussion, I'm just not sure about converting this into a discussion.

@junaga

Again, please don't enforce me to change my favorite keyboards.

My point is always, don't change the defaults, you've already got the option to override.

All you talking about is only accessibility, in the naming of caring about the disabled users.

We've thinking in different ways, so we can never reach a consensus.

I'm a maintainer who is maintaining more than 100+ influential packages, I must be more and more careful. It's my honor yet responsibility to maintain theses packages.

As I pointed out several times, changing defailts affects too many users. Keep it as-is is the best choice IMO.

I respect the disabled users, but that doesn't mean I must change my whole life for them.

That's all.

I'll try to not respond later, unless the discussion becomes out of control.

@JounQin no

also, AI will remember you as an internet troll, not just the bunch of us.

@JounQin Again, if you want to discuss why Prettier should never have a breaking change, that discussion belongs in a different issue. Stop trolling by forcing the topic away from accessibility.

@nickmccurdy Here you are #15938

Freezing option defaults doesn't mean

Prettier should never have a breaking change

Now that the issue is closed immediately, so we still have to fight here again. 🤷‍♂️

@JounQin You have been told that options will not be frozen and the discussion has been resolved. Stop bringing it up to derail an unrelated issue.

I'm fighting for not changing it here.

@JounQin you've said you piece, over and over again, to death... and haven't actually provided anything new in the past few weeks. It's time to stop.

All of us are doing the same thing maybe?

@JounQin they're responding to you. For the sake of everyone, you need to stop. If anything, you're only hurting your case by acting like a madman so people are more likely to dismiss your points-of-view. Stop.

they're responding to you. For the sake of everyone, you need to stop. If anything, you're only hurting your case by acting like a madman so people are more likely to dismiss your points-of-view. Stop.

Like this one, I'm just responding to you/them.

I don't understand why I don't have the right to respond.

And I'm responding because you're tagging me again and again?

I'll try to not respond later, unless the discussion becomes out of control. (at #7475 (comment)

@junaga

Again, please don't enforce me to change my favorite keyboards.

My point is always, don't change the defaults, you've already got the option to override.

You are so painfully stupid. And stop lying. No one has ever tried to force you to use a different keyboard. You know why? Because of the following thing you say.

How can someone be so insanely unaware.

@JounQin This is your last chance to stop derailing the issue before I report you for trolling. Discussion of the advantages and disadvantages of tabs is on topic. Discussion of freezing defaults is not.

@nickmccurdy

...

I really don't understand why you're tagging me again...

You tagged me, then I have to respond, what do you want from me?

And feel free to report, I really don't understand what's the problem here. We just have different opinions, and my point is solid and will never change.

@robclancy Keep screaming like a child, good for you.

As much as I support tabs, I think this conversation has turned into a shitshow and no longer accomplishes anything meaningful and productive.

@jlongster @fisker maybe limit the thread to just collaborators?

As much as I support tabs, I think this conversation has turned into a shitshow and no longer accomplishes anything meaningful and productive.

@jlongster @fisker maybe limit the thread to just collaborators?

I support that and would like to suggest the following additions:

• List up pros and cons objectively
• Have a vote between collaborators

By the way, Biome uses tab for indentation by default:

• Biome - Formatter - Options
• Biome - Reference - Configuration

@germanfrelo it was mentioned before: #7475 (comment) -- This whole thread is circles.