Change useTabs to true by default

[ExE-Boss]

Since we’re changing the defaults for several options in 2.0, I’ve decided to request that we do so for useTabs as well.

Tabs have several advantages over spaces:

• Always 1 byte per indentation level, regardless of tabstop width.
• Indent size is customisable (those of us who prefer 4 characters can use a tabstop width of 4, and those who prefer 2 characters can use a tabstop width of 2)
  • https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/
  • https://alexandersandberg.com/tabs-for-accessibility/

---

See also: #6888

[Shinigami92]

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

[kachkaev]

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.

[alexander-akait]

👎 On that for 2.0

[sosukesuzuki]

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.

[milesj]

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.

[schalkneethling]

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

[MarcoZehe]

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.

[kachkaev]

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!

[justingolden21]

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?

[skuridin]

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

[benlesh]

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.

[fbartho]

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.

[alexander-akait]

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

[anaisbetts]

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?

[Cherry]

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.

[hdodov]

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?

[simpliston]

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

[germanfrelo]

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

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

[dsherret]

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

[mvargeson]

Could somebody from the Prettier team document the rationale behind the current default? I know this is only tangentially related to the topic but it may be beneficial given how many circles have been run on this issue. Thanks!

[robclancy]

Could somebody from the Prettier team document the rationale behind the current default? I know this is only tangentially related to the topic but it may be beneficial given how many circles have been run on this issue. Thanks!

They have taken a non stance on it in their "opinionated" formatter, which is pretty ironic.

Hopefully biome keeps going well, faster anyway.

[junaga]

here we go again 😭

[mnemnion]

Indentation is:

• Any whitespace at the beginning of a line
• Representing a consistent indentation
• Canonically, is one tab, or several spaces

When it's tabs, it's possible to set the number of visual spaces indentation takes.

When it's spaces: it's possible to set the number of visual spaces indentation takes.

There's nothing magical about 0x09 which means it's variable width, when N*0x20 can't possibly be variable width. It's a computer. These are all numbers living inside a computer.

If braille reading machines need indentation to be one space, they can implement that.

If editors need indentation to be variable width, they can implement that.

The accessibility argument is completely fake. Go file bugs against projects where it matters: editors. It's a bit of code, it gets written once, and the problem is completely solved forever.

Of course, if your actual goal is to bully people about your preference for tabs over spaces, and use the visually impaired as your baseball bat, then... y'know whatever gets you through the day.

[ashleemboyer]

A downside of this extremely long thread is that core arguments, which include several explanations and resources backing up the accessibility side of this issue, are hidden and people aren't reading them. 😞

---

@mnemnion your comment has answers throughout the thread, but I want to respond to two things from the last part.

Of course, if your actual goal is to bully people about your preference for tabs over spaces, and use the visually impaired as your baseball bat, then... y'know whatever gets you through the day.

"preference for tabs over spaces": Accessibility accommodations aren't a matter of preference. "Preferences" implies there is a true and correct default that should be adhered to. They're helpful but optional. Accommodations are always necessities for disabled people and shouldn't be implied as optional conveniences.

"use the visually impaired as your baseball bat": The matter of using TAB or SPACE characters for indentation doesn't only concern braille display users or people with vision disabilities. Because indentation affects readability — just like single or double quotes, semicolons, trailing commas, bracket spacing, etc. — it also concerns people with dyslexia, alexia, ADHD, fatigue, brain fog, and so many other disabilities/conditions.

[cdauth]

When it's spaces: it's possible to set the number of visual spaces indentation takes.

Apart from the fact that most editors do not support setting the width of indentation spaces, while most editors do support setting the width of tabs, there are two types of indentation: One to indicate the level of nesting in the hierarchy of blocks of code, and one to align the beginning of the line with a specific character in the line of code above it. Tabs would be used for the first case and spaces for the second. If you use spaces for both, the editor has no way of knowing what type of indentation a space represents, so it cannot tell whether it should adjust the space width according to your setting or not.

I've worked with git’s feature of automatically converting spaces to tabs on checkout and with the rather broken plugin for VSCode to configure the width of indentation spaces, and both have been a real pain to work with because of this.

[junaga]

I actually found something tabs-only

Bash heredoc <<- syntax https://manpages.debian.org/stable//bash..en.html#Here_Documents

function info {
	ssh $REMOTE_USER@$REMOTE_HOSTNAME <<- FILE
		echo "==== files ===="
		ls
		echo "==== vars ===="
		env
	FILE
}

Bash heredoc enables multiline commands. Bash heredoc <<- syntax enables FILE indentation of the delimiter. Without this feature the code would look like this

function info {
	ssh $REMOTE_USER@$REMOTE_HOSTNAME << FILE
		echo "==== files ===="
		ls
		echo "==== vars ===="
		env
FILE
}

spaces dont work

[stylemistake]

First, this is unrelated to JS. Second, Bash has so many bad design choices and quirks, it's unsurprising heredoc syntax doesn't strip leading whitespace unless it's a tab. It's a language that was hacked into existence. It would be common sense to consider this a bug, but it won't be fixed because a change would break many shell scripts along the way.

UPD: This actually predates Bash, and they couldn't have fixed it because it would violate rules of Shell Command Language.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04

[WebReflection]

as this thread keeps going, I just wanted to share the "chicken / egg" situation we're living these days:

• markdown doesn't have any way to tell what's the visually preferred size for tabs and the Web, sadly, defaults to 8 spaces which is an abomination for every snippet of code that would ike to be instantly readable on Mobile Phones too
• browsers don't provide a tab size setting anywhere (last time I've checked) to override that horrifying 8 spaces legacy nobody wants or need since tabs were invented
• because not enough code and content is written with tabs, nobody cares about these details while I am pretty sure that if tabs were the default, every tool would surely have a setting/preference for users consuming tabs based content

Because of this, I had to change some README tabs based code into 2 spaces based code so that finally I can fully, and instantly, read that content on my iPhone mini, hence I believe on every other phone out there as the mini is a rare tiny format (that I love and I hope some Android one day will ship with such lovely size instead of going bigger and bigger yearly) so ... I am still convinced tabs must be pushed forward and the sooner we'll do that, the sooner we'll laugh at this forever going debate the day nobody would care about anymore and tabs would just be the norm.

[ljharb]

They do provide one, via CSS tab-size (which sites and user styles can both set). also, GitHub will obey .editorconfig in a repo and display tabs at the resulting width (via that CSS), so nobody has had to use spaces on GitHub.com for many many years.

[WebReflection]

They do provide one, via CSS tab-size (which sites and user styles can both set)

if I go in settings in Chrome and search for tab-size crickets are shown ... or were you talking about markdown transformers? Imho, browsers not offering any way to override globally those 8 spaces taken by each \t is a huge reason people don't like tabs in the first place: they are visually hostile by default on the Web, specially on mobile 😥

GitHub will obey .editorconfig in a repo and display tabs at the resulting width (via that CSS), so nobody has had to use spaces on GitHub.com for many many years.

TIL ... is .editorconfig something that, once at the root of any project, would dictate how docs would be rendered too? Pretty awkward I was not aware of this for README too, I thought that was a docs template only thing so ... thanks for the great news!

[ljharb]

It's not in browser settings, it's CSS - you can set it for every page with user styles, or individual websites can set it themselves. I completely agree that the default 8-space-width choice in browsers is horrific.

Yes, I believe it would.

[WebReflection]

I completely agree that the default 8-space-width choice in browsers is horrific

Until system wide (bash, sh, shells, consoles, terminals, browsers) are incapable of offering a single flag to accomodate user's choice around how big should be a tab, my original complain remains: in a world where tabs were the norm we would've this features already available out of the box everywhere ... because that's not the case, we ended up using spaces for 50 years here and there (there is a PEP for Python around 4 spaces and no tabs or variants outside 4 spaces) and the entirety of the software assume everyone is OK with spaces or everyone is OK with 8 width tab space from the 80's (or before that) in times the 80 columns max width was also an understandable limit to consider.

Today we have the worst of both worlds: the tech or the Web is there to fix this and nobody cares, as this discussion is a meme in other venues 🤷

[junaga]

@WebReflection it's a CSS property! and just like body { margin: 0; } or <meta name="viewport" content="width=device-width"> it should be reset by every app, site, and page, with * { tab-size: 2; }.

@WebReflection See, i get your point, and i would agree that the best course of action is when Unicode formally declares https://fonts.google.com/noto as the default font for humanity. So not only indentation but all characters in all languages look the same on every screen. also, while we are at it, lets deprecate Safari too.

The problem is: Code and text-data with tabs exists! prettier should not be trying to forge reality, but build around it!!

[WebReflection]

@junaga (or anyone else, really) ... I absolutely know tabs can be configured as CSS property, my point is that GitHub pages require special care and some place doesn't allow Markdown to define tabs size and overall the default on the Web is to show 8 spaces width tabs from times mobile devices didn't exist ... these are all useless friction for the cause where in my specific case, as stated all over the place before in this thread I want tabs to be the default but it's not just on prettier, it's everywhere and everywhere such default should be considered system wide too, not just out of a CSS property, or better ... let the CSS property exist and still allow me to decide that bash, sh, anything running in my console/terminal, any website I visit, by default, shows me a 2 width tabs and call it a day. Once that's possible and it's the default for every OS and Browser, it would be just plain silly for any opinionated tool to prefer spaces, imho.

I hope this is clear, I just wanted to present my latest attempt to use tabs and fail ... now I need to write a config file only GitHub markdown transformer would understand ... not too bad, but also not ideal.

[justrhysism]

@WebReflection something has to be the first domino. Why not Prettier?

The amount of time this thread has been going on, we could've set the default and as a community submitted PRs to fix all the potential downstream tooling/display concerns 🙄

[nickserv]

I actually found something tabs-only

Bash heredoc <<- syntax https://manpages.debian.org/stable//bash..en.html#Here_Documents

@junaga GNU Make requires tabs for your Makefile too! Space indents are still used, but they have a different meaning.