-
-
Notifications
You must be signed in to change notification settings - Fork 86
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
[omnisite docs] Contrast and font - terrible for my eyesight #517
Comments
The font choice could probably be a toggle like for dark/light theme. |
Would absolutely love to have headings in serif and the rest in sans-serif 🙌 |
+1 for being able easily switch back to sans-serif fonts. |
I appreaciate a refresh of the website since this major version is significant for the future of the framework. However, it seems to me it has been rushed. For example:
Overall, I'm super glad Svelte 5 is finally out, but the new website definitely needs a bit of work before going into the production. |
@codercms Your style (both the font and the colors) is a huge improvement. |
I agree, my eyes are begging me to leave the site. Look at the react site where the font is reasonably sized and perfectly built for readability. Imagine using times new roman in vscode, that's my experience with the new docs. I beg the team to learn from other projects like Docusaurus, React.dev, VitePress... This is pretty much the equivalent of the new svelte font in vscode |
This is literally awful, I can't even override this easily.
Please, consider making it easier to change at the very least. Set |
@mary-ext setting the variables on
(Fira Sans is already used for UI so I just set it to be used for body and headings too.) |
Ahh right yeah that seems to work, cheers |
For the record I'm using this browser extension called Stylebot with the following config: :root {
--sk-font-family-body: "Fira Sans";
--sk-font-size-body: 1.7rem;
--sk-font-size-body-small: 1.4em;
} Replacing |
I was excited for the launch but today I couldn't even finish reading the Svelte 5 announcement blog post. This font is not a good decision. |
This is my recipe:
|
I don't believe this is the right way to go about it. I think there's a couple of downsides to this approach:
Aside from that, I feel it's better to just discuss and come to a conclusion on things like this, rather than adding options and saying "the user can decide on their own." |
Indeed there is a couple a downsides to this approach, which is taking into account that the BDFL has fixed something that wasn't broken in the first place and that literally no one asked for. So in this way every approach that is not reverting to common practices will have downsides for at least someone.
This discussion never happened until now so it's safe to assume which one should be the default (or the single choice). To quote someone, though I don't remember who : "Cute features are never a good idea". |
While the Serif vs Sans-serif debate is an age-old question and largely a matter of personal preference, there are some guidelines for when to choose one over the other. For anyone who has delved even slightly into typography, you’ll know that some fonts are better suited to certain use cases than others. Sans-serif fonts were designed to be more easily read on screens. While monitors have come a long way, I—like many other developers—am not reading software documentation on a smartphone or a high-DPI monitor. I have a standard pixel density of 92 PPI. At this pixel density, small Sans-serif fonts are legitimately more readable. Serif fonts have more detail and nuance, which becomes harder to discern due to the low pixel count. As others have mentioned, no code editor uses a Serif font—and for good reason. I want to find what I’m searching for as quickly as possible, not for it to look aesthetically pleasing. Software documentation follows the same principles. I’m not reading a blog post where I can take my time, I’m trying to do my job, and the choice of font is making my—and others—life harder. This is not a discussion about design or personal preference but one about accessibility. If you have any respect for accessibility, which you should have, then the body font should be switched to Sans-serif. The significance of typography is frequently underestimated, but any serious designer should be well aware of its value. |
I would also like to point out that the theme really matters. The bright areas on a screen can perceptually cause a glare-like effect. I.e. with a light theme, the bright background eats into the characters and the serifs help the letters keep their corners/shape; with the dark theme, the letters bleed into their surroundings and the serifs just make this worse, almost fusing adjacent letters together. Rich is a light mode user, so I doubt that he has much of an issue 😅 I took a piece of text and exaggerated the effect using a bit of blur & blending to illustrate what I mean. |
@Rich-Harris can you bump this up to high priority please? |
Looks like a font switcher is being added in #604 |
I appreciate the effort but why not have just one good sans serif accessible font 👌 |
Thanks everyone for the feedback. A few points:
If you primarily engage with the written word through screens, especially on sites like GitHub and social media, then using a serif typeface might seem like an abuse of that freedom. For others, who look at screens begrudgingly because their work demands it, seeing documentation rendered in something like a Garamond feels like a breath of fresh air. I belong to the latter group, as do many others. We could just accept that using Inter or Source Sans Pro or system-ui is just what you do when you're building a technical documentation site, and avoid inviting threads like this one by not having any opinions at all. No-one got fired for choosing the lowest common denominator. But the aggregate effect of decisions like that is that the entire web looks the same. I don't accept that. We have, however, changed a few things since the site was launched:
If you struggle to read serif type for whatever reason, give it a try and see if it helps. |
All of these sites, and many others like them, do not even have a dark mode — I don't think they serve as good examples of accessibility or web design 😑 |
There's a poll in svelte reddit thread from which we can see only 30% of users like the new serif font, not a minority gathered in such github issues. Honestly, it’s already strange that the highly anticipated Svelte 5 release started with hundreds of developers asking for a font change on a newly redesigned site that had worked perfectly fine for years. And now, we have a font switcher. It almost feels like an April Fool’s joke 😅 |
BBC News is so committed to accessibility that it maintains a Pidgin language version. Readership is everything to a news site. If it were found that dark mode and sans-serifs made content more accessible to more people, you would see them falling over themselves to implement them. The fact that they haven't suggests that the numbers don't actually add up. I can believe this — anecdotally, a widespread preference for dark mode is something I've only really seen among techies. The accessibility case for dark mode is frequently overstated — what research exists generally suggests that dark mode is worse for reading comprehension in general, especially if you suffer from astigmatism. (I'm not arguing against dark mode, I'm challenging the suggestion that if a site lacks dark mode it's because it doesn't care about accessibility.)
Pretty much every redesign in history has faced a negative initial reaction, especially if it involves a change as jarring as this one. It takes time to adjust; I would ask you to keep an open mind. Moreover, this poll was conducted before the recent changes to improve readability. Making decisions based on polls is how you turn the world beige. |
yeah, on Windows the font antialiasing is done through subpixels, unlike on macOS, iOS/iPad OS, and Android where it's grayscale-based. However, I've seen some reports even on the Svelte Discord server of people with Hi-DPI screens (including a Macbook) saying it was very difficult to read, particularly on dark mode. |
Good move on the toggle.
Arguably the only reason for this is historical, and nobody ever dared to change it because they knew Those without print history like BBC most likely chose serif more for the charge it conveys (authority, tradition, everything that Svelte is not) and the newspaper look and feel than for readability. Thing is when visiting a news site you actually plan to read and enjoy it, and serif helps create a literary mood. When visiting a doc site you just want to get to the point (especially since the Svelte docs have always emphasized the "come when you need" approach) and sans-serif is hard to beat at this game (less cluttered so easier to read).
So now it looks like the most visited site in the world ;) I'm all behind the intention but switching to serif is kind of a under-powered move if the goal is to make a ground breaking website. Isn't Times New Roman the default for HTML on most browser ? It's still the same boring docs site than before, like any other docs site, with a different font. There is actually room for very interesting typographic/formatting design on a docs site for whoever want to bring something new, but it requires more than changing a font obviously. |
@Rich-Harris If we’re talking about an eye-friendly font mode: I don’t think headings should stay in a serif font; I don’t know where that idea even came from. When the headings are serif, they’re still unfriendly to my vision impairment. As for colors, my eyes can’t stand deep black, but gray is actually quite pleasant. Current documentation before adjustments And previous documentation – Much better I don’t have the strength to keep fighting this, I feel resigned. |
It's an accessibility issue as soon as someone has light sensitivity issues or experiences increased glare (e.g. due to cataracts or damage to the cornea). For the most part, companies only care about things for which there is a legal or business case and as you noted, not many people want (or need) dark mode. So I'm not surprised that dark & high contrast modes are not more widely supported. @lukaszpolowczyk Would recommend using a browser extension to change styles if you often have issues with fonts/contrast. |
@brunnerh I know, I’ll think about it later.
@brunnerh Perhaps Rich wants to show us that he doesn’t care about accessibility or people with visual impairments. |
I think it is wrong to compare News portals with sites from the IT sector, more precisely with a development library whose goal is to create web pages. Also, I wouldn't say that these sectors can be compared in the context of design or font selection, which definitely strongly influence the look and style of the brand they represent. As previously mentioned above, newspapers and news globally have a completely different task and goal, and draw style and traditional roots for many centuries that digital media have actually just taken over. Why do the vast majority of documentation websites have a 3-column layout, left-center-right? Well because this works really well for what it's intended for, quick and intuitive browsing of content and finding the information you want, and that's it. It's not about a revolution in how the web world should actually look, according to Rich's opinion, which he mentions, it's about simplicity and the task that the site should accomplish. If we look at it from an open perspective, tastes are not discussed. Of course, you have the right to your own choice of solutions and designs that you want to represent your brand. I think that most of the people came to leave their feedback because they like Svelte and the ecosystem that suddenly turned the style maybe in the wrong direction that they were not used to and it bothered them. This font-switcher is ok in a way, we have a choice, but all this gives me a certain amount of complication and semi-professionalism to be honest. I have a good opinion of your team and you are really doing a great job, but regarding these moves I have the impression that you may be missing a good designer to complete the team so that the rest of the I wonder if the people from All in all, this didn't exactly turn out to be a great presentation of the Svelte 5 (which is actually great 👍🏻) and lost focus for a while, but I hope everything will settle down soon. |
I use a retina studio display in ideal reading conditions, with perfect eye sight. I also spend a huge amount of time reading serifs in print and on my kindle, so it's not as if I'm not accustomed to it. In light mode, the Svelte serif is at the edge of readable. It's just a bit too small. However, in dark mode, the serif definitely too small. And the tad-too-dark gray does nothing to help the situation. In both light and dark mode, the sans-serif is plainly more readable. Heck, even Github's tiny font on long lines with harsh contrast is more readable than the Svelte dark mode serif. When it comes to accessibility, I think the question should be—accessible to whom? If your audience is developers, and developers prefer sans-serif dark mode, then that should be the default. If you're audience is 55+ romance readers, then sure, go with a light-mode serif at 24pts. The controls available on screen are great options. But for the default, give it to the largest community. How about an experiment where you force all users to set their preferences before they have access to any content? You can run this on 1% of the population for a week, and have all the data you need on the font, size, and color choices of people who actually use Svelte. |
Documentation should feel authoritative. And Svelte is very much rooted in the traditions of the web, hence the HTML-first outlook and preference for normal CSS rather than e.g. CSS-in-JS or Tailwind — when people think of modern web development they think of JSX and hooks and complex state management and impenetrable build tooling and all the other things that Svelte stands against.
Most visitors to news sites are reading something specific, they're not there to have a good time. I should know. But even if that were the case: Does The Verge's FK Roman but you in a literary mood when you catch up on WWDC? Does Eater's Garamond Premier Pro put you in a literary mood when you figure out where to make a reservation this weekend? Does Bon Appetit's Radley put you in a literary mood while you're baking cookies? Does Claude's Tiempos Text put you in a literary mood when you ask it a question? I could go on.
No-one has yet suggested a reason that technical documentation is fundamentally different than other forms of prose that doesn't ultimately boil down to "developers are special and different", which is a widespread belief but not one that's grounded in anything particularly convincing.
The generally accepted wisdom is that higher contrast is more accessible than lower contrast. Indeed, 'insufficient contrast' was one of the complaints I heard about the old website, and even in this very thread people are making the case that there's still not enough contrast in dark mode. The cause of accessibility is not advanced by orienting the world around your preferences. We already have a font toggle, a light/dark toggle, a different default font for low resolution screens, and CSS that's designed to work well with zoomed in text (we use rem units everywhere rather than px). We've taken care to ensure that things are keyboard-navigable and suitable for screen readers and progressively enhanced wherever possible. As far as I'm aware we're still the only framework that has accessibility checking built-in. Of course we care about accessibility. The long and the short of it is this: if you have a specific visual impairment that makes the current documentation hard to read in spite of all of that, then we could probably improve it for you, but only in a way that makes it worse for other people. There's not much to be gained by continuing this thread, so — given that we've already a variety of changes including introducing the toggle — I'm going to close it. |
@Rich-Harris None of the sites I’ve shown, apart from YouTube comments, have as deep a black as the new Svelte documentation. Are you suggesting that each of them has poor contrast? And you completely ignored the point that in a visually accessible mode, the headers should also have an accessible font. If someone switches to a different font, it clearly means they don’t want a serif font, so why force it in the headers? But, as I said before, I don’t have the energy to argue about it; there’s no room for discussion with you. |
@lukaszpolowczyk, it's not that Rich doesn't care about accessibility. There are vision impairment conditions which are more common than astigmatism, and make reading low contrast more difficult, and users who have these conditions find high contrast more readable. If the contrast were reduced, more users would feel the same as you feel currently. Also, there are some technical circumstances where higher contrast is preferable:
Unfortunately, it's not possible to find a theme that suits everyone. Should the site have a high-contrast/low-contrast switch also? Think about other users (including impaired users) too. I recommend using a browser extension to change the contrast. |
@notramo I see you didn't read my last comment. Try reading it. |
I gotta second @lukaszpolowczyk, as another person with astigmatism, the previous website design always struck me as elegant and a joy to read. The new font and colors completely erased those feelings. It's a massive difference in my eyes. Really wish the design just stayed the same. |
I still feel like you're missing the crux of the issue. This discussion is not about whether we like the font or not, it's about the fact that many individuals are having trouble reading it.
We have, it's not the same use case. I doubt many of us read the documentation as if it were a novel or a news article, rather, we skim through it to find specific information that helps us resolve bugs and continue our work efficiently. Even without taking into account visual impairments, having more legible text makes this process a lot easier. If the product is something that is consumed for leisure then this would be a non-issue, however people are dependant of this website to get real work done. I am also confident that more developers access documentation on lower PPI screens than users of news websites. Unlike news articles, documentation is less frequently accessed on mobile devices, where higher PPI screens can mitigate readability issues. These, I feel the designers don't seem to understand. You're building a product for a specific audience with unique needs. You cannot take design principles from a news site, which has an entirely different content consumption model and slap the them onto something unrelated. It's essential to understand your target audience and make design decisions that cater to their specific requirements. Thank you for taking the time to consider our concerns. Even if the core issue may not be fully understood, I genuinely appreciate the addition of the font toggle on the website. 🙌 |
As I say, most people consuming news articles are looking for specific information quickly. This is something that is drilled into reporters from the first day of j-school — people are not settling down with a cup of tea to luxuriate in your prose, they are trying to make sense of the world. The parallels between documentation and news consumption are much closer than people here imagine, though I also gave several other explicitly task-oriented scenarios (recipes, Claude etc). Developers are not the only people that need to 'find specific information'! We are not special snowflakes. But even if we were, this notion that certain fonts only belong on long form content because they're less readable makes no sense. Which is why, aside from low PPI screens (which are catered for via a media query and via the toggle), and visual impairments that can't be addressed without worsening things for some other population, I can't escape the conclusion that this a question of culture ('everyone else does it this way') and subjective preference. |
@Rich-Harris Please, also change the header fonts in Eye-friendly Mode. |
Fair point, I am not one of those people. I assumed you'd have to have the read the majority of an article to have the context.
Then I ask you why don't any code editors use a serif font by default ? Why doesn't MacOs, Windows, IOS, or Android use a serif font by default ? I can't find any concrete evidence as to why, maybe internal studies have been done I don't know. But it seems a bit farfetched to say that every major company that creates interfaces chose sans-serif just by coincidence. For me personally smaller texts using serif fonts take a lot more effort for me to read (on a low dpi screen at least) and I'm apparently not alone. The current serif font for me just kinda becomes a blur when trying to skim through it. I couldn't pin point the reason why. Maybe it's simply a matter of habit, because I've spent 7 hours a day for the last 15 years skimming through code in sans-serif. It's not unreasonable to assume the majority of other people visiting the website won't have a similar past. If I spent my days reading books or news articles for a living I wouldn't be here now. |
While I wouldn't usually quote a Quora as a reliable source, this post seems rather well educated and goes into quite a bit of depth. https://smg.quora.com/Why-do-books-use-serif-vs-sans-serif-fonts-for-the-main-text-almost-exclusively As far as I understand it, serifs seem to be more suited towards longer reading sessions to prevent fatigue. Whereas sans-serifs optimise the space therefor making it easier to make out each individual letter, especially relevant with a lower pixel density. This passage in particular :
There's also the matter of what you're most used to
|
Code itself often relies on alignment, and whitespace is significant (even in JavaScript i.e. newlines), so it's a different beast. I'd love to see some experiments of using non-monospace fonts (even if just for e.g. comments), but that would truly be a leap! We're not quite that contrarian.
A combination of culture (sans serif is viewed as more 'modern', which is obviously viewed as desirable if you're a gadget maker) and history (older screens struggled with details), I think. These two things are mutually reinforcing — because digital devices were limited by technical constraints, sans serif type became associated with digital devices and therefore 'modern'. UI elements are also often very small, which means the technical constraints are even more constraining. I would theorize (without any scientific basis mind you) that your brain processes these elements as symbols more than as words. (Worth noting that MS DOS and other text-based interfaces of the era did in fact use serif 'fonts'; the transition to sans serifs coincides with the transition to the WIMP era, in which text was deprioritised in favour of symbols.) On svelte.dev we distinguish between headers, body copy, UI elements and code — each of these serve distinct purposes and thus have distinct typography.
Indeed. My prediction is that as high density screens become ubiquitous, we'll see a lot more varied typography in digital designs, and sites that use the same handful of fonts (Inter etc) will come to look very tired in the same way that sites using default font stacks came to look very tired once |
I don't think this is true. Once again it depends on the font and the use case. There's been a trend over the past year or so in web design that uses huge serif fonts. To be fair mainly portfolios and luxury, but I don't think using a serif font necessarily makes it "not modern".
I don't disagree, but we're not there yet. Designing for "what might be in the futur" feels a bit odd if you ask me. I don't think developers or software engineers are in any rush to get hold of 4k monitors. For other audiences it might make sense but the site we're talking about isn't about a luxury brand or the next Apple trying to break boundaries in design or aesthetics, it's a javascript library documentation. In the current day and age, the majority of your audience is probably using a standard resolution monitor, is more accustom to seeing sans-serif, and is skimming through text rather than reading the doc for extended amounts of time which appears to be better suited to sans-serif. Though agreed I'd love to see some actual data on all this, it's an interesting topic.
I understand the envy to break the rules and be different, but isn't catering to what best fits your audience more important ? |
@gterras By the way, the fact is, Wikipedia also has a more eye-friendly dark mode. :| Wikipedia has a lighter background but even lighter text. The contrast is HIGHER – 15.64. This can be done for Svelte too, but @Rich-Harris seems to pretend not to understand this. That's it for now. Someday, I'll open a separate issue comparing good contrasts and backgrounds to make it easier to see. |
Have you checked the recent changes to dark mode? It's now actually lighter than the v4 docs were. The blue-ish tint remains, but if that's pleasant to the eye or not depends very much on taste and your eyesight (there are people who can read that much better, and possibly people like you who have problems with a tint of blue; we can't make it right for everyone here) |
You 100% can, see my message just above. |
Describe the problem
"My astigmatism cannot be corrected with glasses, which results in my vision looking like this (while wearing glasses):
image
(double and shifted image. I see this way even when looking with one eye, it's not a squint, but rather astigmatism)
It’s worst with strong contrast, deep blacks, and bright text.
But the font is equally important. The more elaborate the font, the worse it gets.
Not only is it hard for me to read, but I actually feel discomfort and want to leave the site that has such contrast and font settings.
Light side mode is just... too bright. I don't want to use light mode anywhere, it's an unwanted compulsion in some places, but I avoid light mode.
It's disappointing because the previous version of the site had contrast and fonts that were very comfortable for me."
Describe the proposed solution
Many websites are very well designed for my visual impairment (consciously or unconsciously), e.g.:
This Github style
ChatGPT
YouTube
This Twitter style
Facebook
Old Svelte documentation
And many more.
Importance
would make my life easier
The text was updated successfully, but these errors were encountered: