Skip to content
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

Change useTabs to true by default #7475

Open
ExE-Boss opened this issue Jan 30, 2020 · 240 comments
Open

Change useTabs to true by default #7475

ExE-Boss opened this issue Jan 30, 2020 · 240 comments
Labels
area:api status:needs discussion
Milestone

Comments

@ExE-Boss
Copy link
Contributor

ExE-Boss commented Jan 30, 2020

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:


See also: #6888

@Shinigami92
Copy link
Member

Shinigami92 commented Jan 30, 2020

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
Copy link
Member

kachkaev commented Jan 30, 2020

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
Copy link
Member

alexander-akait commented Jan 30, 2020

👎 On that for 2.0

@sosukesuzuki
Copy link
Member

sosukesuzuki commented Jan 30, 2020

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
Copy link

milesj commented Mar 21, 2020

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.

@thorn0 thorn0 added area:api status:needs discussion labels May 22, 2020
@schalkneethling
Copy link

schalkneethling commented Aug 4, 2020

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
Copy link

MarcoZehe commented Aug 4, 2020

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
Copy link
Member

kachkaev commented Feb 21, 2021

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
Copy link

justingolden21 commented Jun 29, 2021

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
Copy link

skuridin commented Dec 19, 2021

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

@benlesh
Copy link

benlesh commented Feb 2, 2022

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
Copy link

fbartho commented Feb 2, 2022

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.

@kachkaev kachkaev added this to the 3.0 milestone Feb 2, 2022
@alexander-akait
Copy link
Member

alexander-akait commented Feb 2, 2022

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

@atomiks
Copy link

atomiks commented Jun 28, 2022

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?).

Markdown documents, pull requests, etc. are going to have unsightly spacing by default with this change unless the developer changes the setting which I don't think many are aware of.

For a change like this to cause least friction, GitHub and other major code hosting providers would need to change tab rendering to a default of 2 instead of 8 spaces. But even that can be a bit of a problem, as some languages prefer 4. Editors like VS Code also default to 4 instead of 2.

Judging by this issue I think we agree that defaults matter, even if the setting is easy to change, e.g. guest readers

Preact uses tabs and this is what its README code blocks look like, which is borderline unreadable to me:

Screen Shot 2022-06-28 at 9 02 37 pm

@anaisbetts
Copy link

anaisbetts commented Jun 28, 2022

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?

@Scrxtchy
Copy link

Scrxtchy commented Aug 6, 2022

@justrhysism
Copy link

justrhysism commented Aug 6, 2022

@stylemistake

It seems that you should direct your efforts towards supporting more flexible indentation settings

What? Like using tabs? 🤣

@Stealcase
Copy link

Stealcase commented Aug 15, 2022

Benefits of having tabs by default:

  • Tabs often offer more visualization customization/accessibility options in IDE's.
  • More new projects are automatically more accessible without users having to argue their case.
  • This only changes the default, it does not affect users who have made an explicit choice.

Disadvantages of having tabs by default:

  • 👀 Some people prefer spaces.

Alright, then just change the config. Nobody is forcing you to use tabs. It takes less time to toggle a boolean than it took me to write this.

  • 👀 People who prefer spaces and are adamant that spaces are superior won't have that bias affirmed by prettier.

This is fine, it's just a preference.

  • This is a breaking change, many projects will be affected.

This is the only legitimate complaint, but I would argue the benefits outweigh the tradeoffs. This is a major version update, people should EXPECT breaking changes. This change should be documented in a migration guide, but that's really it.

The idea that tab ideology is being forced on anyone is silly. I've used prettier for years, with tabs being my normal way of indenting code.
Despite this, my prettier config is set to the default "use spaces", and I've never really noticed.

I think @toastal said it best:

This does not affect users who prefer tabs or spaces, this affects the default only (no stance chosen). The types of folks with an adamant stance, likely already explicitly set it in in Prettier's config or EditorConfig. The argument for the change isn't really taking a side in tabs vs. space for individual teams/projects as both are supported explicitly (unlike many other formatters that don't make spacing configurable).

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

Very biased and misleading summary. You're intentionally ignoring half of the thread worth of arguments against the switch and then drawing the wrong conclusions. You probably haven't dealt personally with problems that tabs create.

The idea that tab ideology is being forced on anyone is silly.

Then why change the default in the first place? Not introducing a yet another breaking change in a major release would be a lot more pragmatic.

Once again, I ask you to upvote this feature request microsoft/vscode#132776, or raise the same feature request for your favourite editor, based on real accessibility concerns, and put an end to this silly crusade.

@ljharb
Copy link

ljharb commented Aug 15, 2022

@stylemistake what problems? i'd love to hear about something more than "the default width is 8 when a website fails to set the tab-size CSS style".

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

Here's a trivial example: I copy paste code into Discord and it converts it down to 4 spaces. Can you tell it to treat it as 2 spaces for some nested react component? No. If you copy it back, it is copied with spaces.

This extends to a whole zoo of tools that I use every day and all of them need to be configured separately. Most of them are used for reading code, so it doesn't even make sense to configure them if projects use spaces, and tab width can even vary per project based on how nested the code is.

In what case would I be incentivized for using tabs when so many things need to be configured?

@ljharb
Copy link

ljharb commented Aug 15, 2022

That sounds like a pretty serious bug in Discord - I'd suggest filing it. If you do, I'm happy to forward the link to some friends that work there so they can prioritize it.

I would think that if there's a tool that isn't easily configurable, and/or doesn't read .editorconfig, that you wouldn't want to use it in the first place, since "their defaults happen to work for you" is a lucky scenario that could change at any time. Do you have any other specific examples?

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

I also really want to emphasize this one:

If your code includes // prettier-ignore at any point, prettier with not replace tabs with spaces on that line or vice versa.

This will amplify the mixed tabs and spaces problem to levels never seen before. I have personally experienced this when I was transitioning a project from spaces to tabs and it was the most painful transition ever which I'd prefer to never endure again in my life.

@dantman
Copy link

dantman commented Aug 15, 2022

If your code includes // prettier-ignore at any point, prettier with not replace tabs with spaces on that line or vice versa.

This will amplify the mixed tabs and spaces problem to levels never seen before. I have personally experienced this when I was transitioning a project from spaces to tabs and it was the most painful transition ever which I'd prefer to never endure ever in my life.

Then don't make the switch in the specific project affected by that issue. You added the // prettier-ignore to tell Prettier to not format your code, then you can just add useTabs: false to tell Prettier that project uses spaces. That's completely irrelevant to what the default value is.

If you think that not having the tooling to convert whitespace in a file using // prettier-ignore is a real issue worth solving, then open a separate issue to get it fixed.

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

Sure, I could create an issue for this, but I am a man of firm belief that breaking changes should be as painless as possible. If the upgrade strategy involves the majority of users explicitly setting useTabs and ignoring the new default, I see it as a fundamentally broken idea. Even if this is meant for "only the new projects".

@ljharb
Copy link

ljharb commented Aug 15, 2022

How is that painful? It’s adding one line to config - one that arguably should have been there anyway, since relying on defaults is a bad practice.

@dantman
Copy link

dantman commented Aug 15, 2022

If the upgrade strategy involves the majority of users explicitly setting useTabs and ignoring the new default, I see it as a fundamentally broken idea.

That is only valid if you assume that the majority of projects use // prettier-ignore. Which frankly, I see no reason to blindly assume so and sounds more like a red herring.

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

relying on defaults is a bad practice

Defaults are there for a reason.

Omitted config entries can enable a more seamless transition when breaking changes are introduced that don't change the behavior (provided you're using defaults), and having explicit config entries can sometimes increase breakage on major releases.

Also users can't be blamed for keeping their configs short.

That is only valid if you assume that the majority of projects use // prettier-ignore

That's just one part of the assumption, another part is people will naturally want to avoid big diffs and changes to external configs.

@ljharb
Copy link

ljharb commented Aug 15, 2022

I’m glad you agree that the transition will be seamless if the indentation default is changed.

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

It would have been if behavior didn't change, but it definitely does change.

@ljharb
Copy link

ljharb commented Aug 15, 2022

The whitespace used for indentation doesn’t affect runtime behavior.

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

Are we going into technicalities now? Prettier's output is a behavior, it formats code.

@ljharb
Copy link

ljharb commented Aug 15, 2022

By that definition, what breaking change would not change behavior?

@stylemistake
Copy link

stylemistake commented Aug 15, 2022

Let's say someone uses jsxBracketSameLine: true while the default is false. Prettier v3 removes this option in favor of bracketSameLine: false.

For this particular user this would break. For defaults users, nothing breaks.

@ljharb
Copy link

ljharb commented Aug 15, 2022

Fair enough.

@justrhysism
Copy link

justrhysism commented Aug 15, 2022

...and tab width can even vary per project based on how nested the code is.

You mean, your personal preference of tab-width of which you are forcing onto others (when using spaces).

@dmadisetti
Copy link

dmadisetti commented Aug 16, 2022

The ownership of household computers/ laptops has remained constant in global south relative to the rapid growth of smartphone ownership. (1, 2)

Changing the defaults in prettier potentially creates a barrier to access for those who can only access the internet via mobile (and most likely programming in JavaScript). From this thread, the consensus is that mobile keyboards are not good (case in point, fig 2 (1)). Programming in a mix of spaces and tabs is not a friendly or welcoming experience.

While prettier can address this issue (yes, yes, haha)- a tab default does not lower the barrier to entry.

Accessibility goes beyond the differently-abled, it's important to keep in mind that resource is a privilege- and adding challenges to the aspiring developer with only an old phone and a library book is not accessible.

[1]: https://arxiv.org/pdf/2107.12257.pdf
[2]: https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet/india/#monthly-201007-202207

@ljharb
Copy link

ljharb commented Aug 16, 2022

@dmadisetti anyone using those devices to edit in a repo that requires prettier (or any other autoformatter) has either a) already been handled by the repo autoformatting it for them, b) has already located a tool that makes this easy, like codespaces or something, or c) is screwed regardless of what the indentation is, meaning that it's irrelevant to this issue (which may have been your point :-) )

@dmadisetti
Copy link

dmadisetti commented Aug 16, 2022

For copy/paste novices? a and b are predicated on understanding formatting in the first place. The real is answer is c- but not defaulting to tabs reduces the noise.

Changes in prettier will send a very strong signal and touch all code. I think 2 different, non-discernible white-space characters adds blockers to prospective developers.

@dantman
Copy link

dantman commented Aug 16, 2022

For copy/paste novices? a and b are predicated on understanding formatting in the first place.

No, a is automatic, a CI system runs whether the user knows what formatting is or not.

@ljharb
Copy link

ljharb commented Aug 16, 2022

@dmadisetti such a user won't have prettier running in their env. as such, they'll make changes that violate prettier in a myriad of ways, totally unrelated to indentation - whether it's set to spaces or tabs, regardless of what the default is. Solving that a11y issue would be a great service! However, it has precisely zero bearing on a debate about this configuration value, or any other, because it's just as terrible for every single one of them, with any configuration.

@dantman
Copy link

dantman commented Aug 16, 2022

Yes, as I've said before on this whole topic about mobile-only developers. It feels like we have a group of people who are under-served by current tooling and need access to proper tooling. And instead of being given that tooling, are being used to try and deny accessibility improvements to another group of people. While spaces are presented as "good enough" for people programming on mobile. Even though such a limited environment implies that mobile users are missing access to a bunch of other things we take for granted on the desktop. Like easy access to the special characters every programming language is littered with and the ability to indent with a single keypress.

"We can't do something that would definitively improve accessibility in most tools for people who need to control the tab width, because maybe it would make it slightly harder for someone programming on mobile."

Why is the solution for these people "use spaces so they don't have to deal with tabs" and not "give them mobile accessible tools that handle tabs"?

Also, anyone care to consider that the ability to control tab width could also be beneficial to someone on a small screen who has limited horizontal space for displaying code?

@stylemistake
Copy link

stylemistake commented Aug 16, 2022

Why is the solution for these people "use spaces so they don't have to deal with tabs" and not "give them mobile accessible tools that handle tabs"?

Obviously because it's a good compromise.

Also, anyone care to consider that the ability to control tab width could also be beneficial to someone on a small screen who has limited horizontal space for displaying code?

Then why not give people accessible tools to set how wide indentation should appear regardless of whether it is a tab or a bunch of spaces?

@dmadisetti has a really good point here, having spaces lowers the barrier to entry because it is ubiquitous and doesn't require special tooling to view and edit code in a way that is appropriate for the project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:api status:needs discussion
Projects
None yet
Development

No branches or pull requests