EXOTIC SILICON
“Website handbook and configuration”
How to use and configure settings on Research.ExoticSilicon.com
WEBSITE HIGHLIGHTS
Private Cloud
100% Valid HTML-5 markup
100% Valid CSS markup
Javascript not required for any website feature
Choice of ten graphical themes
Renders just fine in text browsers such as lynx and w3m
No tracking cookies, no pop-ups, no affiliate links
Support for serving images in bandwidth-efficient arithmetic jpeg format
Configuration options for Research.ExoticSilicon.com
Current settingsAdjustments
✔ Serve webp images
Serve webp (default)
Don't serve webp
✖ Don't serve arith­metic jpeg
Serve arith­metic jpeg
Don't serve arith­metic jpeg (default)
U.S. English
(auto­selected)
British English
U.S. English
Autoselect (default)
No text cursor
No text cursor (default)
Non-flashing block cursor
Flashing block cursor
Theme: Tropical days
Update settings
Notes:
CUSTOMISE YOUR EXPERIENCE HERE AT EXOTICSILICON.COM!
Website FAQ
Website FAQ:
These are technical FAQs about the website.
For more information about Exotic Silicon as a research organisation, please see the welcome page.
If you are looking for our commerical IT services, please visit www.exoticsilicon.com.
What backend content management system does exoticsilicon.com use?
It's our own custom CMS written entirely in C.
Is the source code available?
No.
Why don't you include compatibility code for older browsers?
Because we don't want to encourage the use of outdated, insecure, or non standards-compliant webbrowsers, nor do we want to create bloat for users of modern, standards compliant browsers. The HTML and CSS on this website passes validation tests, so any modern webbrowser that renders it incorrectly or incomplete is either buggy or simply lacks full support for the standards. Note that unless your browser is several years out of date, the website should still be perfectly navigable, as it is designed to degrade gracefully when accessed with a browser that lacks supports for all of the features we use.
I just tested one of your pages and it failed validation!
This should never happen. If it does, and you let us know about it, it will be fixed.
What does the text cursor configuration option do?
If you enable it by setting either a non-flashing or flashing block cursor, then look at the ‘local patchsets’ page, you'll see that an extra line has appeared in the consoles, with a cursor of the selected type in it.
Why did you bother to implement that feature?
To test a certain function of the CMS code during development.
Why don't you set image-rendering:pixelated in the 1980s theme for photograph on the welcome page?
Because it looks less authentic, especially when scaled down. The interpolation when resizing the dithered image happens to approximate the lack of focus on many 1980s green phosphor CRTs.
Why don't you support the prefers-color-scheme css media query to set a default theme?
Quick answer: Because it's a badly thought out standard that doesn't meet our requirements.Show in-depth answer
A CSS media query is a stupid way to implement this functionality. Unlike something like window size or display orientation which can and does change dynamically as a user is browsing, the user's preference for light or dark color schemes is usually consistent. Inline CSS media queries require the entire stylesheet source for each possible variation to be sent to and parsed by the browser when rendering the page, whether they are used or not. This increases bloat, but is an acceptable trade-off for something like display orientation, because the user might switch from horizontal to vertical and back again whilst actually reading the already-loaded page. Therefore, it makes sense to have sent both stylesheet variations to the browser. By contrast, (pun intended), sending a light and a dark variation is almost certainly going to result in half of the CSS that is sent never being used.
More significantly, we offer far in excess of just two themes on the exoticsilicon.com websites, to give users an even finer-grained choice of pages that are brightly colored, have muted color, are slightly dark, very dark, monochrome, and more. This can not be implemented with the overly simple and fundamentally limited prefers-color-scheme media query alone. We could, theoretically, create a special theme that incorporated two of our existing themes, a light and a dark one, and use the media query to select between them, and then if the user switched to a specific theme, only serve that one without the media query and it's associated bloat. However, that would still hurt performance for users who are browsing with cookies disabled, as they can't select an alternative theme, and in any case it goes against our principles to support a standard that we think has been badly implemented, thereby encouraging it's further use.
A far more sensible way to have implemented an indication of the user's preference for a light or dark color scheme in a web browser would have been an HTTP header with this information, which could be parsed by the server and allow appropriate content to be delivered. Note that a dark color scheme doesn't just mean inverting the color of the text and the background! To do it correctly may well require any graphical resources on the page to be changed, too. Not a challenge for static graphic content, and in some cases you might even be able to handle that case with semi-transparent dark color overlays, or css filters. This would avoid serving an entire alternative set of images which could easily run into several megabytes of data, although this approach wouldn't allow complete flexibility over the design. The situation is more complicated for video, though. Imagine a live video stream of educational material, divided equally between video of the lecturer and slides or a virtual whiteboard where textual content is being presented. The video of the lecturer would remain unchanged between light and dark versions, but ideally we would like to invert the whiteboard material for the dark color scheme. Handling this entirely on the client side would mean having the client choose one of two possible live streams, as the server has not been informed of the user's preference. If the streaming is customised for the individual connection in other ways, such as adjusting for the client's currently available bandwidth, or adding a unique waterwark to discourage further distribution, this means preparing an entire second video stream on the server which may go unused. By handling everything server-side, this problem doesn't exist.
In summary: the prefers-color-scheme css media query is too limited in scope, and too inefficient for our needs. It suffers from being implemented entirely on the client-side without sending the same information for parsing by the server.