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
Comments
We don't change some of the default settings because it's funny 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. |
|
I agree with @kachkaev . We need to more discuss making |
useTabs
to true
by default for 2.0useTabs
to true
by default
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: 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 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 |
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: |
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? |
I'd love to read more about single vs double quotes in an issue dedicated to that.
…On August 5, 2022 8:03:08 PM UTC, Jordan Harband ***@***.***> wrote:
I think *any* default change that provides better accessibility should
be discussed - I'd love to read more about single vs double quotes in
an issue dedicated to that.
--
Reply to this email directly or view it on GitHub:
#7475 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
--
Sent from mobile
|
What? Like using tabs? |
Benefits of having tabs by default:
Disadvantages of having tabs by default:
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.
This is fine, it's just a preference.
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. I think @toastal said it best:
|
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.
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. |
@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". |
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? |
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? |
I also really want to emphasize this one: If your code includes 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. |
Then don't make the switch in the specific project affected by that issue. You added the If you think that not having the tooling to convert whitespace in a file using |
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". |
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. |
That is only valid if you assume that the majority of projects use |
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's just one part of the assumption, another part is people will naturally want to avoid big diffs and changes to external configs. |
I’m glad you agree that the transition will be seamless if the indentation default is changed. |
It would have been if behavior didn't change, but it definitely does change. |
The whitespace used for indentation doesn’t affect runtime behavior. |
Are we going into technicalities now? Prettier's output is a behavior, it formats code. |
By that definition, what breaking change would not change behavior? |
Let's say someone uses For this particular user this would break. For defaults users, nothing breaks. |
Fair enough. |
You mean, your personal preference of tab-width of which you are forcing onto others (when using spaces). |
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.
|
@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 :-) ) |
For copy/paste novices? 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. |
No, |
@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. |
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? |
Obviously because it's a good compromise.
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. |
ExE-Boss commentedJan 30, 2020
•
edited
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
The text was updated successfully, but these errors were encountered: