Personalization

Properties and themes
cover almost everything you'd want to change. This page is about the last
stretch: what to do when the knob you want doesn't have a name.

There are three escape hatches, in increasing order of power — and of how much
they tie your deck to a particular look.

1. Raw CSS variables in the frontmatter

Any frontmatter key starting with -- is passed straight through as a CSS
custom property. That means every variable the renderer reads is settable,
including the ones with no friendly alias:

===
title: My deck
--tac-callout-theorem: #7b4bd8
--tac-footer-padding: 40px
--tac-grid-gap: 2rem
===

Use this for the variables listed in the
Property Reference that have no named key, and
for custom callout variants.

2. Spans with classes: [text]{.class}

To style a piece of text rather than the whole deck, wrap it in a span and
give it a class, Pandoc-style:

The result was [entirely unexpected]{.surprise}.

You can also attach an inline style directly, when a one-off doesn't deserve a
class:

[This bit]{style="letter-spacing: 0.08em"} is spaced out.

Spans are also how Magic Move identifies the
elements that fly between two slides — [E = mc^2]{.magic-formula} on both
slides makes the formula travel instead of cutting.

3. Your own CSS

Two keys load real stylesheets.

css: — an inline rule

Repeat the key to add more; each occurrence is appended:

===
title: My deck
css: .surprise { color: #d94f4f; font-weight: 700 }
css: .block-table td { padding-block: 0.4em }
===

cssFile: — a stylesheet next to the .tac

For anything longer than a couple of rules, put it in a file beside the deck.
cssFile: (synonym cssFiles:) takes one path or a comma-separated list:

===
title: My deck
cssFile: lecture.css, brand.css
===

Both keys work in a tac.config too, so a whole folder of decks can share one
stylesheet without repeating the line.

The CSS is injected into all three surfaces — the presentation window, the
presenter window and the print/PDF view — so a rule you write shows up
identically in the room and in the handout.

What you can target

The renderer's class names are stable enough to style against:

Selector	What it is
.presentation-root	The root of the whole presentation
.callout, .callout-alert, .callout-<name>	Highlight boxes
.block-paragraph, .block-list, .block-table	The ordinary content blocks
.code-block, .inline-code	Code
.tac-math, .tac-math-display	KaTeX output
.tac-icon	A /icon[…] glyph
.slide-quote, .slide-footer	Layout pieces

A slide's own class: / classes: key adds classes to the root of that slide,
which gives you a hook for rules that should apply to one slide only:

## The dramatic one
===
class: dramatic
===

.dramatic .block-paragraph { font-size: 1.4em }

No raw HTML

There is deliberately no raw-HTML escape hatch in .tac. Anything that
would need markup goes through
/component[…],
which keeps structure separate from presentation and means nothing written in a
.tac file can inject markup into the app.

Reach for the lowest level that works

A frontmatter key survives a theme change and a Tachyonn upgrade. A CSS rule
targeting an internal class does not, necessarily. If you find yourself writing
the same CSS in every deck, that's a sign it wants to be a
.tt theme instead.