Something to consider (especially for "child themes") — including:

1. Do not change :focus styles! http://bit.ly/1T12z1S
2. Hiding text and screenreaders
   • :before and pseudo elements

Writing and compiling

• #24 (they're mixed and messy at the moment)
  • A simple way to write and compile an article or a blog.
  • A simple way to generate a pdf or presentation.
  • Just use Pandoc?

Monospaced fonts

• #64 (and check <code><strong> inherited styles)
• #31
• #57

Code examples, references, images

• How to structure internal/external links?
  • Ease of reading, less distraction, yet Brutalist.
• code inside other elements? h1, blockquote, etc
  • Or, make a note never to use within elements whose font is bigger (easier)
• Pandoc's fast-reading of isolated documentation snippets
  • Only downside is a bit hard to find the exact snippet you need (poor search/list)
• Table of contents for longer articles
  • e.g: Real python, HTDP, Ben Frain
• Reliable (MD compiler agnostic) footnotes or references (see Economist style guide)

Insert and delete

• ins, and del vs s?

Tables, instructions, lists

See here and here

• Tables with and without headers (what are the semantics)
  • Section headers?
  • Real headers?
  • Style table headers?
  • Or, use a data list (dl) if there's no need for column / row headers?
  • Longer content, other content

Maths (unlikely I'll use it)

• Maths and symbols (not <code>)

Update: current naming of variables in latest commit

Now it's:

• --color-b
• --color-l

Previously was:

• --color-d
• --color-l

Adding in Anki Themes code, it was:

--color-b
--color-card-l (no colour for light in Anki Themes)

The --color-card is mostly used for background colour, but also used for .missing-Notes font colour.

Might be worthwhile having a --colour-d for dark text and a colour-l for light text. Something like that.

Should I be concerned about basic forms or is this a job for each individual site?

• Check some healthy resets
• Leave it to the browser Gods

Eventually I want to replace .less files with .css files, as most features I want to use in Anki Themes are now possible in default CSS. However, I have a lot of less // comments.

CSS Nesting

I don't think the editor CSS syntax highlighting is properly set up for CSS nesting (yet).

Less.js is only really useful now for @includeing partials, and compiling a css file:

• Coming to you in 2025: CSS nesting is now go!
• Currently compiled into regular CSS with Less.

One day I'll be able to rip out the less code and use a simple compiling script, or at least simply use it to watch for CSS file changes and compile the main.css file.

Other useful HTML/CSS features

1. HTML can do that?
2. CSS can do that?
3. Collapsable section with nothing but HTML/CSS

• abbr usage
• Fringe elements like <u> underline (Github/Markdown doesn't seem to render the tag)

In Material Design (and original cardinal-stylus) I was using --font-tracking variables:

• letter-spacing: $font.tracking.pppp

Put back in?

Hashes fail silently if they've been used but not declared — $this.hash.isnt.setup but is referenced, with no errors given

It's not exactly pretty, but just use css variables: badlydrawnrob/anki#38

Explaining some of the build problems

You'll need to reference some (or all) of these problems in the advanced tutorial for Anki Themes) — especially the "Github dependencies" and "NPM commands" which should be to-the-point and leave no need for thinking. Remember to hide complexity when writing the docs.

• Anki Build Documentation
• Advanced tutorial on building an Anki Theme
• Semantic versioning (and breaking changes)

The Pandoc build script is a little hard to remember:

The Pandoc documentation is pretty verbose, and I struggle with it. I also want to be aware of security concerns with NPM such as here.

1. Output a standalone file
2. Using a template file --template=./source/pandoc/template.html (you can use variables also)
3. By default Pandoc outputs a fragment ...
   • Use the -s or --standalone flag to output a HTML document.
4. To include a custom CSS file (or many), use -c or --css flag!
5. --embed-resources: a standalone document with no external dependencies?
6. #24 (make things simpler?)7.

NPM commands: Updating your packages

npm can install and run your "scripts".
npx seems to allow you to run CLI commands locally (like this website builder).
I tend towards installing packages locally (not globally)

⚠️ Neither npm update, nor npm install <package> will update to the latest version if you're using ~ or ^ semver ranges!!! Why? Read on ...

🏆 You can specify the @major version with npm install. Alternatively, you must change package.json dependency version first, then npm update to that version. Can be done programatically or manually.

1. Dev dependencies currently updating range only (patch/minor)
   • View npm outdated for regular packages (it won't show GitHub dependancies) and npm update (why won't it update to latest version?)
   • View the Change Log before updating to a major version!
   • npm list --depth 1 will list package dependencies (1 level deep)
2. More on NPM Dependencies and scripts

Such a lot of reading, for such a simple thing 🤬😩

Github dependencies: It get's worse!

GitHub repositories that are dependencies don't update at all!! 😔

Make sure you change the #commit-number on the end of the dependency url. You'll also need to explicitly update the package npm update print-first-css.

Use a makefile and watch changes?

An interesting approach to auto-load changes for .less files in this article.

I think I was using the Marked App to compile the specimen.md and styleguide.md files:

You can view the original .md files here

1. Adding the print-first-markdown css file to the app
2. Using it with yaml code Marked Style: print-first-markdown.
3. Marked App uses highlight.js to render code blocks

Is it necessary to prevent a gap if two code blocks are siblings?

• pre tags have no margins
• .sourceCode from Skylighting have margins.
• pre.sourceCode is also overriding pre + pre styles.
• Probably wise for a margin-bottom on <div> or the <pre> for sibling components.

Pandoc spews out default css code in the header when compiling the template. Removing margin: 1em 0 from .sourceCode will stack them together — but this shouldn't be needed — custom Skylighting css should be the default (not Pandocs template code).

Wasted code?

I think originally I added this because of the Anki Themes layout.

• div wrappers have no padding or margins
• pre tags have padding only (no margins)

Two code blocks in Anki Themes will stack together with no gaps.

The following code.less is using negative margin-top:

  & + & {
    border-top: transparent;
    margin-top: calc(var(--spacing) * -1);  // #2
  }

I expect my thinking was to make sure that two pre blocks together would stack up without a gap ... only, while using Pandoc the <div class="sourceCode"> for Skylighting the pre blocks are never going to be right next to each other!

div.sourceCode {
  margin: 1em 0;
}

The above code is what Skylighting wrapper will do; two pre blocks rendered with Pandoc will produce a gap.

Ideally need to update the following base files, that set up standards:

• #43
• Reset (is this still necessary? Maybe yes [box-sizing: border-box here and here)
• Root (does body still require 100% height?)

Consolidate files where possible, delete junk:

• Merge _reset.less and _root.less?
• Keep normalize.css up-to-date?
• Better manage @print functionality?

Waiting for an answer from the less repo

It's not in the main.less file so perhaps less is versioning the output?

Baseline grid can be a bit confusing and a nice ideal, but hard to stick to.

TL;DR: Alignment to a small grid is possible, but items like images aren't quite sticking to it. The more complex the site, the more components it uses, the more you have to be flexible (and break from the grid).

• Baseline grid can be confusing and hard to stick to^¶
  • Units of measurement based on Material Design. Mo' devices, mo' problems :(
  • I think Material Design have scrapped their grid
• Simple things like --font-family can change the rhythm of the baseline grid
  • #6
  • Which unit of measurement? px, dp, sp, rem ... ? 🤯 I think I'm safe with rem.
• When viewed, the baseline grid overlays the HTML elements, i.e: you can't click on links etc.
• Material design promises to fit to a 4dp grid, but breaks it's own rules sometimes.
• The more complex the site, the more it potentially falls down (complexity):
  • See a few attempts to make a proper inDesign style baseline grid.
  • Once you start adding components, font-sizes, etc, it gets harder to control.
  • The current baseline (below) was built a while ago and I've forgotten how I did it!!

¶: It's also difficult to stick to as a website grows in complexity:

See this thread

• Option 1: "quote: odd chars"
• Option 2: Use >- or |- characters

🔍 Google: Staying sane with open source

Things eventually go dead (or get handed on to other people) with open source:

• Stylus and Jeet etc (@corysimmons)
• The problem with wanting languages, software and helpers free. (Elm)
• On not burning out 👎 (Elm)
• #40
• #16 (why should I give a fuck?)

Some great talks amongst others (like Hammock Driven Development) that cross over different industries (like design, coding, charities, ...) with common problems on burnout, or working for free.

Ways to stay sane!

This is something for the future if I ever write a book.

• ePub 3
• Pandoc ePub creation
• InDesign ebook creation

If you had a script.txt file, you could split the command onto lines ...

some command^
 next command

Also, see using npm as a build tool (I think you can do something like "styleguide": "pandoc.txt" to pull a CLI script from a text file:

• Use a .sh file?
• Use a makefile?
• Fail if command doesn't exist?
• Styleguide (specimen) — with correct template and styles
  • Currently using Marked2 app
  • Table of contents?
• Security (see #25)

This might have something to do with the font-size of the monospace font — again this is going to be tricky to resolve when using system-ui as there's no way to know how it'll render without checking every OS!

• Using pre means total area no longer divisible by 4
• pre-line and pre-wrap work

Without table-layout: fixed, you'd need to use <br> to wrap text. By default the width of the table contents will depend on the text length, too.

without fixed table

with fixed table

Potential changes for accessibility:

Notes:

Do not change :focus styles! It’s an accessibility no-no: http://bit.ly/1T12z1S

Got lost along the way (using package.json for tags)

Which parts are still necessary? It doesn't seem to have changed much in 5 years ... is this a good sign? A bad one? See this thread for a discussion. Something newer and lighter required?

• Is it dead?
• An overview of what it's actually doing.
• An overview of css resets in general (and their place today)
• Another (very verbose) description of an alternative (modern?) reset.

Sketch out the pros and cons, as well as the workflow options

Markdown is a simple formatting method, so it's probably best not to get too clever when writing and formatting ... but when adding HTML, current difficulties:

Pandoc allows the following syntax to wrap with a div:

::: {#special}
text goes here
:::

• Marked App seems to add empty paragraphs, causing broken layout
• Pandoc doesn't seem to suffer from this problem

Code example:

<div class="split"><div class="split-left">

- list
- of
-stuff

</div><div class="split-right">

Content

</div></div>

Need to decide whether it's best to:

1. Use Markdown for full pages (with HTML inside file)
2. Use Markdown for partials (and a templating language)
3. Use Markdown with frontmatter
4. Use javascript to style some elements (the introduction, for instance)

HTML inside Markdown is easy(ish) to compile, and if done right can provide some flexibility (such as figcaption etc) — but feels a bit hacky, somehow.

Perhaps there's a balance between building a structure and using markdown files, within that structure.

Some changes to links:

• Force links to always be black with !important

Is it possible to add them as footnotes, instead of using [raw text] in brackets?

• Old article
• @page
• Use (or convert to) shortlinks instead?

See the print-first-css isn't downloading properly — I don't think you can sync them through the GitHub Desktop app.

For now, in general, I'm using as little functionality from Less CSS as possible:

• CSS nesting (which is now included in the CSS spec on modern browsers!)
• @import for including css partial files (very helpful to keep a sane structure)
• #37 and I don't care!

And that's about it. So avoid Possibly best to avoid fancy but ultimately wasteful features — colour functions area nice-to-have, not a need-to-have. Nor do they work nicely with --css-variables anyway.

Keep it simple, stupid!

This issue is too long!! Split into manageable chunks!

"I just let it run, because you can always rewrite, check things, find the right way to say things. If you sit and plan, you get stuck in the planning. When you’re writing a book, I find my fingers just start doing it." (Terry Prachett, source)

Just-in-time and revise as-you-go — easy to understand for beginners and just enough for serious writing. Do the next right thing. Pick a style and stick with it! You can cherry-pick some of the styles you prefer, but it's easier to pick one style guide as a base.

• A refresher on quasi-academic writing.
  • Citations are helpful!
  • Long boring text isn't.
• See also source/markdown/specimen.md
• Things like the Oxford comma?

Decide a general tone, style (academic? head first) as a standard default. This can always be extended or updated for child themes.

Writing must be

1. Easy to understand and reckon with (the stupid version of future me)
2. Easy to write in Markdown (including extra html markup)
3. Work in any version of Markdown (Stick with CommonMark)
4. Easy to extend (for specific needs)
5. Looks pretty

Don't be boring

I don't need to think of all this upfront, as the main things I'm using this repo for is simple articles, the anki tool, possibly a faq or simple documentation, someday a book ... so on. It just needs a simple guideline that's reasonably fun to read (and not a wall of text).

Start super small, super simple and build from there.

• A lot of documentation and writing sucks
• Don't make me think, just enough information (and no more)
• Look at design systems and even kid's books for inspiration.
• Aim to keep the language simple
• Are you writing a programming book? A CV? An article? Documentation?

Inspiration

1. Going to print
2. Designing for print
3. Economist style guide
4. Practical Typography
5. Gov.uk styleguide (design styleguide)
6. A nice [styleguide] that combines different guides

See also:

• #20 — page breaks
• #18 — is this a bad idea?¹

Legible fonts

• #27

Basics

Italics

• When to use italic to highlight terms (or places, authors, titles)
• Bear in mind that serif fonts are way better than sans-serif fonts for this.²

I'm finding it hard to find examples in context online: the way it's actually written in the book. There's lots of quotes with images, but not so many in the original style (a thought in italics)

• When to use <i> for styling?
• When not to use <i> for visual styling?

Heavily used in Terry Prachett's work and Game of Thrones. There's also times where it may not be appropriate.

Italics for works, titles, etc — or should this be 'quotation' style? For instance, this guide has seemingly arbitrary rules for not using quotation marks on certain types of works.

Bold

Bold or italic: they're mutually exclusive

Possibly for sans-serif font to replace italic terms (ie: titles, but not thoughts)

• When to use bold to highlight terms?
  • Does it detract from the text or not?
• When not to use <b> for visual styling?

Using quotations and brackets

These also tend to change depending on country — there's a few ways to go about this ¡Vamos!

• The Economist style guide ("This is speech and 'this inside' speech")

• The Oxford style guide ('This is speech and "this inside" speech')

• The New York Times

• Paraphrasing with a citation (Harvard style)

Semicolons and dashes

• Semicolons, colons, dashes

Images

• Better figure and figcaption defaults

• #13 images
• pre inside figure (with figcaption)
  • linking to a figure (and format, i.e. fig. 1 fig.1 — description
  • figure plus quote
  • figure + figure or figure > img + img (what happens when more than 1?)
• Images styleguide (rough guide on sizes, dimensions, so on)

Citations

• Citation styleguides? (Pick one!)

General writing

• #63

Code

• #52

Other stuff

• #54

Composition

• #51

Accessibility

• #67

Perhaps using a <hr> with a .page-break class? (or no class at all)

• info here
• and here
• styling for ebooks

Some more information on avoiding block elements to be "cut" in half when too long for a page. break-inside: avoid; should work, but on my version of Safari it doesn't.

Also worth reading is Laying out a print book with css which covers some page level css, and annoying bugs with page numbers.

Currently testing out new variables in Anki

• There's a lot more in the Skylighting json file.
• The class names are different in other highlighters
• If building a static website, what highlighter do they use?¹
• badlydrawnrob/anki#107

What is this repo for? Simply for writing? Or a base for web apps?

Not so much for ebooks and pdf printing, but quite useful for simple pages.

• https://cutcodedown.com
• https://github.com/cbracco/html5-test-page
• https://design.virginmoney.com/principles/digital-design/
• Designing for cognitive difficulties (or accessibility)

And remember, programming sucks

They were lifted from the original Material Design, and might be overkill. Just how many font-sizes are acceptable, and how big should a heading font get?!

• Probably add rem sizing in the comments on typography
• Check how many of the variables I'm actually using (in print-first-css and anki themes)
• Glance over the new Material Design documentation and see how many spacers and font-sizes there are there.
  • How do Material Design v1 and v2 differ?
• #40

Currently using npm version ... which is good, but requires manual pushing of tags (and you can't seem to commit and version at same time)

• Conventional commits
• Github releases

Are they secure? #25

I more or less understand it, but I suppose breaking changes can be a bit opinionated. SemVer:

• Major.Minor.Patch

An annual survey carried out by the University of Glasgow tracked author earnings over the last 15 years. The results showed a clear drop in average author income, from £18,013 in 2006 to £10,497 in 2018. By 2022, author income has dropped even further, with professional authors earning an average of just £7,000 a year.

[...]

Research suggests just 19% of authors earn their income solely from writing.¹

Should probably write about this proper, but good to have a few links and references.

• Why you should pay for Beautiful Racket book
• Richard Osman £25 million sales and 10million advance.
• David Walliams has sold more than 50 million books and netted around £100million²

Within the #10 issue, how might I be able to write standard markdown, but style in a subtle, useful manner?

Decide

• Do I stick to basic styling in print-first-css (a blank canvas)
• Or set up some "academic" style defaults?
  • Or, use a child theme for this?

Examples:

• Link styling — could be useful for footnotes or references

Tone and voice

For example: removing passive voice from your paper (academic writing can be deathly dull, so why the hell not?)

Other resources

• Storyteller tactics (pip-decks cards)

I'm pretty sure I'm only using --css-variables and simple @includes with Less CSS now, as I made a bunch of changes after scrapping Stylus. This is stated in #19.

It's good to note that Stylus is back in vogue, and actively maintained now. One of the main appeals of the language was it's similarity to Python notation.

Alas, my general feeling now is that CSS is hard enough, without added complexity of preprocessor trickery. The features of Stylus, Sass, Less, or others can be a nice touch, but too much of a ballache to reason about when files and folders expand.

Keep it simple, stupid and don't make me think!

• Remove $grid hashes?
• Remove dependencies (original Cardinal Stylus)
• Remove buttons?

Child themes

Remember that Print First CSS is a bare-bones approach.
It is not a framework. A child theme takes on that responsibility.

Currently the default font is system-ui, the headings are font-weight: normal and inherit from :root, and there's no custom font included. Beware that @font-face should not be nested inside a selector or class.)

Add a @font-face to customise your fonts? Definitely a problem for child themes, not the defaults as we're using system-ui font stack.

Anki, Anki-child-theme etc

• badlydrawnrob/anki#12 — uses @font-face
• https://github.com/badlydrawnrob/anki-child-theme — currently same styles as Anki
• https://github.com/badlydrawnrob/print-first-cv – uses system-ui for now

Some nice font examples

• Gentium book basic and book plus (Google font)
• Why I hate Verdana (best for screen, not print)
• #31
• Menlo is also a good option for a monospace font.

The particulars

• #31
• ⚠️ Exploring font stacks for Safari/Anki (very annoying compatibility issues)
• Change --font-family and --font-family-mono font stacks
• Override partials/..: _root.less, headings.less, code.less, etc. — You don't need to edit these if overriding --font-family-** variables.
• Embed fonts (like with Anki themes) or use links.
• Variable fonts will eventually be easier.

Especially npm run build

This is probably more relevant to print-first-css for writing, but adding it here also:

• Git word diff and it's problems
• Other ways to track changes
• CriticMarkup using Marked 2 app

For different languages
Also could be useful stylistically

⚠️ It get's complicated!!
..... Seems tricky to find good Arabic examples?
..... Grids and Flexbox is hard enough without foreign languages!

Some questions

1. Should books be transliterated?
2. Or should they be in their own language?

For non-natives, it's hard to manage a site that carries international languages as some things are very hard to add, edit, and search for without knowing the language (or owning the keyboard in ___ language)

Some example sites

• Smashing Mag article
• Multilingual site examples
• Localised website examples
• Japanese writing system
• I wonder if Chinese can read in pinyin? Interactive pinyin
  • They do use it for texting to find Chinese characters

Needs a debate on which method to use, whether to blanket-force responsive images ... and so on.

• max-width: 100% on all images [using]
• center all images?
• responsive? resolution?
• Aspect ratios?

UPDATE 2023: Why should I give a fuck?

e.g: 4 days worth of work and I feel like I've barely scratched the surface:

• Installing the software required
• Refactoring code and minor updates to files
• Copious amounts of Google searches and document reading
• Issues, issues and more issues (documentation)
• Note taking and abstract thinking about problems
• And on, and on, and on, ...

... Little wonder Computer Science drop-out rates seem to top the charts!

CSS it too damn slow (to create)

It takes forever just to get a simple CodePen working, unless the css is super simple. Anything with a butt-load of html starts to get more time consuming — especially if you're trying to reason about and override someone else's code (like Pandoc's Skylighting)

It's quite infuriating. 💩

WSIGAF?

Currently the only repos including print-first-css is Anki themes which, I don't think is sticking to the baseline grid; and Print First CV

Why should I give a fuck? That's a great question to ask yourself whenever you consider working on a new feature/update. The file system is a bit nebulous and I'm beginning to wonder if humans really want to print out a webpage anyway. Do I really need to create a CV page created in code? Does it really need to be designed? Does anybody actually give a shit about this repo?

No, no, and probably no.

On Design Systems

A general rule is Reduce, Reduce, reduce!!! (succinct and distilled)

• Don't make me think!
• It's weird how design systems are so rote, yet so difficult Y combinator thread
• ⭐ Pico CSS and Tailwind
• Material Design is a monster of a design document. Yikes.
• Brutalist design — ugly or elegant?
• Use boring technology where appropriate!
• Using the right Typography for the job (a CV or an Anki tool)
  • #49 (Typography has a lot of sizes)
• What happens with a new font? (font-size / line-height combinations)
• #42 (use stock CSS wherever possible)
• #40 it's difficult to stick to as a design develops, such as the font you use or components.
• Things like --font-tracking are a luxury I don't need.

On Writing Styleguides

• Don't make me think!
• #10 (improve this document**

Some other considerations:

• #24
• Look to simple, easy to build guides for inspiration.
• Accessibility in writing?
• Boxes and child themes (see below)*

Currently not sticking to the printable css philosophy in Anki Themes. Should print styles be considered and @media screen rules used?

• Avoid overkill:
  • Case by case basis, i.e:
  • Useful for a CV document
  • Useful for certain portions of a website (blog post)
  • Useful for an [epub] book (possible with Pandoc)
    • Also Ascii doc but that's in Ruby. Yuck.
    • There's the question of professionalism; are apps better?
    • ePub3 has some nice features (also accessibility)
• Can you even print from Anki?! This is a no in my view.
• A styleguide for an ePub-style document (print and screen)
• Also see #5
• #57

• Include verbatim main.css file contents in <header> using Yaml? (interesting but not relevant essay post)
• Include a .json file to change the <header> CSS highlight styles
• Simply include a <link ...> file to main.css and just override highlight styles there (e.g: edit HTML template file and hardcode CSS file there)

You can find the basic documentation here ... though I've forgotten how the bloody html templates and flags work in the npm command for Pandoc rendering the template in terminal. I think it's wise to use Pandoc templates frugally as, to me, the documentation is as clear as mud and likely to change.

See a better overview in the Stackoverflow thread (seems more thorough than the official docs) and this is also a good guide for the .json files that Pandoc uses — and this Stackoverflow conversation is a good reference for printing out the default html template, and css files that Pandoc uses (this link is ok for the basic html and css template, but I think the $highlighting-css$ is dynamically created through the .json file. Yeah, it's getting confusing (and this bug isn't helping either)

Outputs a .json file, which I think you could replace with --css-variables at least to create a light and dark theme. The core Skylighting css file might be better suited to live in print-first-css, only extending it in Anki themes if absolutely necessary.

It'd then be a simple case of changing the values for --css-variables in a simple colours.less file!!!

Also see this comment about Skylighting's downsides.

{
    "text-color": null,
    "background-color": null,
    "line-number-color": "#aaaaaa",
    "line-number-background-color": null,
    "text-styles": {
        "Alert": {
            "text-color": "#ff0000",
            "background-color": null,
            "bold": true,
            "italic": false,
            "underline": false
        },
        "Annotation": {
            "text-color": "#60a0b0",
            "background-color": null,
            "bold": true,
            "italic": true,
            "underline": false
        },
        "Attribute": {
            "text-color": "#7d9029",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "BaseN": {
            "text-color": "#40a070",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "BuiltIn": {
            "text-color": "#008000",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Char": {
            "text-color": "#4070a0",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Comment": {
            "text-color": "#60a0b0",
            "background-color": null,
            "bold": false,
            "italic": true,
            "underline": false
        },
        "CommentVar": {
            "text-color": "#60a0b0",
            "background-color": null,
            "bold": true,
            "italic": true,
            "underline": false
        },
        "Constant": {
            "text-color": "#880000",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "ControlFlow": {
            "text-color": "#007020",
            "background-color": null,
            "bold": true,
            "italic": false,
            "underline": false
        },
        "DataType": {
            "text-color": "#902000",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "DecVal": {
            "text-color": "#40a070",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Documentation": {
            "text-color": "#ba2121",
            "background-color": null,
            "bold": false,
            "italic": true,
            "underline": false
        },
        "Error": {
            "text-color": "#ff0000",
            "background-color": null,
            "bold": true,
            "italic": false,
            "underline": false
        },
        "Extension": {
            "text-color": null,
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Float": {
            "text-color": "#40a070",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Function": {
            "text-color": "#06287e",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Import": {
            "text-color": "#008000",
            "background-color": null,
            "bold": true,
            "italic": false,
            "underline": false
        },
        "Information": {
            "text-color": "#60a0b0",
            "background-color": null,
            "bold": true,
            "italic": true,
            "underline": false
        },
        "Keyword": {
            "text-color": "#007020",
            "background-color": null,
            "bold": true,
            "italic": false,
            "underline": false
        },
        "Operator": {
            "text-color": "#666666",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Other": {
            "text-color": "#007020",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Preprocessor": {
            "text-color": "#bc7a00",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "SpecialChar": {
            "text-color": "#4070a0",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "SpecialString": {
            "text-color": "#bb6688",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "String": {
            "text-color": "#4070a0",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Variable": {
            "text-color": "#19177c",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "VerbatimString": {
            "text-color": "#4070a0",
            "background-color": null,
            "bold": false,
            "italic": false,
            "underline": false
        },
        "Warning": {
            "text-color": "#60a0b0",
            "background-color": null,
            "bold": true,
            "italic": true,
            "underline": false
        }
    }
}

Nested queries: IE11 does not support nested queries

Getting the hierarchy and order right (aftercare)

• What's important? How do you read at-a-glance rules and which are priority? Start with the absolute basics, atoms.

Look over some examples of articles, stories, documentation, and aim to get an overarching style that reads nicely and could work for varying purposes.

• Pages for grouping content (H2 headers per page)
• HTDP has a side-menu and call-out sections, but a lot of text.
• How do elements "fit" together? How do they not?
  • headers can look bad in some combinations (depending on css)
  • Do we really need two pre elements stacked together?
    • Keep the css simple and add only if necessary (in child themes)
• Specific guides for highlighting words and sections Guides for highlight words
  • This isn't perfect but has short pages and key terms highlighted (overall it's not pretty)
• When to write in prose style, or short "snippet" style
  • An article has paragraphs smushed together
  • A documentation might have short paragraphs, lots of subheads, lots of bullet-points etc.

Using system-ui, --system-mono and --fallback-mono
In general, these should use the defaults for each OS.
The monospace font seems to have a larger x-height ...
So we're using a Goldilocks hack with calc(...) for --font-family-mono.¹

I'm going to allow for variety of fonts depending on system-ui:

• 🔗 Monospace font stacks (default is browser-safe monospace fonts)
  • There's some very nice monospaced fonts with ligatures too.
  • See [this Anki issue](Good monospaced fonts) for alternative monospace fonts. (see "Good monospaced fonts")
• Does the mono line-height need updating?
• Goldilocks the --font-family-mono (i.e: "just right") Use system-ui
• Use a set --font-family rather than the generic --ios/android font stack?
• Does it look the same on ios and android? No! (the default, at least)
• See also this link and another explanation on monospace font-size issues (see below comment)
• #40