8 ms·

I got curious and looked back in archive.org to this page's initial release in 2014. The text background started out as good old reliable background-color: #EEE

I got curious and looked back in archive.org to this page's initial release in 2014. The text background started out as good old reliable background-color: #EEEEEE, which was later replaced with background: url("http://a.yu8.us/bg-tile-parch.gif http://a.yu8.us/bg-tile-parch.gif") ...because what could possibly go wrong? From the latest comment at the end of the page, the author would like you to know that the outcome is your problem, because you're using the wrong browser: June 20, 2021 - 15:02 Subject: RE: Undoing whatever is hiding this page. Hi Allen, try a different browser. There's no strange shading on the page, your browser is deciding to display it in a weird way. Regards, -Rex

rentnorove 5y ago
It's definitely nothing to do with the following string in the response: > Page copy protected against web site content infringement by Copyscape
extra88 5y ago
Yes, they web author made the mistake of defining the <article> background-color: #EEEEEE within a min-width 960px media query. If the background image fails to load in wider window, there's still a readable contrast between text and background but on a phone or other narrow screen, the dark background color set on the <body> is what's behind the article text.
mmsc 5y ago
Most likely using the HTTPS Everywhere addon. That website is not available via HTTP, and the user must visit the page first to accept the 'risk' of using the http version.
- nabilhat 5y ago
  Firefox also defaults to HTTPS by default nowadays. Lots of content blockers block third party content too. Regardless, if literally anything goes wrong with the third party dependency that the article's contrast depends on, the best case scenario here is that the text falls back on the body's background. Interestingly, the author also appears to control yu8.us Breaking one's own content by https-ing one site but not another is a great example of why to not prop up a website's basic legibility on a third party dependency, even if it's one you own and control.

rentnorove 5y ago

It's definitely nothing to do with the following string in the response: > Page copy protected against web site content infringement by Copyscape

extra88 5y ago

Yes, they web author made the mistake of defining the <article> background-color: #EEEEEE within a min-width 960px media query. If the background image fails to load in wider window, there's still a readable contrast between text and background but on a phone or other narrow screen, the dark background color set on the <body> is what's behind the article text.

mmsc 5y ago

Most likely using the HTTPS Everywhere addon. That website is not available via HTTP, and the user must visit the page first to accept the 'risk' of using the http version.

nabilhat 5y ago
Firefox also defaults to HTTPS by default nowadays. Lots of content blockers block third party content too. Regardless, if literally anything goes wrong with the third party dependency that the article's contrast depends on, the best case scenario here is that the text falls back on the body's background. Interestingly, the author also appears to control yu8.us Breaking one's own content by https-ing one site but not another is a great example of why to not prop up a website's basic legibility on a third party dependency, even if it's one you own and control.