Introduction

Monochromatic aims to define some sensible sets of styling for text-heavy websites.
For example, a personal blog made of blog posts or a manual organized in chapters.

Why choose this name?

  1. Only pure black and pure white are allowed.

  2. Only the styling necessary for conveying the semantic meaning of each element and its surrounding context are made.

  3. Only the animations that are necessary are allowed. At the same time, the animation cannot be something that updates too much of the view, takes too much time, or has too many @keyframes.

  4. Only one stylesheet and one script are allowed for each variation. This:

    1. reduces maintenance costs

    2. improves performance if the user visits more than one page.

Hence "Monochromatic".

Why are you placing so many restrictions?

  1. There's some appeal about having the option of using something but avoid using it and get the job done anyway.

  2. More restrictions means fewer considerations.

  3. Only using pure white and pure black automatically satisfies the high-contrast requirement.

Why write documents in HTML instead of a lightweight markup language using Markdown?

  1. HTML gives more control over Markdown. Here are some requirements only achievable using HTML.

    1. Use <details> and <summary> for headings and its content in order to let user freely fold those sections.

    2. Styling and scripting.

What's inside this repo?

There are several top-level directories in this repo.

Top-level Directory archive

An archive of abandoned content. Including ideas, design choices, and design mockup with HTML.

  1. For example, the has_red_color directory inside the archive directory is for when the project was using color red other than black and white only.

Top-level Directory src

Stores the source code of this HTML document.

Stores all documentations of design decisions, design software mockups, and implementations of those mockups with Sass and JavaScript.

Documentation of design decisions.

A typical document would communicate:

  1. Which purposes the UI element should fulfill, and which purposes the UI element should fail to fulfill.
  2. How the UI element should be presented, and how the UI element should not be presented.
  3. The user interactions the UI element should be able to react to, and the user interactions the UI interface should not be able to react to.
Implementation of design decisions in Figma (or other design software).
Implementation of the result of Figma (or other design software) mockups with Sass and JavaScript.

Top-level Directory docs

The directory GitHub Page's "Classic Pages Experience" serves.

Sure, using GitHub actions sounds cool: I can instruct a full Linux virtual machine to run a pnpm build whenever I push. However, that also means there would be a lot of wasted resources. It's just a simple command, at most it would take a few seconds. So, the ratio of actual, necessary resource consumption over unnecessary resource consumption is very low. Sure, those are not my resources, but I don't want to spend unnecessary resources anyway.

Inside of those top-level directories, some subdirectories will be created for variants of "sensible set of styling"

Subdirectory M

M

Why choose this name?

Monochromatic start with the letter M.
Meaning this variant of "sensible set of styling" is closest to what the name of the project conveys. Unassuming but still provides a modern reading experience.

Specific rules:

  1. Use the simplest style.
    If using a simpler style, like using a normal border instead of using a double border, would still sufficiently convey the semantic meaning of the element and the surrounding context,
    use the simpler style instead of the fancier one even when the fancier style can convey the meaning better or is more aesthetically pleasing.
    This variant has the fewest requirements on how well the semantic meanings should be expressed.
  2. Always use a sans-serif font.
    For example, titles, paragraphs, references, comments. Reasons:
    1. The font family Inter is specifically designed for modern electronic devices.
    2. Sans-serif fonts have much fewer details than serif fonts, by definition.
    3. Using only one font family throughout the entire website reduces the data need to access it. In other words, avoid performance loss.
    4. People are used to reading sans-serif fonts on websites since most websites use them instead of serif fonts.
    5. Titles look more modern when using a sans-serif font family.
    6. All Operating Systems' default sans-serif font families are readable. If the external font fails to load, the website would still look okay-ish.

  3. No animations are allowed.

  4. Use built-in styling and element appearance adjustments instead of removing them and put my own there instead.

jsDelivr URL: https://cdn.jsdelivr.net/npm/monochromatic/docs/assets/style.css

Subdirectory A

A

Why choose this name?

The alphabet starts with A.

In this variant of "sensible set of styling", Fancier styling can be used when there are big improvements to the expressiveness of semantic meanings compared to simpler styling.

  1. For example, consider using double borders on the inline-start side of the <blockquote> element instead of using a normal, simple border
    because a double border can better differentiate the appearance of blockquotes from message tip blocks. A double border can also imply the content on the right side is a page from a book, which is a desirable effect for blockquotes that are often quoted from books.

  2. Sans-serif font can be used sparingly, like in some headings or comments.

  3. Simple animations like animation the transformation of the <a> underlines to a rectangle behind them is allowed. Both the shape and the color.

    The use of animation-timing-function is allowed.

Subdirectory B

B

Not decided yet. Maybe allow one gray?

Subdirectory C

C

Not decided yet. Maybe allow one (or some, or many) gray and some (or one, or many) transparency levels? Or allow CSS features that are mainly used for showing off like `clip-path`? How about fancy animations?

Subdirectory D

D

(Same as above because I failed to come up with more ideas.) Not decided yet. Maybe allow one (or some, or many) gray and some (or one, or many) transparency levels? Or allow CSS features that are mainly used for showing off like `clip-path`? How about fancy animations?

Subdirectory public

This is the directory for public, static content that needs to be served, like the favicon.

The build system used in this project, Vite, enforces this naming convention.

What this project is not.

The code written in this project is mainly used for demonstration.

I1 do not seek to write high-quality code. Therefore, lots of coding standards are not followed and lots of common linters are not applied. Expect poor optimization and lots of duplicate code.

However, due to the advancements in modern devices' computing capacity, most of these code snippets should work well enough, if not faster, than using a heavyweight frontend framework. Therefore, I believe it's still important and meaningful to publish my implementations.

License - CC0

I chose CC0 license for this project because:

  1. This project won't be well-maintained.

    (For personal reasons.)

  2. I have not done the learnings I should have done.

    1. The designs I have came up with right now are horrible.

      Project will undergo huge changes after I learn more about UI and UX design.

    2. Yeah, and I should learn how to write technical documentations, too. I'm assuming writing so many "I"s would not make the document look serious.

    (Not going to promise anything here, though. We'll see how it goes.)

  3. Citing this repo or asking my permissions is troublesome and non-rewarding,

    (As there's not much to cite or use in the first place...)

Therefore, I declare that:

You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permissions.

See more at https://creativecommons.org/publicdomain/zero/1.0/legalcode

  1. "I" means Aquaticat, the creator and owner of this project, for simplicity's sake. Using "we" would not be fitting because I do not expect a potential future contributor to share my opinions on this project, nor do I expect any contributor at all.

Element by Element