Seriously, no static display on a modern and correctly adjusted VDU such as a computer monitor or phone screen should ever be inducing headaches or eyestrain in a healthy individual when properly used for reasonable time periods, and with sufficient breaks.

What's more, we never have done, (under the Exotic Silicon banner), never will, and have no interest in doing so.

Anybody asking this question either wasn't around in the 1990s, or has a very bad memory.

With the exception of blue, underlined links, (which we hardly use exclusively), we don't use any of the above design elements.

The animations on our site are implemented with CSS or S.M.I.L. and are quite different visually from the GIF loop animations typical of 1998.

(Binary transparency was possible with GIF images, but that's completely different technically and visually to the alpha channel effects that we use here today.)

We do provide a “1990s” theme, which is basically the default tropical days theme but with serif fonts everywhere, less transparency and less rotation. This was never intended to be a truly authentic 1990s experience, but more of a nod to that style.

Is anybody else designing pages like we do? Basically, no. If they are, it's CSS enthusiasts and not organisations with a corporate agenda.

Exotic Silicon started as a research organisation, and we're here to push the boundaries of the technology that we use. Our website reflects that, both with it's content and it's style. If nobody pushes the boundaries, then they don't move on their own.

Personally, my designs draw from styles and concepts typical of 8-bit computer magazines in the late 1980s and early 1990s.

Every single CSS feature that we use on the webpages is intended to enhance the presentation of the material. Nothing more, nothing less.

Some CSS features are much more commonly used on the web as a whole than other CSS features, to the point that people seem to think that using the less commonly used features is some kind of ‘advanced technique’. To us, it's not.

We're not limited to any subset of the CSS standard. You're expected to use a modern, standards-compliant browser to access our pages, so we happily use any valid CSS that's been supported in the major browsers for a year or more.

(Although the pages should degrade gracefully on older browsers, since the CSS is all standards-compliant and validates without errors.)

We have absolutely zero motivation to do that.

Exotic Silicon does not offer commercial webpage design services, and none of the people who work on the webpages here accept freelance work.

The web pages on our research site are designed to present our research material for viewing in standards-compliant web browsers in the 2020s.

You almost certainly did not try ‘all of the themes’, at least according to our website logs.

Most people never change from the default theme. Those who do tend to try two or maybe three others.

The percentage of users, (apart from Petalbot, which seems to be obsessed with our site), who have tried all of the themes can probably be counted on one hand.

So after you complained on social media that our website is not to your liking, (in a rude, sarcastic, exaggerated and/or non-constructive way), somebody kindly pointed out to you that there is a theme selector, which provides a total of ten different themes.

There is a monochrome theme. In fact, two different monochrome themes. And a sepia theme, which is basically bi-color, or split-toned, (black, white, and sepia).

Seriously, the amount of transparency we use is quite minimal, and if you select the 1990s theme, there is even less.

The 1980s theme basically doesn't use transparency at all.

This is almost certainly your browser at fault, not rendering the shadows as intended and in compliance with established standards.

Note that the rendering of text shadows is, (as of March 2023), currently defined in the CSS Text Decoration Module Level 3, subsection 4, which refers to the CSS Backgrounds and Borders Module Level 3, subsection 6.1.

The rendering process, and therefore the final visual presentation of text shadows in browsers, is fairly strictly defined, and it is not acceptable for a standards compliant browser to simply render the text-shadow property, ‘any old how’, and, ‘hope for the best’.

Since Exotic Silicon is at the forefront of applying this technology to real-world webpages, we get the brickbats and ridicule from uninformed commentators on social media channels, who are not aware that they are using broken browser technology.

It's hardly surprising that browser bugs are more likely to show up when viewing pages from Exotic Silicon than they are browsing pages from the majority of other websites which don't use many CSS features. We're finding and exposing the bugs in your software that other people, including the developers of the browsers and text rendering libraries have missed!

Either that, or you have fiddled with the settings to make other sites look the way you want them to look, without realising that you're breaking things elsewhere.

We do occasionally use drop shadows on text for pure visual effect, usually in section titles or on body text in the light on dark themes such as the night theme and the neon theme. In most cases, though, drop shadows are deliberately added to body text to make the text more readable, and not less readable, by increasing or decreasing the apparent contrast with the background color.

Note that we frequently use several text shadows together, so if you have bugs in your text rendering code then it's even more likely to show up in these cases.

Here are some sample renderings from Chrome 109 on Android 8, and surf-2.1 running on OpenBSD 7.2, using webkit 2.38.2.

You should view the images without further scaling to make a fair evaluation, although we note that even with further scaling by the browser the text generally remains clear at reasonable sizes.

Whether you like the visual presentation or not, it's clearly not ‘unreadable’. Similar layouts and color schemes can easily be found in advertising materials, packaging, print magazines, and many other places.

If reading text like this causes you headaches or eyestrain, then you would presumably be experiencing these effects elsewhere too, (and should promptly seek professional medical advice).

This is how we intend you to be seeing our material.

Therefore, if your local browser renders the page significantly differently, especially if the text shadows are more pronounced, and/or obscure or blur the text, then one of the rendering platforms in question is not complying with the standards, (or the standards are inadequate and/or are not sufficiently clearly defined).

Removing the CSS effects and reducing the website to black text on a white background would not solve this issue. It would stop the deluge of sarcastic comments that we see every time we publish. But we're here to fix the real issue, which is browser bugs and standards non-conformance.

Browser updates can be, and are, pushed on a regular basis nowadays. Users absolutely should be using a modern browser for security reasons, so there is no need for us to support the quirks of particular old versions of popular browsers for a decade at a time anymore.

The main global stylesheet uses the browser default font size, smoothly scaled up to 130% on higher-resolution displays as the baseline for the body text of the whole document.

If you are using a browser without first configuring it's default font size to something that suits you, then it's hardly surprising that the font size is not to your liking.

Some websites follow a trend of artificially setting a larger font size for the main body text. We won't do this. We are not going to start adding, font-size:2em, font-size:2.5em. font-size:3em, to the HTML element just to make our pages stand out. It's basically just the same as mastering a piece of music with more and more compression to make it sound louder. Stupid policy that we are completely against.

An appropriate base font size should be set in the browser, so please correctly configure your browser so that the default font size is comfortable for you to read. Then complain to the other websites that artificially bump it up. If you've previously tweaked the font size using other websites' proprietary settings rather than those of the browser, then then do it the propper way and fix your browser, then come back to us.

This really falls in to the category of personal preference, but in any case, all of our recent publications have used regular weight fonts for their body text in the default theme.

Whenever one of the light text on dark background schemes uses bold text for the body, we generally increase the leading to make the text more comfortable to read, and long lines easier to follow.

Guess what? Despite all of the rudeness and arbitrary criticism that we receive, we even go the extra mile to cater for awkward people who make extra demands!

All of our pages should render neatly in the common text-mode browsers, such as Lynx, Links, and w3m.

You won't get the best experience that could possibly be achieved on a text console, because none of these browsers is really acceptably standards compliant. They don't parse even the parts of CSS that they could reasonably do - margins, floats, borders, and even colors are all possible on a text console, but support for these is sorely lacking in text browsers as of 2023.

But anyway, most of the material published on our research website is also available in gemtext format via our gemini server.

This is pretty much pure ASCII, and can even be read without a gemini browser.

It's them who have decided to arbitrarily mess with and ruin our content.

Our pages require a modern, and standards compliant browser. The use of ‘reader’ mode can hardly be described as modern and standards compliant.

Ask the Firefox team this question!

Our HTML renders correctly without it's corresponding CSS, that's to say, if you manually remove the embedded CSS style information from the page.

In other words if you strip out all the CSS content, you should see correctly formatted text in paragraphs, and the content in the correct order. It will be rendered in the browser's default font and color scheme, which was traditionally black text on a light grey background. No textual content or navigation should be inaccessible.

Of course, it will look ugly, like a webpage from 1993 displayed in an early version of Mosaic. But that's what you wanted if you selected ‘no style’, right?

The vast majority of the CSS that we use is intended purely for visual effect, and we intentionally don't want that interpreted as having any semantic meaning related to the document content.

Most of our articles are fewer than ten thousand words long, and all of the text is trivially searchable and indexable since it doesn't require javascript or rely on awkward CSS to put it in the correct order.

As a result, the use of HTML <section> elements as the main form of semantic markup shouldn't be hindering or negatively affecting the accessibility of the material we publish anyway.

On the other hand, seemingly innocent addition of semantic markup, such as replacing the div elements containing section headings with tags like h1, h2, and so on, can and will cause awkward and unexpected results on some text-mode browsers as well as assistive technology such as screen readers.

Graphical browsers can be made to ‘ignore’ their default presentation of elements such as h1, by using a so-called, ‘css-reset’, which in itself is a nasty cludge. Current text-mode browsers will not parse CSS, and so they will impart their built-in visual effect to these semantic elements, which is not controllable and differs between browsers, so this is not desirable.

We would like to point out here that as of the time of writing, we have never received a single complaint from a user of assistive technology, and we actually pride ourselves on the fact that our material should be more accessible than most other web content. We take great care to ensure, for example, that keyboard navigation works just fine, and that you can navigate the site without a mouse or other pointing device.

Also, the footer of each page is contained in an HTML <footer> element, and there are other semantic hints too, such as the use of the aria-hidden property for the “TEST” pattern on the candlelit console page.

So it's plain wrong to claim that we don't use any semantic markup. We use what is appropriate for the content and it's intended use.

Long answer: This question actually comes up quite rarely, because the overall page loading and rendering time is so good that most people don't notice how large the resources they are downloading are.

But it's a question worth answering since it's interesting from a technical point of view.

The essential point is that over-compressed images full of artifacts look awful. As long as loading and rendering time is not negatively affected, higher quality images are always going to provide a better experience to our users.

Our pages are designed first and foremost for interactive use by human visitors and not for indexing by search engines. Search engines love it when you compress your images beyond the point of no return, because it's drastically reduces their bandwidth requirements. They have virtually no vested interest in the visual quality of your material, and once the majority of the web has been convinced to over-compress their images and destroy the fine details, then it's just a race to the bottom.

As far as we know, the vast majority of people visiting our site are doing so over modern fixed line broadband or cellular links. Certainly, you should be experiencing total page loading times of around one second when moving from page to page, and the time to initial rending should be below one second.

If the site is ever significantly slower than this, it's usually because we've taken one of our DNS servers off line and DNS requests are timing out. In other words, it's not a website design issue.

We are one of just a handful of websites globally who support arithmetic JPEG which reduces the image bandwidth requirement by around 10% for exactly the same quality. It's not enabled by default, since there is no reliable way to detect browser support, but it can be enabled on the website configuration page. Once again, we're ahead of the curve, doing something that virtually nobody else is. Please try it out before complaining.

Furthermore, despite clearly asking people not to infringe the copyright in our work, we've seen it plastered around the web everywhere from unauthorised, (and un-necessary), ‘archives’, of our material, to use of our images on message boards. Since most of this re-use involves re-compression of the material, and some people will inevitably get their first exposure to Exotic Silicon via these unauthorised copies, we at least want to minimise the damage by ensuring that the original material is of high quality. In this way, any ‘pirate’ copies that have been further compressed at least have a chance of retaining the high visual quality that we want associated with our original work.

If your browser doesn't support SVG favicons at all in 2023, then that's pretty pathetic. We're not going to disincentivise browser coders from implementing support for SVG favicons by compromising and providing an alternative format. Such browsers should be fixed. Or laughed at. (Or both.)

Firstly, the fact that you expect us to go out and find your comments on random third-party sites, instead of just contacting us directly.

Since the vast majority of the private comments we get are positive, but the public discussion is often more critical, we genuinely wonder if the ‘complaints’ have any real basis or if it's just attention seeking.

Secondly, the fact that we get virtually no recognition that the entire site:

Actually a few people have commented positively on the fast loading times. Thanks.

Actually, the truth is quite the opposite.

We love criticism, although it helps if it's constructive.

Any, ‘we love it’, comments make us feel good, but it's the negative comments that feed in to our pool of knowledge and give us potential ideas for how to improve even further.

But if this is really what you want, then you can easily have it by:

We're ahead of the curve. Just like those who realised the multimedia potential of the Amiga in the late 1980s, rather than deriding it as a games machine.

Exotic Silicon's research department publishes IT research on the web in 2023.

No it is not! And the rest of the team get really upset, (not to mention jealous), every time somebody asks this question!

No, she is not! And please stop asking!

We're not sure why you'd want to, anyway. Typically, I know when Crystal is in the office when suddenly, after three hours of staring at drawterm, my concentration is interrupted by her hair in my face, as she leans over my shoulder, drooling down my neck and commenting, ‘owwww, that looks sweet!’.

Crystal is mainly here to answer our external communications, and maintain our local BSD patchsets, porting them forward to new releases. She does research and technical writing in otherwise idle moments. That's it.

A lot of the most popular articles on the Exotic Silicon research site, (the reckless guide, SBC bootcamp, real programming tutorials, SMTP over IPSEC, and more), were written by - and are clearly credited to - Jay Eptinxa. Yet he doesn't have a fan club!?

And neither do I!