Please Stop Using Grey Text
tangledweb.xyz
tangledweb.xyz
I have moderate amblyopia and severe astigmatism. For a frame of reference, I only barely pass the driver’s license vision test when I renew my license (don’t worry I don’t actually drive).
My vision has good days and bad days. My ophthalmologist thinks that I frequently have eye strain from looking at screens which further (temporarily) degrades my vision.
Examples that I’ve run into _in the last 24 hours_.
- Why can’t I choose the colors of web sites and applications?
- Why can’t I choose (and override) the default typefaces on mobile browsers?
- Why can’t I change the default system font for my iPhone or my Mac?
- Why can’t I change the font size in modern video games?
- Why do most desktop applications fall of the edge of the screen below 1080p?
I rely on hacky tools to get by — e.g. momentarily dropping HIDPI or jail breaking devices. No one would want to use technology the way I have to. It sucks and it’s constantly getting worse.For what it's worth, Firefox lets you edit them:
http://kb.mozillazine.org/index.php?title=UserContent.css&pr...
Not terribly easily, but you can do it for any site. For example I fixed a GitHub bug for myself: https://github.com/github/feedback/discussions/8098#discussi...
There is a world of styles out there: https://userstyles.world/
That does come with downsides such as Nightly being less stable and installing extensions requiring some extra setup, so it isn't the best choice for everyone. But I myself am using Stylus (which works perfectly fine) and some other not officially supported WebExtensions on mobile this way and can recommend it if you don't mind the downsides.
[1]: https://blog.mozilla.org/addons/2020/09/29/expanded-extensio...
Given the partitioning of device storage, my understanding is that it's either not possible. I'm not sure the browser itself even supports userContent.css.
Would it work with a... opionated website with a hundreds of !important all over the CSS?
Over all, I’m much pleased by the results of forcing Equity/Concourse/Triplicate.
Most states have something like this. Typically you fill out some forms and pay a fee to get a “State ID”. Just be prepared for people to give you shit about it occasionally when ID’d.
If you’ve already gotten your drivers license in the past though, I don’t see any good reasons to get a new ID vs just renewing the driver license.
I do still technically pass the vision test, but I don’t think it tests for impairment from astigmatism very well.
It’s not rational, but I think a big part of keeping my license is anxiety. It’s really challenging to get around in America without driving. Knowing that my license is still valid makes me feel less trapped.
People need a ride to the hospital all the time, if the state says your vision is up to the task of doing it, why not be available for emergencies? There's no downside.
Because these are relatively uncommon, they will lead to extra scrutiny and hassle in many situations (buying alcohol, showing ID at airport security, etc).
The US does not have federal level ID cards, although the federal government has used funding for state programs as a cudgel to make states comply with standards for how they verify who you are before issuing you an ID ("Real ID").
Examples of non-driver IDs:
- New York: https://dmv.ny.gov/non-driver-id-card
- Massachusetts: https://www.mass.gov/how-to/apply-for-a-massachusetts-identi...
- District of Columbia: https://dmv.dc.gov/service/non-driver-identification-cards
Thanks for examples.
The downside is again that it's non-standard form of ID, but it is a photo ID and may be useful
ID is required for many things. Off the top of my head I've had to show ID to get into bars or buy alcohol, rent a car, drive, doctor visit, picking up kids at school, R rated movies, at the bank, opening a crypto account, opening a Robinhood account, when I need to prove my identity at work - and probably many other times. You need an ID for many random things in life and somehow that's not exclusionary.
I've just googled to see what percentage of American adults have ID and I saw percentages in the high 90's. Though, these survey results are a bit confused with some surveys excluding expired results or being strictly "driver's licenses" versus any government photo ID or counting people who "don't know" or decline to answer as not having ID.
I haven't voted in a long time, but the last time I did - I think they just asked me what my name is and I didn't show any kind of ID. They then check if the name you gave is on their list of voters. If it is, you get a ballot, and they check that name off the list. If it's not you get a provisional ballot and who knows what happens to that.
All this is to say that the politicians who believe voter ID would reduce their share of the vote consider it exclusionary. Politicians who believe voter ID would increase their share of the vote do not.
This various by region, but the procedure where I live is that you are registered to vote in a district. When you go to vote you provide your name and, if necessary to disambiguate, an address. The poll worker finds you and checks you off. Then you vote. If two people try to use the same registration, this catches that.
> All this is to say that the politicians who believe voter ID would reduce their share of the vote consider it exclusionary. Politicians who believe voter ID would increase their share of the vote do not.
The voter ID debate does concern whose ox is being gored. The party whose constituents are poorer and less mobile is the party whose voting share will go down with voter ID laws, depending on the law, because acquiring the ID allowed by the law may take travel and expense which is prohibitive to their voters. The argument for ID is that it will prevent in-person voter fraud. The argument against it is that the fraud it will prevent is negligible, the number of people it will disenfranchise is not negligible, and that the actual incidents of voter fraud, or election fraud, that should be prevented are not in-person voter fraud.
TLDR; voter ID laws will decrease participation and the laws can be gamed, by choosing acceptable forms of ID and whatnot, to selectively decrease one party or the other's voter base. Also, there is no evidence that this prevents fraudulent votes swaying elections and there is evidence that it has partisan bias, which will sway elections. A solution: issue a federal ID delivered to voters at no expense. This is not on the table.
I don't think accessibility should mean that you have to forgoe aesthetics or compactness for those users that don't need the contrast or extra space or whatever so these don't need to be opposed. Instead, provide options for users that do need them and/or integrate with OS or third-party accessibility tools where possible.
> Why can’t I choose the colors of web sites and applications?
I can choose my applications colors under KDE and pretty much everything "native" (Qt and GTK <= 3 apps) will respect those settings. This seems more of a problem in the proprietary ecosystem where each company wants to insist on their own branding.
For websites there are prefers-contrast [0] and prefers-color-scheme [1] media queries that in theory provide some user configurability but they are a) barely exposed to users b) not implemented by most websites and c) very limited. It would be nice if there was a standard way for CSS to refer to system fonts and colors - then again that would also be yet another privacy leak that WILL be used for tracking :|
> Why can’t I change the default system font for my iPhone or my Mac?
You can in other operating systems. Apple has always been about aesthetics first so this this shouldn't really be suprising - not that that excuses Apple from not providing these configuration options.
> Why can’t I change the font size in modern video games?
This has actually become more common for CRPGs now. I guess most less text-heavy games still don't bother. OTOH most new-ish games scale text with the screen resolution. Older games might have fixed absolute font sizes but if they are old enough they also have a fixed (or limited set of) supported resolutions and you need to scale up the whole thing anyway.
> Why do most desktop applications fall of the edge of the screen below 1080p?
Windows is really bad about having fixed-size dialogs everywhere. This is another of those things I like about Qt-based applications - they have always had flexible layouts unless the developer deliberately breaks that.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref... [1] https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
So - why on EARTH are you publishing there? And for what it's worth, the areas that fail WCAG AA for colour contrast on this page are areas entirely within the control of the publication.
I had this exact thought. Maybe it's just me, but I grow increasingly tired of content published Medium. I'm not really too sure if I can nail down exactly what it is, though. Maybe I am too influenced by Anti-Medium arguments. Idk.
Medium post pages are heavy, load slowly, and have all kinds of unnecessary junk in them. Also, the free article limit authwall is a nuisance.
I also dislike medium and also wonder... Perhaps it's the most low-effort way to blog? Or perhaps medium "is where the eyeballs are"?
> The files currently in this repository are presently considered pre-release, and as such do not have a permanent license attached. In this repositiory, all files present are under a time-barred beta license, and intended for use with web-based content only, and not for any other use without written permission.
The non-pre-release stuff[3] offered to W3C is better but still seems to be intended to end up non-FOSS:
> Files in this repository are licensed to the W3/AGWG under their cooperative agreement for use with WCAG accessibility guidelines for web-based content only, and not for any other use.
Similarly, the online calculators[4,5] referenced in the author’s posts (not this one) are
> PROPRIETARY AND NOT LICENSED FOR THIRD PARTY USE.
(The question being, of course, how much of this is copyrightable at all and to what extent these terms are just sowing legal FUD.)
[1] https://github.com/Myndex/SAPC-APCA/
[2] https://www.myndex.com/CVD/
[3] https://github.com/Myndex/apca-w3/
This is destined as open source. The only reason the public beta has a time limited license is to make it clear that the pre-release materials needs to be discarded once it's stable and in release. BECAUSE this is destined to be part of various standards, it is important to prevent "wrong versions" from circulating (to the degree possible) this has already caused problems, hence the current temporary license.
Any developer that wants a longer term license only needs to request it, so that we can have contact and follow through on changes.
I hope that clarifies the matter.
Sorry, but you don't get to excuse yourself with that. The text/background in your own post is awful, as others have already mentioned. Medium is a notoriously bloated platform, with their ad heavy and JS heavy pages producing a generally poor user experience.
No one is forcing you to use Medium, you could easily use GitHub pages, SubStack, or any number of other, better options. Options that allow you to control your own CSS. By continuing to use Medium, you are saying (basically yelling) that you really don't believe in what you're writing, at least not enough to do anything about it.
Thank you for reading.
I can instantly tell when a designer is using a Mac and never bothered to check how text renders on Windows. In particular with thin fonts a Mac may render it somewhat legible whilst it completely falls apart on Windows.
Nothing is so simple to be just black and white (see what I did there!)
I say this so that other HN users that influence the design of their products don't walk away and start making changes that negatively impact their users.
This has been studies and there is a ton of research. Here are a few with selected excerpts- please read the articles in full!
"white text on black backgrounds creates a visual fuzzing
effect for people with astigmatism called “halation”."
Source: https://www.essentialaccessibility.com/blog/accessibility-fo... "A research study found that “black text on a
white background overstimulates the OFF ganglion
cells while white text on black background
overstimulates the ON ganglion cells.” This finding
means that “white text from a black screen could
inhibit myopia, while black text on white background
may stimulate myopia.” The study advises against
reading black text on a white background due to
the striking effects of contrast polarity."
Source: https://uxmovement.com/content/why-you-should-never-use-pure...A collection of further reading:
https://www.esa.org/communication-engagement/2018/08/03/reso...
The latter link provides some sources, but not much experimental evidence.
The fact the article is currently displayed in dark mode is that medium really messing things up unless you set the page to #fff, which is visually fatiguing.
Your sources cite the useful study concluding that pure black text on a pure white background on a screen causes eye strain for folks like me with astigmatism. The uxmovement site, however, jumps to the conclusion that black text on a white background is the worst configuration and anything else that gets a good WCAG contrast rating is better, and sufficient for readability. That's unsupported, seemingly false, and the topic of this article. Their asserting the grey-on-white text in their graphic is more readable than the black-on-white is patently absurd.
The appropriate way to decrease contrast is by tinting the background but leaving the text towards the extreme. The author argues that the current WCAG method of determining contrast without considering other factors such as leading, tracking, type size, etc. gives passing scores to inaccessible results, and more recent methodologies are much more accurate, especially in dark mode.
This article is part of research I am doing on readability contrast.
Also, "uxmovement" is about the last place to be taking advice on the subject.
Nevertheless, The subject is much more nuanced, but articles like the one you linked lead to misunderstanding.
Spatial frequency is critical, and it is spatial frequency that is the driver of contrast perception for smaller stimuli, particularly for small thin body text, where luminance contrast needs are substantially higher than for large bold headlines.
I said as much in the article.
Grey text = weak design department with damn expensive monitors
Grey background = management dabbles in design questions
Grey text & other-grey background = decision by committee
Any color discussed long enough becomes grey.
When it comes time to install the actual payload, it's presumed / assumed that grey is the text colour, or everyone (designers, reviewers, project owners / managers) are so used to the (non-semantic, incidental) placeholder representation that an unreadable text is simply accepted or presumed as the intent.
There are less charitable interpretations as well.
One fix would be to insist on high-constrast text in all phases of the design process. Yes, it will be visually distracting, but text should be your principle asset and intention.
Though ultimately it would seem that this is in fact starting point to failure itself.
So why are designers resorting to lighter and lighter text? When I asked designers why gray type has become so popular, many pointed me to the Typography Handbook, a reference guide to web design. The handbook warns against too much contrast. It recommends developers build using a very dark gray (#333) instead of pitch black (#000).
The theory espoused by designers is that black text on a white background can strain the eyes. Opting for a softer shade of black text, instead, makes a page more comfortable to read. Adam Schwartz, author of “The Magic of CSS,” reiterates the argument...
https://www.wired.com/2016/10/how-the-web-became-unreadable/
Correlation is not causation.
Possible alternative version of this history: WCAG came out with its recommendations when it did precisely because trends in design at the time were towards using different font weights and colors, as cleartype rendering was becoming universal and displays were moving away from CRT to LCD and becoming higher resolution. (LCD monitor sales only surpassed CRT monitors in 2003. The concept of a 'retina display' dates to 2010.)
In the absence of WCAG contrast guidance, the wild west would have won. Instead, by putting a line in the sand for contrast, WCAG helped ensure that design trend was held in check.
My https://wordsandbuttons.online/ uses default browser colors for anything other than interactive illustrations. For those, I just don't know how to make user choice work with the graphics they show since the graphics is always different from picture to picture, so I impose slightly tinted background as part of the palette.
I don't see your point.
My job for the last decade has been to facilitate accessibility.
Not only have I never heard of this control existing in native Chrome, I can't figure out how to do it. I'm doubtful, then, that we can consider this a remedy of any kind for accessibility issues.
My hunch is that you mean that there are extensions that provide this – which I definitely have issues classing as "browsers providing" much in the way of anything.
Closest thing I can find are custom user stylesheets – which were removed in 2014 (also not sure if "write some CSS" is an a11y solution, heh): https://codereview.chromium.org/66383005/
I do agree the the actual point that the default colors have nothing to do with user preference though.
I don't want forced contrast or font size that's suitable for people with eyesight issues the same way people with eyesight issues don't want my dark theme or zoom level.
Website makers should learn to design for all, but not for everyone at the same time.
Edit—author says so in his article. FWIW I might add that while my terminal emulator and my text editor both use light on dark color schemes, the way to make that work is to reduce contrasts. The most horribly eye straining web sites use incredibly harsh contrasts. I can work for many hours in both apps before getting anywhere near the condition that many 'dark mode' web sites can cause in a minute or so.
I first noticed this with some video games (Maybe Hexan or Quake?) versus Word 2.0; however, back then my monitor had brightness and contrast knobs on the front so it was trivial to switch (IIRC, brightness adjusted black-level, contrast adjusted white-level).
I cringe every time I see someone open a black-on-white document up on a projector. White-on-black is infinitely easier to read in almost all conditions.
"The Mother of All Demos" had dark text on white background. Xerox Star for obvious reasons also had dark text on white background.
Downvote me and see - this comment fades into contrast-obscurity.
Downvoted comments turning grey/on greyer is beyond dumb, adding another UI-bezel on top of the pile of shit that is popular (>51%) opinion echo chamber.
Reddit hides comments via minimizing. Hackernews literally makes it more difficult to read.
anyone else notice the lack of outrage? it's the worst conceivable way of dealing with this.
it has, though, made me think about how contrasting/conterverial/more useful discussion chains get presented, at a UI level, and how that affects further participation.
50/50 chance you get an upvote instead because the buttons are so small and close together on mobile. This is where I really like the Apollo app for Reddit. On it, you swipe left or right on the comment to access actions like reply, upvote, downvote. Similar concept in a lot of mobile mail clients for archiving or deleting.
Not surprising for a product that also in other appearances promotes fast use and quick reaction instead of pondered response.
> I think the original intention was probably to de-emphasize the top text a little, relative to the comments below, so it doesn't come across as so authoritative. But that's just a guess. I agree that it's low-contrast. I'm reluctant to mess with the existing design, but we'll think about it.
I see the reply corresponds to what I would have guessed:
tradition.
useful discussion is the opposite of an echo-chamber circle jerk.
lowering the barrier to dismissing valid criticism does not fit the bill, it does the opposite.
It's either rude or offensive, an obvious bad faith take on its parent comment, or is just plain spam.
It is incredibly rare to see a greyed out comment and think "wow that guy got downvoted just because people disagreed with them", unlike reddit.
I have my custom theme for the 16 terminal colors, as tempus doesn't handle well dark <color>/light <color> contrast with the same <color>, and some terminal applications like to do that... But I'm not fully happy with my custom theme yet, the dark colors are too dark.
That is for eye comfort.
So, yes: we adjust text for maximum contrast (#000 to #FFF) and adjust the light accordingly. This is expected behaviour.
Which, by the way, is also in general energy efficient.
If your screen setting make the black on white / white on black way too intense to the eyes.
Shouldn't people adjust their screen to match their need?
Why on the earth a website lower its own contrast because it expect everyone using a over contrast screen.
It basically make the site unreadable for everyone that has a sane setting.
Unrelated fun idea for hardware engineers: develop a GPU that outputs average image brightness before each scanout. This allows the monitor (or GPU itself, though you'd suffer quantization issues) to slowly ramp during dark-to-bright transitions. Consumers would love the feature: people like to stare at devices in dark rooms (bed etc) but melt their eyeballs every time they navigate from a dark page to a light one. This would prevent that pain.
I think that is why hdr invented at first place. Sdr is never meant to present "sun casting on you directly". The sdr #fff in hdr setting is called "paper white". Looking at paper shouldn't hurt your eye in reality and nor does on screen.
Fortunately, they changed it to some sane color.
https://userstyles.org/style_screenshots/199552_after.png?r=...
I used to make user style just to make it readable. The top right is the original color of GitHub dark theme, and left bottom is the one I modified.
Someone set the color must forget how srgb works. #808080 is not half of the light level. It's about 1/3.
Pure black text is not needed everywhere. Make sure to keep the contrast levels nice and high, but experiment with low brightness grays and they may work better than pure black given in certain situations.
Also find it ridiculous they published their screed on Medium, one of the most text unfriendly websites around.
The US Digital Web Design System has one of the best, easy to understand discussions of color and contrast and I always share it with as many designers as I can: https://designsystem.digital.gov/design-tokens/color/overvie...
Color and accessibility are closely linked and I wish more people would be far more practical and less fashionable about it.
javascript:(function(){var%20i,x;for(i=0;x=document.getElementsByTagName("*")[i];++i)x.style.color="#000000";})(); javascript:document.querySelectorAll("*").forEach((x)=>{x.style.color="#000"})Tbh, I dislike web programming and anything close to DOM, I'm more of a backend and embedded kind of guy. I haven't had success in making a similar one that removes "overflow: hidden" from all elements. That in combo with removing anything with fixed position is a quick and dirty way of bypassing GDPR pop-ups.
Say you come to a new site, eg via a HN link. Boom, I have to indicate my stance towards tracking and ads by rejecting all cookies, and objecting to "legitimate" interests. That takes time, so instead I have a bookmarklet that removes anything with position:fixed (the gdpr pop-up). The second piece would be re-enabling scroll by disabling the "overflow: hidden". I do this manually now by inspecting.
Can highly recommend greasemonkey for automating the process. Once it's in place it makes the web so much nicer.
As an author, I prefer not to define colours and fonts at all, except to specify which text must be displayed using fix pitch fonts. The end user can specify their own colours and fonts.
Most don't though, unless your audience is technical.
I use it for this on my e-ink device. The results aren't always optimal (site graphics and navigation are often mangled), but the main body text is at least readable.
> Rendering mode[s]: Inverted ; Grayscale ; Inverted grayscale ; Increase contrast
Oh, and this is an Android app (available via F-Droid to boot).
I've already got ... three web browsers installed (not including w3m and others under Termux). The thought that there's a need for yet more browsers just to read the fucking text seems ... sad?
Would you happen to know of screenshots / videos demoing features?
That said, thanks. It is another option.
Well, if you are using browsers on EPD, one of the first points in the wishlist (or, "requirements unless desperate") is to have a high-contrast option.
https://github.com/plateaukao/browser
High-contrast, paginated nav, minimum animation, save-to-ePub (see my recent comments here), font scaling, adblocking, and more.
Though Dark Reader can be tuned to give high-contrast light-background themes.
The extension itself has a dark-mode formatting which cannot be changed, however.
The pages are gray with black text on it. at nearly 1000 pages, it is exhausting to the eyes.
But yes this light grey on white (often using thin fonts) causes me to immediately leave. Modern design is most often about creating some crap with zero idea about the ergonomics.
There is no strict need to leave: you view client-side material and there exist tricks to modify page styles.
( body > div#root > div.a.b.c > div.l.ev )What about people using someone else's computer and hence having no control about changing such settings (public computer, pair programming)?
It makes sense to make stuff accessible by default.
The author, bound as you may know to the choice of the publisher, advocated for readability so that people could be encouraged to arrive at least to the actual first paragraph of text.
> And before we continue, let’s make it absolutely clear that we have no control of the color of the text in this very article, as it is hosted through Medium.com, which features poor visual accessibility of their site design.
When viewed through the TangledWeb publication,we have set it to a dark mode, which is probably the best contrast possible per how Medium is configured.
By hosting the article at Medium.com, despite their objections to how Medium.com constrains the article's appearance, the author is demonstrating that they don't consider their own argument particularly persuasive.
The authors do have control, but apparently their own point isn't important enough to change their medium (no pun intended).
If I chuck your vase at a wall, I don't get to blame the inevitability of inertia for the resulting mess.
Further, Medium prevents their users from selecting black text as a choice. While Medium’s “Fischer-Price-simple” content creation is easy to use, it is also extremely limited, and fails in accessibility in areas beyond color. Perhaps this article can serve as a wake up call regarding this issue.
But it is funny that the article uses grey text itself for the headline paragraph:
.fc {
color: rgba(201, 184, 211, 1);
}Highly misleading, among others because of reasons explained in the medium article under discussion.
https://scribe.rip/please-stop-using-grey-text-3d3e71acfca8?...
(Or your browser's Reader Mode, if available.)
Secondly: as someone who's switched almost wholly to e-ink for online reading[1], the greyed-out text, or worse still, grey-on-grey experience is all the more aggrevating.[2]
Fortunately for me, reading on my BOOX with Firefox, reader mode addresses the colour and font-face issues. Leaving me with a remaining third problem: scrolling.
Touch-based scrolling through a document on mobile devices is itself a horrendous experience, and e-ink's latency makes this worse.
At the highest display quality, scrolling causes the display to "shatter" into a sandstorm of pixels until movement is stopped. Given the nondeterministic nature of scrolling, trying to pick up where the original end-point of text was, and continue reading is ... difficult at best. Reducing image quality at least gets rid of the sandstorm effect (at a cost of display quality and increased ghosting), but scrolling remains uneven.
An alternate browser, Einkbro, which has numerous e-ink optimisations, features pagninated navigation. Specific zones of the screen (my preference is lower right & left for next/previous) will navigate by (nearly) a full page, deterministically (I leave about a 10% overlap for continuity). It's still not as good as a fully-paginated document, as with PDF-based e-books, but it's worlds better than scrolling.
I've been noticing how annoying online reading is for many reasons (ads, sidebar clutter, animations, and more), and was beginning to wonder if that was intrinsic to me or my device itself. Re-reading a 500 page novel this past week, on the device, I realised that no, it's mostly Web design / Web browser / Android interactions themselves, and that e-books are a vastly superior long-form format.
Even tools such as Pocket which offer a "page flip" mode turn out to be a horrendous UI/UX in comparison:
- The flipping is gesture, not region based.
- Application features such as highlighting and tagging are not available in page-flip mode. It's necessary to scroll slightly to expose these.
- Pagination is not fixed for the document, but is arbitrary depending on your position within the document when you initiated flip mode.
Consequence: I rarely use Pocket for reading. Einkbro has one further trick up its sleeve, however: "save as ePub".
Yes, you can save as PDF, which should be familiar from other browsers. As with these, the result is a statically-formatted document with fonts poorly-selected for static reading, page-clutter from the online experience, lines cut off between pages and running into both side and vertical margins and gutters, and a pile of increasingly-difficult-to-navigate single documents.
Save-as-ePub:[6]
- Largely succeeds in stripping out all non-main-body text from the article.
- Standardises fonts to your ePub defaults.
- Formats vertical and side margins. (I'd prefer these could be made larger, that's actually the fault of my e-book reader.)
- Permits annotations of the document directly: highlighting, bookmarking, and both typed and handwritten annotations.
- The kicker: Compiling multiple Web articles into a single ePub book. This might be a set of articles on a specific topic, on a date (or date range), material for a project, to be sent to a colleague, friend, or family member, etc.
There are limitations , but it is transformational and uncannily brilliant. It also highlights that a tremendous problem with the Web is its very Webbyness.
Einkbro has several other highly-useful features:
- Font scaling ON THE MAIN TOOLBAR ITSELF. Not buried four levels deep within menus as in Firefox, or entirely nonexistant as with Chrome.
- A "White Background" toggle, which mostly works. - A good "Reader Mode" feature, though IMO inferior to Firefox's. I'm often caught between Firefox's better reader mode and Einkbro's better navigation, at which point save-to-ePub is usually the best alternative.
- Various interface quirks which have my relying on Firefox more for content discovery (often through HN), and Einkbro for long-form reading.
But it's an excellent browser and if you're on an e-ink device, or even a tablet, I strongly recommend it.
But yeah, the further I can get from a site's own design and styling, in general, the better.
________________________________
Notes:
1. Exception: when I'm commenting on specific sites and services, as one of my accomodations is to not have any account-based services on my e-ink reader, so yes, this is being typed on a colourised & emissive older tablet.
2. "Night mode" defaults are also exceptionally bad. TFA's choice of an exceedingly grapey-purple background renders as grey-on-black, which ... is pretty bad itself. Worse still are colour combinations of similar luminosity (say, red-green or red-blue) in which all distinction between text and background is lost. Even my own take on the "Motherfucking Website" motif, which tends to render well on most colour-emissive devices, is suboptimal on e-ink. I should add a @media query based on available colour depth and toggle colours to maximal contrast for e-ink. https://codepen.io/dredmorbius/full/KpMqqB
3. Fonts matter. A lot. At 220 dpi, i much prefer serif to sans.
4. There are many other reasons for this, mind, I'm just referring to the navigation / interaction aspects. My years' old gripe list remains largely current, though there's been some small progress: https://old.reddit.com/r/dredmorbius/comments/5x2sfx/pocket_...
5. Expanded at length here: https://toot.cat/@dredmorbius/107958709435468728
6. I've had a lengthy GitHub discussion with the developer: https://github.com/plateaukao/browser/issues/107
We should have a HN guideline to add (Medium) to the title when the URL itself obfuscates that fact.
Anyway, I agree with the article. I find myself resorting to reader mode more and more these days partly due to crummy web fonts, partly due to janky JS and bloat, and partly due to unreadable color combinations.
Are there any effective browser extensions to intelligently prevent things like a "Subscribe to our newsletter" popover?
I'm trying to think how i could tell uBlock origin to intercept any element with a high z-index which has it's ".display" attribute changed only in response to a timer or a scroll event.
In firefox i have the "I don't care about cookies" plugin and i genuinely forget that noise exists on the web until i use another browser and it all comes flooding back. I'm hoping there's something similar for this endemic cruft the web has been filled with.
Reader mode can be useful. NoScript can be useful but can also be painful.
https://www.no-thanks-extension.com/
I haven't personally tried it yet, but I'm tempted.
There's also a gap of websites that are big enough to have this corporativist behavior of putting annoying... objects in their webpages, but not big enough that enough people visit to the point where it's likely that one of them will write the script.
Especially because, like, I do write some stuff for userstyles and userscripts sometimes, but I won't publish them unless I think they'll be useful for at least a small group of people, which I never seem to think will happen for websites in my mother tongue for some reason.
- Globally blacklist malicious JS (and other features) within uMatrix.
- uBlock Origin's "Annoyances" filter is highly effective.
- UBO's element remover tool is also quite good, and permanently removes misfeatures.
For added leverage, on desktop, I use Stylish to write custom CSS rules that assign annoyances the CSS property "display: none !important". This is typically on a site-by-site basis, though there may be some common targets that can be addressed either globally or with a standard stylesheet applied to multiple sites.
All of which is a pain, agreed, but less of one than not doing so.
I used to dive into the console and start removing stuff and even went so far as to write a bookmarklet that tries to identify and nuke anything with fixed position and reset the height to auto on body/html but ... if someone's going to be that user hostile it's not worth my time.
When this happens I'll copy the url, close the tab and paste it into archive.is.
It's a one click removal. It's nice because I dont have to search for the nearly transparent x or tiny no thanks, I can just muscle memory to the same button in the toolbar of my browser every time.
Note that it does not include custom domains or image uploading on the free plan, but you can upgrade for $29 (lifetime), which gets you:
Custom domains (this is time-consuming)
Image uploading (due to the cost of hosting images)
Email subscriber lists (since it gets complicated)
Beta features (since they aren't ready yet)
You can upgrade for $29, flat.
The editing interface is just a textbox where you paste markdown; doesn't seem there's a github integration or anything like that, which is too bad.I stopped when I posted an article, and Medium decided it was so good, that it deserved a paywall.
100% agree !
https://scribe.rip/please-stop-using-grey-text-3d3e71acfca8?...
It's similar in spirit to Invidious, Nitter, Teddit, and Bibliogram.
It doesn't just save people the technical effort of making a blog, but people think that it saves them the marketing effort -- which is a lot more effort.
> And before we continue, let’s make it absolutely clear that we have no control of the color of the text in this very article, as it is hosted through Medium.com, which features poor visual accessibility of their site design.
Why do they do that? They even have their own domain, they can get a domain but they can't host text themselves and choose their own colors?
Medium unfortunately simply doesn't work on my phone. It shows the first paragraph of text, then just nothing, no button to expand text or anything either. Some bug, they can't even render a textual article even though browsers could do that in 1993.
Sure, fine, whatever, The Web Is Worse Than It Used To Be. I wish every text-driven website (news, blogs, etc) rendered with zero jank and zero JS required. But Medium really isn't much worse here than everyone else. Their pages are more cluttered than they used to be, which sucks, but they're clearly just victims of the same forces driving all other commercial websites to do the same things.
Long body text should have sufficient contrast and good typography. Using only maximum contrast for all text "just because it worked for books" is bad advice. Not only was there not really a choice when it came to books, also books reflect natural light instead of emitting light. This is fundamentally different and needs to be taken into consideration when designing.
The web does offer incredible flexibility for improving information transmission with _good_ design. Establishing visual hierarchies, guiding the eye and emphasizing things, just to name a few. Just look at your code without syntax highlighting. The issue is - as with most things - that there is a mix of bad taste, carelessness and lack of education going on. Just like the design of this article.
But do not forget that there are other technologies around: EPD, OLED do not quite overlap with that general idea. And both call for maximum contrast (EPD to reach a decent threshold for contrast, OLED to get a completely mute background on one pole and to be energy efficient on the other). Edit: I forgot "projectors" (there where the issue of contrast is nightmare).
> maximum contrast ... Not only was there not really a choice when it came to books
Not really. Try reading a printed book with non-black text. Your "eyes" should tell you it's "not good".
:) I assumed that the context was that of focused-reading material, long text. Even the movement at https://www.contrastrebellion.com/ does not use B/W everywhere... I assumed that we were discussing a context where «legibility really is the primary concern».
For an aside, a title etc., function prevails - it works in a context; optimal readability: "for the time I will spend on it"...
But the web is full of articles - long text - set as grey on grey.
This alone almost made me stop reading the article. What worked for printed text has no bearing for what works on an illuminated screen.
But honestly, it's not grey text that's the problem. I agree with the author that maintaining high contrast is important, but it is equally important that things aren't too bright. You should avoid using extremes like #000000 and #ffffff unless you're really trying to make something highlight.
#0f0f0f or even #202020 doesn't make an appreciable difference, at least to my eyes. Believe me, as a 50+ year old, I notice when it's hard to read things.
> On a light or white background, body text should be black. In many cases it is more appropriate to reduce contrast by darkening the background. As an example a white #FFF background is really too bright for comfortable reading, a background such as #e8e2dd provides a less fatiguing background.
Sorry if I come across blunt but if you're going to be critical about an article then at least read more than the sub-heading first.
Second, accusing posters of not reading articles is against the Hacker News guidelines.
Third, I bring all this up because the vitriol of your comment is no fun to read and brings down the site.
At no point were they making any of the suggestions the GP are criticising them for.
(Whether they rage quit or "merely said they almost did" is same difference).
Paper can be very white and bright if well lit. Much more than a typical LED/LCD screen. If your screen is brighter than a white sheet of paper, it's probably too bright and you are probably tiring your eyes.
The only moment when a sheet of paper is darker than my screen is when I'm in my bed, in a completely dark room watching or reading something, and that's not known as a very good thing to do for the eyes (and for the body posture neither by the way).
I'm not buying the fact we should darken the background of a text. I think we should let people reduce the brightness of their screen instead.
There is such a thing as too much contrast. Typical ergonomic workspace regulations (like the ASR in Germany for example) will tell you how much contrast any given type of workspace environment should have between the brightest and the darkest point for a reason.
Now someone with an old, washed out TFT might get a much different contrast when viewing a #000 #FFF page of text than someone with a modern HDR display if this is not accounted for in software. Now you could say they need to adjust their screen – but text is not the only thing people view on screens. Why would you throw away image and color fidelity, because some website doesn't fit that setup? We are on computers, why not just support different contrast levels like we do with dark mode?
--- ¹ except maybe black holes
I should have mentioned that I was thinking of a sheet of paper in the same room / with the same lightning, next to the screen we are speaking about. Otherwise, yes, indeed.
> why not just support different contrast levels
So what I understand from this is that we can't get this right (in HTML/CSS) for now because we don't have details about the environment of the user wrt lighting/contrast (preferences/perception).
It seems like something that should be fixed at the browser or the OS level. One should be able to say: "this is some black text on white background that needs to be displayed so as to be comfortable for the user given their environment" (or something). Maybe that needs to be the default by the way.
Until then, any forced value is going to suck for someone.
Advanced configuration could allow you to tune the curve continuously (or in a sufficient number of discreet steps that it seems to be continuous).
I think I noticed my Android phone at least doing a "I'll remember a relative brightness you want for this much light outside", though I haven't checked if it's really that.
Adapting to the ambient light and reading on paper which is never more than 90% DIFFUSE reflectance (typically 80% for paperbacks, and 70% for newspaper) is not at all like having polarized light beamed straight into your ocular medium to collide with your retina at well over 100% of the ambient adaptation level. Or words to that effect.
> _There is such a thing as too much contrast._
Yes, there is absolutely such a thing as too much contrast, however, I hesitate to say this as it is so often misunderstood—spatial frequency is the key factor to determine first. The contrast needed for small thin body text is very different than that needed for a large bold headline.
The thing that some find confusing is thinking that too much contrast with a light background means making the small thin text lighter grey, when in fact the text should stay darker tha #303030, and lower the luminance of the background to #e6e2dd. I say as much in the article.
In general, nothing useful ever came after an "I've stopped reading at" disclaimer.
The # of articles that I personally haven't commented on because I found them impossible to read them to the end is probably in tens of thousands.
That's in fact how I come to the conclusion that nothing good ever comes after reading it :-)
So IMO, both of you are contributing constructively here.
If it's too much contrast for you, maybe your screen is not setup correctly (too bright), or you don't zoom enough. Or your room is not correctly lit. Black on white should be comfortable.
Don't force me to squint or to use way too much brightness sucking too much power to compensate for poor contrast.
People are fine with office suites despite (thanks to?) them defaulting to black on white. We would have known by the time it if was an issue.
I guess the real problem is that there's no real standard for what #fff means – it has to be interpreted through a colour space, which in turn does not talk about brightness, I think.
Done properly, moving away from #fff/#000 can be done in such a way that it looks excellent on better monitors and is usable, at very least not entirely unpleasant to read, on less capable ones.
> I will have a harder time reading your site
It not looking as nice for you is fine, as long as it is readable. If we held everything back to making sure it worked on all screens there would be a lot more plain-text-only sites/apps out there. A perfectly good option IMO, but try getting the general screen using public to agree with that!
Even with a bad screen there are usually adjustments you can make to help.
There are of course many pages out there that are too low contrast, or otherwise unpleasant, unless you are using a particularly good monitor setup a particular way for which…
> or just give up and go somewhere else.
… is a perfectly valid option. You don't owe them your attention, though likewise they generally don't owe you anything either.
You would wear out the brightness controls in no time unless you go out of your way to mandate dark mode on everything.
Another factor might be the dark adaptation of the iris, which could be helped by desk lights.
(Brightness is the adjustment that decreases the max white level without also making blacks brighter. So, a display that only has a contrast knob would count as missing a brightness adjustment.)
Even if the ratio stays the same, the darker shades suddenly are a lot more distinct as they just aren't consumed by artifacts and color shifts or even just glare anymore.
Just because your screen is configured badly doesn’t mean we should make content unreadable for users with correctly calibrated screens.
My screen is fine, probably as good as or better than what most people have. We can't optimize for the almost 0% of people who have calibrated screens to the detriment of the big majority of people.
Those norms also set a limit for the maximum amount of contrast allowed at a workspace, which #000000 on #ffffff violates if it’s shown on a color-calibrated screen with standard brightness.
> We can't optimize for the almost 0% of people who have calibrated screens to the detriment of the big majority of people.
We can’t just change the meaning of what definitions and terms mean just because it’s easier than making everyone follow the standard.
Create a color profile for your monitor, so your OS can compress contrast if your monitor isn’t powerful enough to reach the SDR sRGB specs.
https://www.iso.org/standard/57992.html
> that will ensure effective and comfortable viewing conditions for users with normal or adjusted-to-normal eyesight
Sounds like it did not do so for you, in the case of non-compliant websites with your compliant display.
I can't be bothered for my personal blog. $158 is my hosting cost for 3 years or so.
Still, any standard prescribing "standard brightness" for office environments is bound to be nothing but a decent average or default. Even if there was biologically optimal display luminance, it would still depend on the environment lightning (which changes during the day if there's a single window in the room), and on the state of the viewers eyes (age, any visual problems or even temporary issues like tiredness), type of display...
The purpose of a standard isn't to be most preferred by any given person or "biologically optimal", it's to be...standard. Without a standard, a designer has no ability to pick a particular color and expect anything like that color to be what the end user sees. Without a standard, there's almost no point in discussing what text colors websites are or aren't using.
The GP was talking about using whatever "DIN norms for workspaces" regarding screen brightness are, so I don't see how that relates to colour calibration.
You also sound as if any one end user really cares if they are looking at exactly the right hue of blue when looking at the "hp" logo. If anything, the company and their marketing department care (for subliminal messaging?), but users really don't. I don't think anyone could pick a McDonald's red or yellow out of a given table of similar red/yellow hues.
But even so, if we were looking at any non-light-emitting content displaying colour (eg. a printout), it will look differently to your eye whether you are looking at it in dim light or in a very light setting, so designer can't do anything about that.
Anyone who knows even the most basic stuff about colour perception understands that it can't be decoupled from your environment (enter a darkroom and every colour is suddenly... black).
Colour calibration and standards are done so that you can guarantee that some things will look identical when displayed in exactly the same environment (so your two screens sitting next to each other show the same hues) or to reproducibly transfer between different mediums (eg. screen and paper), but there is no way you can guarantee that it will look identical for another user in a different environment.
Colour calibration is of limited use in general (eg. even different types of paper [think glossy vs matte] will produce different visual results), and while there's more stability with light-emitting mediums (like LCD screens) — because you, essentially, control some of the lightning as well — that breaks down for the average user because they do need to adjust the brightness according to their environment. Those who absolutely require reproducibility, control both their environment and their equipment.
I'm sure people with calibrated screens can find a setting where black on white is comfortable, even temporarily, while most people just can't fix contrast lowered at the source. Including not visually impaired people in not ideal environments.
But the same issues apply in reverse if you try to reduce contrast because some idiot thought a 200:1 contrast for text was healthy.
My personal solution is relatively simple: I replace every monitor that’s too shitty to do sRGB at good contrast at 400 nits. For a T470/T480 I can recommend this panel: https://www.xelent-store.de/Innolux-N140HCG-GQ2-400cd-Low-Po...
This seems highly unlikely if your brightness isn't completely off. What cd/m2 are you at? I'm on a Eizo CG277 with built-in hardware self calibration. It's set to 120 cd/m2 and I have hard time thinking it could be painful to anyone. I much prefer #000 on #fff over lower contrast alternatives.
At the same time, #000000 may not be above 2 cd/m² at the absolute most if a pure black and a pure white pixel are shown right next to each other.
"Screen configuration" means more things. You can optimize for readability, or you can optimize for faithfulness (and more). You should switch according to use.
Just like I've got to have filters that force websites not to use too contrasty colors.
I might add that office-type programs were developed at a time where 14 to 18 inch color CRTs were the latest and greatest. The image that modern flat screens deliver is much more dynamic and has way sharper edges, to the degree that maybe we should consider to artificially blur the entire display ever so slightly just so the higher Fourier frequencies get a bit less dominant.
Until we get HDR on the web, one sRGB size must fit all. At this point, accessibility and readability are top priority. You can always tone down your backlight, while someone else might have it at full blast and still not be able to read without squinting in the sunlight on a cheap display. I know who I'm more sympathetic to.
As I’ve said countless times before, we’ve got OS support for tonemapping HDR content onto SDR displays, now we need OS support for tonemapping SDR content onto shitty displays.
I don't need accurate colors when reading text, but I need it to be comfortable. It seems having color calibration would actually suck for me if I can't adjust brightness depending on the weather, on the hour of the day, on the season, on whether I'm tired or not, or on the location I currently am, or on what I'm doing (reading, programming, or watching a video). I need to be able to adjust brightness without fuss.
I guess I would buy dedicated hardware and put it in a well lit-controlled room if I needed accurate colors.
I want accurate colors because setting it up is a pain, and switching between accurate and inaccurate colors takes your eyes quite a while to readjust.
It’s much easier to just have everything in an accurate color mode and have content designed for that than to switch it around.
Proper color profiles are actually even more of a benefit for cheap displays than good displays as cheap displays profit from proper colors even more.
The issue with color on screens is a bit like the loudness wars in audio mixing: everybody tries to use the available bitspace to the max, because this made some sense in the days of 16 bit (or lower) audio. Nowadays much more dynamic delivery would be possible (with dynamic reduction as a user preference), yet there is no real, well designed system for such things in place.
Maybe that's to compensate for low contrast content?
In addition, the paper it’s on is almost never pure white. And, as a reflective medium, the perceived colors of paper and ink vary with ambient lighting.
So in digital: should one create sufficient contrast to read? Yes, definitely do that. Stay well inside accessibility guidelines.
But a site absolutely does not need pure black text on white background to do that. And in fact at high screen brightness, that level of contrast risks creating little bits of ghost text in some people’s vision.
Similarly, it cannot boil water or charge my house's solar batteries if I display an all #fff screen.
(If it could do these things, then I'd argue for clamping contrast in the display driver, not in untrusted CSS code!)
Even in the realm of thermodynamically plausible displays, if it is so bright it's burning stuff into your retina, then turn the brightness down before you permanently have an xkcd burnt on to your retina!
Also, I'm reasonably certain such a monitor would fail safety certifications, so maybe don't buy black / gray market hardware, then ruin it for the rest of us?
That's why your display has a brightness control.
At least as long as we're stuck with implicit sRGB, until the web gets proper HDR support, don't murder the contrast of text. You never know the actual viewing conditions (probably less ideal than a well-lit office), and it's foolish to limit it at the source.
https://www.sunvisiondisplay.com/reflective-lcd-monitor https://news.ycombinator.com/item?id=31203809 https://www.youtube.com/watch?v=Ehqj0W3koP0
That's controllable at the screen end.
Even if people use off-white background on webpages, you'd still get white screen real estate in UIs and other places (default Word and Excel background, for one. textarea boxes for another).
I would have no issue with sticking #000 on #FFF, except for the fact not everyone has e-ink displays and it's like shining an LED torch in everyone's faces. If it's inverted to #FFF on #000 this is pretty much solved - but this is a hard sell for most product teams.
The ideal situation is where people can change stuff to what works for them, which is why I use the Dark Reader extension. It's the best extension in that it not only lets you easily change brightness and contrast, light/dark, but, most of all, has a crowdsourced file that carries special settings for each website over which elements should be inverted, which elements shouldn't, or whether there's an element that shouldn't be touched at all, for instance.
I have used such extensions in the past (and even welcomed stuff like Chrome's automatic dark mode) but unless they come with perfect AI—which they don't—they're not gonna match Dark Reader's crowdsourcing.
Not clear. We always normally printed in K - insaturated black. Or, "typographic black", or "sufficiently black black", or "just black". «[A]ctually black» requires a definition.
Yes it does.
> ... but it is equally important that things aren't too bright. You should avoid using extremes like #000000 and #ffffff ...
No, you shouldn't avoid them. Users are fully capable of adjusting the brightness and contrast of their monitors.
> Believe me, as a 50+ year old, I notice when it's hard to read things.
I believe you. I just don't think your personal experience is relevant.
It'd be a hack. The buttons are not sturdy enough for it, they're even not designed for it and the colour representation will be very incorrect.
Instead of asking every website to blast every user with the highest amount of contrast, modify your own display to do so if your eyes need it. That way the need and the solution is localized to where it should be.
I find this hard to believe because in both cases what we actually perceive patterns in the light that enters our eyes. It would seem to follow that only aspects of the reading surface that cause difference in the light patterns (color, intensity, phase, coherence) and the time evolution of those patterns can affect matter when it comes to how well something works for reading.
If we determine, whether from printed text on paper, inked text in tattoos, skywriting in smoke, or anything else that certain relationships that some kinds or combinations of the aforementioned aspects of light matter or don't matter, that should remain true when we are reading from screens or from any other existing or yet to be developed form of reading device.
A monitor can easily be adjusted so that the contrast between #000 and #fff isn't too much. In fact, most displays have a setting named "contrast" just for that, but what actually makes things too bright is the "brightness" one, that is usually more prominent. People will have opinions all over the place about it, because they do get results all over the place.
Instead, yes, you should avoid using the extrema. But that's because if you use them in a normal situation, you won't have any more extreme values when you need them in a special situation. People should be able to change the color schema anyway, so you are better with a functional choice.
This alone almost made me stop reading the answer.
This people is talking about accessibility. So, the more contrast, the better. You want to "highlight" something? Bold uses thicker fonts, underline adds also more pixels. You can add a carefully selected background, like a medium gray or other light color.
But black on white it not to highlight. Is to make it readable. To anyone.
On the contrary, I highly recommend that for light backgrounds the, background directly under body text be something like #e6e2dd. I explain this in the article.
I'm actually kind of annoyed at prefers-color-scheme, and the inability to control it as a user in my browser.
I have my Windows set to dark mode because I prefer how Explorer and the rest of the Windows UI looks in dark mode, and I want my OS chrome to be less distracting and to just "fade away". However, all web browsers see this as a signal to tell every website I would prefer them to be in dark mode also, which is not correct! I wish I could set chrome itself to prefers-color-scheme: light (without having to use the dev tools on every website).
The trouble is that `prefers-color-scheme` is set at browser or system level. In order for a website to use a different colour-scheme, then they need to add functionality with Javascript in order to be able to load different styling at user request.
I wish there were some URL-based rules you could set in the browser settings (I expect there are addons to do this, haven't looked though!).
I don't really care that I'm probably in the minority of users who think or care about this. It doesn't make how I feel any less valid.
are there better extensions for providing styles that apply to every website than stylus?
- match the Firefox theme
- match the system theme
- force light
- force dark
Though, maybe that only does the reverse of what you're looking for.
Perhaps it's because it's more readable, not less, and you realize that the site is not worth your time faster :)
That being said I think most if not all browsers will always answer true to one of those.
Unfortunately firefox with enhanced tracking protection claims that the user WANTS a light theme instead of indicating no preference - yes, the spec has no no-preference but a) this means the spec is broken because there is no equivalent setting to not implementing the spec and b) web specs are defined by browser vendors and Firefox used to have a no-preference value for this. In general, desktop browsers will also often indicate prefer-color-scheme: light if the user has not actually made an active choice - either as a default in the browser or based on the default system theme. This unfortunately makes prefer-color-scheme: light not actually carry any useful information so there is currently no way to have a dark theme by default but provide a light thome for those users that actually want it (you can only do the reverse).
sigh
I absolutely hate light text on dark background. There are a few sites I'd really like to follow (hello hackaday), but their insistence on light text on dark background makes them a pain to read. And it kind of feels like the website says "because fuck you".
There is no shortage of "helpful" people who suggest I use all manner of browser plugins to "fix" poor design choices. Eh, no. That is not a solution. If people want to be oddball and weird they can do whatever they want, but I won't be spending much time on their websites.
I use a relatively dark blue/green background in VS Code, with light, low saturation yellowish base color for the code. Before VS Code I used the same dark color scheme for 25+ years in Emacs. But this is for editing code where I have a bunch of colors that have a semantic job to do. The colors are a bit easier to identify precisely against a darker background. And I don't actually read code per se - I scan and orient by shape (formatting) most of the time. So editing code is very distinct from reading.
For prose/text I find it tiring to have a dark background. Not least because people get the contrast wrong because they don't know that it is different for dark backgrounds. And from an aesthetic point of view it strikes me as a bit ... well, demonstrative and perhaps childish. I'm sure this impression isn't shared by everyone, but that's the feeling i get.
And then there's what you can make work on the web.
(Interesting observation: I'm a big fan of what Erik Spiekermann says about typography - yet both the book he wrote for Adobe ("Stop Stealing Sheep & Find Out How Type Works") and a book about him ("Hello, I am Erik") have horribly annoying typesetting. One has horribly ugly guillemets that look like someone has taken a metal file to the type, the other has type in white-on-pink, which ought to qualify for a severe paddlin'. Is there a rule that whenever someone tries to write something about typography, things go wrong? :-).
One possible explanation might be in one of Spiekermann's writings (can't remember where), where he emphasizes that "good tyography" isn't always the best choice because what people are used to plays a really big role. So a poor type can in some circumstances be better than a well designed type, simply because people are more familiar with it, so they'll have less trouble reading text typeset in the bad, but familiar, type)
“No, the way medium's designers set things up, the text color follows the background color. The user (me) has no way of controlling that.
The page was set lower than FFF because FFF is also much too bright. In light mode, Page luminance needs to be around 80 to no more than 90.
I've been experimenting to see if there is a way to improve Medium's poor, inaccessible design choices.
Unfortunately, attempting to use web inspector while in design mode, they crash the browser, so you have to publish each iteration to then go and inspect how the text colors end up.
And it's actually worse than I imaginged. Medium actually makes the text worse when you choose a color other than FFF. As as I stated, FFF is much too bright.
Ultimately, I think I am going to leave it in a dark mode, until I move my articles to a better site.”
That's rich: he lambasts people for poor typography and then blames the poor typography of his own blog on someone else. As if he had no choice in the matter. Like using a different blog platform. Or setting up his own website.
> And before we continue, let’s make it absolutely clear that we have no control of the color of the text in this very article, as it is hosted through Medium.com, ...
Edit: typo
I've used Medium to post, and it sure allows one no to use white on purple.
In fact, Medium's default, even if not 100% black, is more legible than his choice.
> When viewed through the TangledWeb publication, we have set it to a dark mode, which is probably the best contrast possible per how Medium is configured.
I have never used Medium, so I can't comment in this regard.
If legibility was important to this author, they could have done the bare minimum to improve the legibility on their own site. The bare minimum was to not change the default theme. A bit above that but more honest to their claim: host somewhere else and use a darker grey.
Maybe true, but this is the first Medium page I've seen with this bizarre color scheme and I hit perhaps 50-60 Medium articles a week in my work. So it's certainly something to do with the theming of his site.
Open the website and the first thing I see is dark background and grey-light text. Close the website. The website doesn't stand for the claims.
> And before we continue, let’s make it absolutely clear that we have no control of the color of the text in this very article, as it is hosted through Medium.com, which features poor visual accessibility of their site design.
I stopped after that example..
Black on white (without any tooling to soften or to check ambient light) is hard on the eyes. It’s like looking in the sun while reading something.
Terminals with CRT monitors were also using 50% white on something that looked like black, but was actually gray
But that is an implicit requirement, part of the setup...
> For over 1000 years black text on white paper has been the best practice for printed texts worldwide
No it hasn't.. It's gray on yellow
Later the article reads: > Join the Readability Revolution. Ideally make your text no less than 16 px, and 18 px or larger is preferred
No thank you. I'm on a hidpi/retina screen.
The article also tells us that body text should be black black. If he knew aboutvanta black, it'd probably be vantablack.
It's wrong. I'd advise the writer to do some DTP/Print/Prepress work.
But of course, all "black", "white", "gray", "yellow" etc are fuzzy concepts in nature. And in nature, the quality of the medium and of the environment dominate in the visual effect.
On a display, "black" and "white" are abstract - maximum and minimum. They are a shard of the final effect, that passes through other parameters of the medium and of the environment (especially, "how much light here and there and directed where").
Insisting on comparing "colour on display" vs "colour on book" is strongly misleading in this context.