Closed lukaszpolowczyk closed 1 month ago
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 🙌
This is how I have customized mine.
Modifying page's CSS to use font-family: system-ui
makes it much more readable for me
--sk-font-family-ui: system-ui;
--sk-font-family-body: system-ui;
--sk-font-family-heading: system-ui;
+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:
The button to get started is easy to overlook.
Why are the charts black and white if they reference to something that is not old or deprecated?
List of companies using Svelte looks nice on the desktop but on the mobile the logos strip looks weird:
The actual font used in documentation, as metioned in this issue. It's a lot harder to read. If you compare it with the Nuxt docs, the Svelte ones are much harder to read.
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. The entire site should be in non serif fonts, documentation should be built for practicality not aesthetic.
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... There's no need to reinvent the wheel when it comes to documentation. We have standards for a reason.
This is pretty much the equivalent of the new svelte font in vscode Imagine having to read through hours of technical content with this font on a computer screen
This is literally awful, I can't even override this easily.
svelte-omnisite.vercel.app##body:style(font-family: sans-serif !important)
doesn't work, because the font-family are being set in each individual component
svelte-omnisite.vercel.app##body:style(--sk-font-family-ui: sans-serif; --sk-font-family-body: sans-serif; --sk-font-family-heading: sans-serif; --sk-font-family-mono: monospace)
this one also doesn't work, because for whatever reason it just doesn't, it doesn't work if I put the override on :root
either.
Please, consider making it easier to change at the very least. Set font-family
on where it actually matters like body
for whole-app font and code
/pre
for monospace, don't do it on individual elements where someone would have to manually change them one by one just to get something that is actually readable for them. Make it possible for someone to use the fonts that they've already set on their browser, or make it easy to override with basic CSS rules.
@mary-ext setting the variables on html
works for me:
svelte-omnisite.vercel.app##html:style(--sk-font-family-body: Fira Sans !important; --sk-font-family-heading: Fira Sans !important;)
(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 "Fira Sans"
with system-ui
works too.
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:
/*change the p, ol, and ul font family to the system font or Verdana*/
:root {
--sk-font-family-body: system-ui, 'Verdana';
}
/*make the small code blocks bigger and give them a white color*/
.text.svelte-zj4hfh code:not(pre *) {
color: white;
font-size: 11pt;
}
/*add a white hover to the side nav links*/
a.svelte-s0ea8g:hover {
color: white
}
/*Make side nav links current page svelte orange*/
[aria-current="page"].svelte-s0ea8g {
color: var(--sk-theme-1)!important;
}
The font choice could probably be a toggle like for dark/light theme.
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."
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.
the discussion to "which font should be the default?"
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.
for content more broadly it's extremely common to see serifs. The BBC is the most visited news site in the world, and it uses serifs. So do the New York Times, The Guardian, The Washington Post... I could go on.
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 😅
I don't think they serve as good examples of accessibility or web design
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.)
There's a poll in svelte reddit thread from which we can see only 30% of users like the new serif font
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.
It is true that serifs have historically dominated on screens, because pre-Retina pixel densities weren't up to the task of rendering small details (notwithstanding the fact that Times New Roman has been the default web font more or less since the web existed). This is particularly true on Windows, which for whatever reason (patents? idk) has seemingly never been able to render fonts well as other operating systems, particularly macOS. For that reason, on low resolution screens we replace EB Garamond with Georgia, which trades a little bit of elegance for increased legibility on blockier screens.
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. I think the problem is not that the font is serif per se, but rather that it is too thin for body text, and when the background is darker it creates a very weird effect on my eyes (doesn't happen much on light mode, and I am on Windows).
Good move on the toggle.
for content more broadly it's extremely common to see serifs. The BBC is the most visited news site in the world, and it uses serifs. So do the New York Times, The Guardian, The Washington Post... I could go on.
Arguably the only reason for this is historical, and nobody ever dared to change it because they knew pretty much every redesign in history has faced a negative initial reaction.
In this case it would probably be a bad idea to change anyway.
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).
But the aggregate effect of decisions like that is that the entire web looks the same. I don't accept that.
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. I see nothing has changed:
Current documentation before adjustments Background: rgb(17, 19, 23) Current documentation adjusted Atkinson Hyperlegible Background: rgb(17, 19, 23)
And previous documentation – Much better Background: rgb(26, 26, 26)
I don’t have the strength to keep fighting this, I feel resigned.
I'm challenging the suggestion that if a site lacks dark mode it's because it doesn't care about accessibility
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.
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.
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.
@brunnerh Perhaps Rich wants to show us that he doesn’t care about accessibility or people with visual impairments. But as I said, I don’t have the energy to fight this—if Rich has a clear philosophy on this matter, it just makes me feel bad about it.
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 Developers
can focus on Svelte
and the Designers
on representing the Brand
in the best possible way.
I wonder if the people from Vercel
can jump in with their opinion, they have a very good design team, so you can try to come up with the design of the site together, while still keeping some of the uniqueness that Rich advocates.
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.
(authority, tradition, everything that Svelte is not)
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.
Thing is when visiting a news site you actually plan to read and enjoy it, and serif helps create a literary mood.
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.
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.
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.
Perhaps Rich wants to show us that he doesn’t care about accessibility or people with visual impairments.
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. They all have good contrast.
Are you suggesting that each of them has poor contrast? What you're saying makes no sense—less deep black doesn’t mean there will be less contrast; all you have to do is increase the brightness of the letters appropriately.
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've seen a ton of extremely positive reactions to the serif typeface, including from people with serious design chops. That may seem doubtful here, because people only come to the issue tracker for things they don't like
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.
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.
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. 🙌
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
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.
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.
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.
But even if we were, this notion that certain fonts only belong on long form content because they're less readable makes no sense.
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 :
In typography, color refers to the overall distribution of black on white space (assuming black letters on a white page). Essentially what serifs do is offer a better distribution. You can think of sans-serif as being high contrast (relatively simple black shapes with a lot of white in between), while serifs offer a smoother image. In the image below you can see the effect amplified.
The presence of serifs causes a more even color, which effectively lowers the contrast and thus offers a smoother reading experience. When you set one book in Futura and one book in Garamond, your eyes will start to tire sooner with Futura than with Garamond. Conversely, sans-serif typefaces tend to work well on the screen and mobile phones because rasterized sans-serif typefaces can in principle use the given space more efficiently, because due to the lack of serifs it has more horizontal space to work with.
There's also the matter of what you're most used to
There are a myriad of reasons why serif typefaces perform well for extended texts, but what’s also true is that the more we see certain typefaces, the easier they are to read.
why don't any code editors use a serif font by default ?
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.
Why doesn't MacOs, Windows, IOS, or Android use a serif font by default ?
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.
what’s also true is that the more we see certain typefaces, the easier they are to read
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 @font-face
became a thing. Conversely, as more sites start to use pre-digital typography, and more people become accustomed to it, those sites will be the ones that people perceive as 'modern'. But someone has to go first!
sans serif is viewed as more 'modern'
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".
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
@font-face
became a thing.
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.
those sites will be the ones that people perceive as 'modern'. But someone has to go first!
I understand the envy to break the rules and be different, but isn't catering to what best fits your audience more important ?
FYI I've just noticed this side panel on wikipedia:
This is surprisingly very efficient and pleasant to use, and it seems like there is a lot of potential to it. Reading preferences are glorified for once. Actually felt like the spark of revolution this PR was after.
@gterras By the way, the fact is, Wikipedia also has a more eye-friendly dark mode. :| (although it's not perfect; the background could be a bit lighter and less blueish)
Wikipedia has a lighter background but even lighter text. The contrast is HIGHER – 15.64. And Svelte has a contrast of 10.29.
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)
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