Archive of Our Own ^beta

NB: ALL OF MY FICS ARE ON archiveofourown . org — GO THERE TO READ THEM (IF YOU'RE READING THIS ANYWHERE ELSE, THEN THAT SITE IS PHISHING YOU).

One small note, before everything else.  It's probably not worth noting, for most people, but that OCD part of me feels compelled to mention that technically, what everyone calls fonts are actually typefaces, e.g. Times New Roman, whereas the technical term “fonts” means specific variations, e.g. Times New Roman 12 pt. bold, which are instead called font-family in HTML+CSS....  OK, now on with the show! 🙂

On SITE Skins  ^{Contents ↑}

  [blah blah]
  ↓  Reading font site skin
  ↓  Paragraph alignment

Before we deep-dive into making a site skin, I need to mention something that I will repeat in the work skin section: what you see (per how each browser processes things differently, each user's browser settings, site skin, work skin, third party browser extensions, and a device's resources [e.g.: fonts]) and what the author intended / your readers see can vary greatly.  Even with something as simple as a standard Unicode character (in this example, taken from a comment on my Green Rain font header-note explanation: U+218B, which should appear as the number three “3” glyph rotated 180° to be upside-down [and italicized and made small] — ↋) can go unexpectedly oddly awry (in which the rotated “3” glyph appeared as a Creepypasta Thin Man, for some reason [so perhaps an HTML entity of ↋ {↋} or ↋ {↋} might be better choices]):

(zoom)

OK, now on with the show!

My purpose in this tutorial is to share what I've learned about Work Skins w.r.t. AO3 (in order to write in fonts other than the AO3 default), but I just now (06 Aug 2022) tried my hand at a Site Skin (for a reader's benefit) in order to change the fonts that I'm reading in (which raises the question of author-added text through reader-applied site skins, and chains thereof).  This section isn't itself an in-depth tutorial on Site Skins, just a quick-and-dirty How To that I wrote as a comment-reply and upgraded to a section for everyone's immediate use, but it gives the full code needed; all that you need is to copy-and-paste it into your Site Skin (instructions in next paragraph down), and change the example given (Comic Sans MS, Comic Sans) to whichever other font(s) you prefer (and always list several in case the first one isn't available on some device, or the second, or the third...) — and then hit Submit (preview the results of course, and edit if needed, but then just apply the Site Skin as you see fit).  If you need basic HTML training, then check out CodenameCarrot's excellent primer A Complete Guide to 'Limited HTML' on AO3 to start with, and there are a bunch of HTML tutorials on what functions here on AO3 (though a lot of them actually focus on work skins and site skins, not HTML as such), and there are many really good resources out there such as W3 and Khan Academy (it's free), though most places kind of assume that you're using inline or internal [header] HTML rather than the [external] CSS approach of AO3 and so they freely mix the two interchangeably (which means that you'll learn things that might not work the same way here [or at all, since some things are disabled on AO3]), and Google is (in this case, anyway) your friend (just search the term HTML and add a word or two related to what you want to do).

There's a good explanation of how to do this in ElectricAlice's Tumblr post, but the TL;DR of it is that you go to your AO3 Dashboard and click the Create Site Skin button.  Once you're there, Site Skin should be pre-selected by default, but if it's showing Work Skin, then hit the drop-down menu and select Site Skin; after this, give your new Site Skin a name in the Title edit field (maybe add a description, but you can always do that later if you want).  There are Site Skin tutorials available, but finding them among the works that only give you {site skins and not a tutorial, and tutorials that aren't about about site skins} might be tricky, so here's one that covers the basics: Useful CSS for readers, by ao3commentoftheday and memorizingthedigitsofpi.

Then it's time for the CSS rules that you want — in this example, I'm looking at only one rule, the font itself (taking Comic Sans as an example).
  NB:  If you normally use AO3 with some particular site skin (e.g.: Reversi, taking a popular example [and Mewsmodeus points to two excellent variations in Dark Catpuccin and Reversi++, with tons of details that you can work from]), and you want to keep using it, and simply want a different font or font color or whatever added to that, then when you make your site skin you'll want to click “Advanced” just beneath the big edit field with all of your CSS in it, then click “Add parent skin” (the button in the lower right of the newly displayed little section), and start typing the name of the parent skin to which you want to chain your site skin (it'll suggest skin names as you type) — and then hit submit once you've chosen your parent skin, obviously.  If it doesn't look right, you can always edit your site skin as needed.

/ * NB: I started with the asterisk “*” as a wildcard to cover anything that it can that isn't already covered, but please note that this is potentially far too sweeping and probably a terrible idea. * /
*,
body,
.toggled form,
.dynamic form,
.secondary,
.dropdown,
blockquote,
pre,
kbd,
tt,
code,
var,
pre,
samp,
input,
textarea,
.heading .actions,
.heading .action,
.heading span.actions,
span.unread,
.replied,
span.claimed,
.actions span.defaulted,
.datetime,

/ * And if you want all of the story-text — the actual reading material itself — in the fics to do the same thing (font family, color, whatever), then also add the following * /

p,
.userstuff h2,
.userstuff caption,
.userstuff table,
.userstuff td,
.userstuff col,
.userstuff tr,
.userstuff thead,
.userstuff tfoot,
.userstuff tbody,
.userstuff th,
.userstuff thead td,
.userstuff th a,
.userstuff th a:link,
{
  font-family: Comic Sans MS, Comic Sans;
}

  Top of site skin section  ↑

I modified the material from Plain Text Site Skin (by AO3), which is one of the Public Site Skins (and there are a bunch more that you can find in ElectricAlice's Ao3 Skins [sic] collection), and made a Site Skin for myself using the CSS code above, and tested it out.  It works!  This changed the entire page to Comic Sans MS (all but the AO3 Logo, the filters in the search page, and one or two others like these); the fic, the tags, the author, the comments — all in Comic Sans MS.

The one thing to keep in mind is that if you log in and use your Site Skin on multiple devices, then it will show the fics in Comic Sans only on devices that have the Comic Sans font in their system.  Even though it's pretty popular one, you might find yourself on a device that doesn't have it (maybe at work, or on a friend's computer) and you don't have permission to install it.  Just in case that happens, I suggest that you list a few of your favorite fonts as fallback options, which would look something like this:

font-family: Comic Sans MS, Comic Sans, Bradley, Times New Roman;

Doing that, the device would then try to use Comic Sans MS if possible (and Comic Sans if not), and fallback to Bradley if need be, going for Times New Roman as a last resort (and yes: this same arrangement and fallback routine applies to Work Skins).  You can always modify your Site Skin later and add more fonts, of course, but this is a starting point at least.  If you want heavier duty info, then please see the advanced materials at the bottom of this work for more sources (esp. AO3's full list of supported CSS properties and Dustnik's AO3 CSS Selector Ids and Classes at the start, and AO3's skin/873 at the end [26 Jan 2025 update:  Cf. Targeting specific AO3 work sections (not site) with CSS effects for an in-depth breakdown of how to find what's where in your AO3 works, and affect same with your work skin]).  Time passes, new CSS comes into existence, and AO3 evolves to add a few things safely over time (and possibly some things haven't made it to the official list of functional stuff, even though it's been functional and approved on AO3 for a long time; I could swear that I've seen some, but can only attest to knowing that some exist that aren't on the lists, not sure how long they've been functionally approved though); you might want to check compatibility of CSS stuff at caniuse, along with the usual suspects of MDN and W3 (in each of these, check the browser versions that support whichever specific CSS property you have in mind, since CSS isn't some monolithic go/no-go across the board).

The same basic principles as shown below for work skins can be applied to your site skin, if you want to make the font larger or a different color, or read all fics in paragraphs of align="left" or align="justify", etc..
  For example (since I code my fics' paragraphs' alignments directly into the HTML [the original uploads by individual p, the later stuff by div], rather than using a work skin which would be lost in some download filetypes): if you wanted to turn my fics' mostly-justified paragraphs into left-aligned, then you might want something like [align|=justify]{text-align: left;} (per this r/AO3 thread), whereas if you just wanted to read everything in left-aligned regardless of any author's original alignment, then you might prefer something like .userstuff p {text-align: left !important;} (per this other r/AO3 thread, or as I show in the usual blockquote code structure in the How To AO3 tutorial).
  Just keep in mind that if you have a Site Skin turned on, then it will override your Work Skin, so you won't necessarily see your fic's Work Skin mistakes, or might think that it's broken [due to the Site Skin overriding it] when it's actually working perfectly well).
  Top of site skin section  ↑
 

My heartfelt thanks go out to JeiceValacka for having asked the question that prompted this potentially vital entry for any readers seeking to do the same! ❤️

Sidenote:  I couldn't help chuckling over the navigation panel's source headers recently (~mid-Oct 2023) 😉:

Choices
[Dashboard, Profile, Preferences]
Pitch
[Works, ...]
Catch
[Inbox, ...]
Switch
[Co-Creator Requests, ...]

NB:  I know essentially nothing about site skins beyond what you see above and what basics translate from work skins, and have no use for reading AO3 on my iPhone or Android, so as far as modding a site skin to react to your using different devices or browsers, I can only point you to u/cjrecordvt's (“Definitely not an agent of the Fanfiction Deep State”) instructions (below) that I found in an /r/AO3 subreddit thread and a tutorial for the same (recommended in another thread):

[...] as long as the devices are different widths. It's going to require some jiggery pokery, though.

1. Set up the tablet skin
   
   1. Create Site Skin at ao3.org/skins
   2. Give it a name like "t1mepiece tablet"
   3. If you have custom CSS you want to use, you can enter it in the box
   4. Scroll down to Advanced: Show
   5. You want this for tablet: in Media, choose "only screen and (max-width: 62em)"
   6. You said you use Reversi (good choice): scroll down to Add Parent Skin and enter "Reversi"
   7. Update
2. Set up the desktop skin
1. this is only necessary if you're tweaking the CSS - if so, repeat steps 1.1-1.7. you don't need to set the fallback media format
3. Set up the use skin
1. Create a skin
2. Give it a name like "t1mepiece actual" or as you prefer
3. Scroll down to Advanced: Show
4. Add Parent Skin #1: "Default"
5. Add Parent Skin #2: "t1mepiece tablet"
6. Update and Apply

That should work, though I'm not on a set of devices to test at the moment. When you're adding skins in Step 3, the most restrictive skin should be the highest number (the order they're listed doesn't matter as long as the numbers are set).

NB 05 Jun 2024:  Before you drop a site skin on your reading, or a new declaration into your skin, keep in mind that it will go squirrelly on you sometimes / eventually; I was reminded of this today when someone's site skin [with TL;DR no weird fallback fonts] turned the Unicode character U+218B (a 180° rotated 3) = “↋” into a Creepypasta Thin Man glyph (so perhaps an HTML entity of ↋ [↋] or ↋ [↋] might be better choices), much like how years ago I had signed my MS e-mail replies to my second wife with “:-)” (ASCII smiley face emoticon) which it changed automatically to “🙂” (smiley emoji) and her e-mail (Yahoo, I think, though possibly Hotmail) turned the “🙂” into “J” (the capital letter J — it was a while before she bitched me out, thinking that I was signing off with my first wife's initial... I was able to prove that I hadn't been, but the takeaway here is that what you read might not always be what the author wrote [come to think of it, a similar issue arose once in a Facebook geek-dating group: I had written my bio, and there was a smiley face “🙂” in it, but when I copied the bio from OpenOffice and pasted it to the FB Edit Field, the smiley had become a camera “📷” / “📸”, which I didn't notice until much later, and that portion had been an aboveboard reasonable spot to have a smiley, but a sickening one to have a camera]; the same caveat applies to websites the links to which you send to someone: they might have “adult” ads on them that you have no idea about because you use multiple ad-blockers and almost never see ads anywhere, as when I sent my [adult] daughter a link to a site for online copies of the original decades-running The Fabulous Furry Freak Brothers comics).

If you have a certain look in mind, but not a font name that you can think of, and so want/need to browse a bunch of fonts for inspiration and font names, you can try Wordmark, Google fonts, Microsoft 365 Cloud fonts, Adobe foundry, Adobe, and probably any other major font source (even a Google for "fonts" might be useful, though less chance of a given font being on any reader's device).

BTW, I just now (29 Jun 2025) ran into this excellent write-up on making site skins that might guide you in a more-detailed way for general application: Nerentina's Dracula theme for AO3.

Concise ten-cent tour to font colors  ^{Contents ↑}

Some people might need a no-frills quick-and-easy stripped down version of “how to” on this (thank you, EvenBrighterMarle, for having asked!) — no giant list of details and explanations.  If that's you, then here's the TL;DR of this whole tutorial:

1. Open a new tab and find the colors that you want (or set of fonts in your font-family declaration, being sure to name your most-preferred fallback option first and least-preferred fallback option last), and write down the RGB/RGBA or HEX code values (or HSLA too, as of 31 Mar 2023!).
2. Go to {My Dashboard ► Skins ► My Work Skins ► Create Work Skin}.
3. Write each color's work skin rules something like this:

   #workskin .my-favorite-blue {
  color: rgb(0, 0, 255);
}

   or

   #workskin .friendly-green {
  color: #27b300;
}

4. Save your work skin (you can always edit it all that you want later, as many times as you want) with whatever name you like (again: you can always change that name).
5. Go edit your fic to apply your work skin (halfway down the page to the Associations: at the bottom of this section you'll see a field named Select Work Skin; click the Edit Field's pointer and it will present you with a list of all of the Work Skins that you can choose from).
6. Go edit the fic's chapters by using the HTML field (not the RT GUI) and writing (around the words that you want to colorize) this (depending upon what you choose to name your rules, of course):

   One day, the <span class="friendly-green">Incredible Hulk</span> realized that the sky was <span class="my-favorite-blue">a really deep blue</span>, and he was happy.

After you save your fic's edits, that section should look something like this:

One day, the Incredible Hulk realized that the sky was a really deep blue, and he was happy.

though likely with a slightly different blue, since I used my own specific work skin rules in this show-and-tell result, rather than the exact same wording as the one listed in the example rule. 🙂

If you have a certain look in mind, but not a font name that you can think of, and so want/need to browse a bunch of fonts for inspiration and font names, you can try Wordmark, Google fonts, Microsoft 365 Cloud fonts, Adobe foundry, Adobe, and probably any other major font source (even a Google for "fonts" might be useful, though less chance of a given font being on any reader's device).

Preamble  ^{Contents ↑}

CSS is just HTML, or rather: it is the same exact language, but what is now CSS used to be part of what was the whole of HTML and became reclassified as magically separate from the general stuff for semantic reasons.  It's not some different language: that change happened somewhere in the past couple of standards' changes over the decades.  If you knew HTML a couple of decades ago (i.e.: '90s), then you already know how to do what is now called CSS (apparently they forced it to split from the rest of HTML back in '96 for semantic reasons), and you just need to know where to put it now in order to get it to work the way you're used to it doing.  If you need basic HTML training, there are a bunch of HTML tutorials on what functions here on AO3 (though a lot of them actually focus on work skins and site skins, not HTML as such), and there are many really good resources out there such as W3 and Khan Academy (it's free), though most places kind of assume that you're using inline or internal [header] HTML rather than the CSS approach of AO3 and so they freely mix the two interchangeably (which means that you'll learn things that might not work the same way here [or at all, since some things are disabled on AO3]), and Google is (in this case, anyway) your friend (just search the term HTML and add a word or two related to what you want to do).

My only reason for “coding” (which this isn't, really) in AO3 is to enable a slightly more than basic typing (e.g.: alignment, typographical emphasis [bold, italic, etc.]), so that I can [judiciously] apply different fonts or colors.  I'm a book reader (i.e.: dead trees), and although I value the capabilities of webpages' layouts and such, my writing presentation is aimed at simpler things — but fonts or colors aren't immediately available by GUI nor even inline HTML (for some very good reasons, I'd say).  Nevertheless, the course of events brought me to the question of [CSS] work skin rules to perform these functions, and then on to the thought of applying them to the Summary section solely to demonstrate these same effects, at which point I noticed that although one can certainly cause them there, those effects (except for the choice of font, oddly enough) notably don't appear when viewing the same summary as listed in the search results page (and so I saw no impetus — for my purposes — to add the CSS code for higher level effects, if they'd be seen only when in the fic itself, where you'd be able to see them in the header Notes through straight HTML in any event).

It started when I wanted to select a couple of lines of material to be color coded in a story, but that wasn't vital, so I ignored it — after all, why go to such effort for so little added value?  Then eight months later (three days ago, in fact), I discovered that “Hồ Chí Minh” and “phở gầu trứng vịt” wouldn't render properly in AO3's default font of Lucida Grande (though this varies per browser — this was a problem in Chrome, but rendered perfectly well in Firefox): they should read “Hồ Chí Minh” and “phở gầu trứng vịt”, and I'm a stickler for clear diacritics, so I spent a couple of hours mucking about with CSS in general (useful to ground what I learned afterward on AO3).  I use Times New Roman in my own documents and .pdfs (and it seems that I'm not the only one to think that it might be preferable to the current font defaults, but there's good reason against it: most people can read sans serif just fine [with the exception of capital Ii vs. lowercase Ll], personal preferences aside, and many people have trouble reading serif fonts online, so it's better to default to sans serif whenever possible), and have no diacritics problems, hence hadn't noticed it on AO3 until now.

Basic research

Having found AO3's Public work skins (and work skins and site skins that are available as meta-fics, rather than officially public skins as such), and notably Homestuck (see this example for its “How to” and this one to see how that should look), I saw how the external CSS method isn't terribly different from raw HTML.  The Homestuck work skin uses only Courier as its default (with a fallback option of monospace), which makes it easy to focus solely on font color and size changes and highlighting, or coding errata (for example: although it talks about various characters' individualized fonts, it contains rules for the Caliborn character but not for the Captor character, so if one were to choose the class .captor, then the span of text selected for Captor wouldn't be in a font individualized to them, and so would default to AO3's standard Lucida Grande [or if you right-click to inspect the element: 'Lucida Grande', 'Lucida Sans Unicode', 'GNU Unifont', Verdana, Helvetica, sans-serif;]).  That caught my attention because MS specifies Courier New for Tiếng Việt (which is where the diacritic issue came up, after all) — in other words: though a font might be able to display some glyph+diacritic, it won't necessarily display it properly due to character repertoire issues of the font chosen and/or [browser / document / printer / etc.] layout engine.

Here's a sample of the Homestuck work skin, showing two rules (.dad and .pipefan413); this shows that rules are permitted to be identical, and that a rule can contain multiple declarations (four in this case: font size, and weight, and family [listing two values], and color):

#workskin .dad,
#workskin .pipefan413 {
  font-size: 14px;
  font-weight: bold;
  font-family: courier, monospace;
  color: #4b4b4b;
}

The Undertale work skin turned out to be far more streamlined (lacking multi-functioned classes) and much smoother (with intuitive names) than Homestuck was, and made it so simple to see how to arrange a font-family element.  The Basic Formatting work skin was beautiful, mostly just duplicating some HTML and RTF, and adding only font colors.

Here's a rule from Undertale (a simple rule, here: just one property [the font family] and five preferred values):

#workskin .comicsans {
  font-family: 'comic sans ms', 'comic sans', 'chalkboard se', 'chalkboard', cursive;
}

and a rule from Basic Formatting (which has similar simple rules for indents and spoilers and borders and so forth):

#workskin .font-green {
  color: green;
}

NB:  You might be tempted to emulate the Homestuck example and incorporate <b> / <strong>, or <i> / <em>, etc. into your work skin rules.  That's up to you, but the CSS will be stripped if the reader downloads the fic, so those changes won't show up.  The HTML would remain upon download, so it might be better to just stick with that.
  This raises the question of the difference between <b> and <strong>, or <i> and <em> for screenreaders, as a sidenote.  In principle, they don't pronounce <b>boldfaced</b> or <i>italicized</i> differently, but should be able to stress <strong>strong</strong> and <em>emphasized<em> words differently from the surrounding text; to my understanding though, some do and some don't, and apparently those that possess the capability don't have this as the default setting (and since most people don't fiddle with their settings...), thus leaving no practical difference in using <b> vs. <strong>, or <i> vs. <em>.
  Worse still, aside from proofreading visually, I also use a screenreader (a free one, which unfortunately doesn't have settings for strong or emphatic voices) on the final product in order to hear the flow and catch screwups that my eyes skimmed right over (and sadly, there are a few) — which is how I can add my own two cents and mention that words within the less-than/greater-than symbols <such as these words right here> will be skipped entirely by some non-zero subset of screenreaders (so if you're listening to this on a screenreader, or reading it by braille, a lot of this tutorial might be missing some vital info, and I don't know how to correct for this).  You can find more about screen reader / TTS problems and solutions in my meta about making and fixing series, in the section about HTML w.r.t. different sizes of dashes and breaking and non-breaking blank spaces (no, TTS and series and dashes and spaces have nothing to do with one another, but it sort of grew organically...).

So I tested multiple fonts all at once at Wordmark (those already installed, at least) to see which ones would turn “ầ” into “ầ”, “ị” into “ị”, & “ồ” into “ồ” (also checking some individual fonts not installed on my system).  While I was at it, I also checked to see if these fonts would fix the problem with “̄S” (combining macron) or “̅S” (combining overline, or combining overbar), and found that I'd have to keep using the “S̅” that I had found at fsymbols.com (or more simply the HTML of “S&#773;” = “S̅” {which looks too far right-shifted over some glyphs, as in the case of “O̅”}, but they're both just too long for use with lowercase letters, as with “o̅” vs. the more satisfactory “ō” from my computer's character map, but keeping the HTML for uppercase letters, since the char map's version “Ō” simply doesn't suit).

  If you're already looking at some words on a website, and you like the font that you see, but don't know which font that is, then you can inspect element or arguably more easily view source page in order to see what the site lists in its CSS rules.  For that matter, if you're on a computer (or maybe a 'phone?), you can simply copy one of the words and paste it into a document and see which font or font-family your word processor says it is; if they embedded the font into the site, then you'll know the exact font, but more likely it's a CSS rule, and you'll at least have narrowed it down to a small set of options that you can then look up easily and see which ones you like.  (Alternatively, you could try some font identifying site such as https://www.myfonts.com/WhatTheFont, but that's really more if you're looking at a picture of words, rather than actual text on the page.)
  NB:  while Vietnamese diacritics sparked all of this, I still had an eye for generalizing a single rule declaration in order to keep things simple across multiple diacritical needs and orthographies.  In this case, were I seeking only to create a declaration of font-families specific to Vietnamese and not consider flexibility for other languages (such as Greek, as shown farther down) at the same time, then it might have been better to create one work skin rule per language orthography, and seek a decent font-family specific to each language.

Just as a quick aside, since I mention the character map there: if you have a need for unusual characters (glyphs that aren't on your keyboard, such as {œ, ‰, or ≥}, or letters in other alphabets, or special mathematical symbols), the character map is easy to access.  On a Windows system, just click the windows logo / icon “⊞ ” in the lower left corner of your computer screen (or click into the search field, if you're on a newer version — or just press that key between the FN and ALT keys), and start typing “character map”; by the time that you get as far as “cha” or maybe “char”, the map should show up as an option (you might want to pin it to your taskbar, if you're liable to use it often); as ever, searches are your friend, if you can't access the Windows character map in the usual fashion.  On a Mac, hit Command-Option-T or ⌘-⌥-T (though I'm not boned up on Mac, so you might want to search online if needed).  I'm even less versed in 'nix, so you'll have to look into Gucharmap / GNOME Character Map for yourself (I'd too likely misguide you were I to try my hand with that).  For cell 'phones, I don't know how well the character maps match what I'm used to on a computer, but you've probably noticed that when you hold a key on your iPhone screen or Android screen, a string of alternative characters will pop up.  Of course, you can always just use the maps directly through MS office or its free equivalents of OpenOffice and LibreOffice.  Note that not all character maps are equal (it's “complicated”), and the characters presented within a given font also don't necessarily match those of another font and simply look a little different (obvious example: any normal font vs. the Wingdings and Webdings fonts) — and just because you can see some specific symbol in some particular font doesn't mean that the reader will have that font available (hence the symbol might look a little different in a similar font, or it might be an entirely different symbol — for example, try finding “␢” on your character map, or displaying Klingon font glyphs [and there are many tlhIngan Hol fonts to consider, and their pros and cons] without first installing a modified private use font map for it).

So: all of that gave me some suitable fonts to satisfy my criteria (in order of descending priority):

1. Fix the diacritics by placing the grave accent above the circumflex;
2. settle for nearly above, if I must;
3. deal with it being at the leading (left) edge if absolutely necessary.
4. Use sans serif fonts if at all possible, in order to minimize contrast with the surrounding text;
5. fallback to serif fonts that at least functioned for the diacritics (just in case none of the sans serif fonts were loaded to the reader's device).

For example: let's say that you had a rule that read font-family: courier, monospace;.

1. Their system will check its fonts for courier;
2. failing that, it will then check for monospace;
3. if it doesn't have that one either, then it will go down AO3's default font-family in the same manner: 'Lucida Grande', and if it can't find that, then it will try for 'Lucida Sans Unicode', then 'GNU Unifont', and then Verdana, and Helvetica, or finally any sans-serif;
4. and if it had none of those named fonts, then it would try to display in whatever sans serif font it had available (presumably it would have one, I'm sure, but if not, then obviously it would just display whatever was their device's or browser's default).

Working all of this out decided the question of the older and mostly irrelevant issue of font colors: as long as I had to make a work skin to fix the diacritics, why not incorporate those too (particularly since I'll likely enough add to it over time)?  For example... add some rules for red, green, and blue text capability (if you look carefully, you'll note that I didn't quite use Basic Formatting's green, having instead chosen to go with #27b300).  I even tossed in bright yellow and pale yellow highlighting (N.B.: the HTML term for highlighting is mark, but meh: that ain't natural [FWIW, if you can find some sort of use for this info, you can use <mark> on AO3, but the results are not what you'd expect: in both single- and multi-chapters' comments, summaries, header-notes, and footnotes it does nothing to whole paragraphs, but will cause single words (or non-paragraph strings of words) to become their own paragraph, but has zero effect within the actual main-fic-body .article {where the <mark> and </mark> simply get deleted instead}.]) options (though I didn't see myself as likely to use these outside of tutorials, I did end up doing so for the illustration of an admission ticket in an old story]).  Once more unto the web, this time for a color picker (N.B.: you might want to stick to the standard 140 [or perhaps 147, or even 216] web-safe colors, since pretty much all browsers will take these names or values, but older browsers don't always support other [more modern, wider variety] colors and will have to default to the closest thing that they can approximate such other colors with).
  NB:  When using W3's color picker, you can click on the interactive figures and things, but if you enter a color code into an edit field, then don't simply type the numbers (e.g.: 255, 0, 0) or you'll get perfectly good results that don't match what you intend; type it in as full HTML (e.g.: rgb(255, 0, 0), and you'll get the color that you would expect from a given triplet).
  I like W3's layouts, but different people need different interfaces; you might prefer something like Adobe's color wheel, or the old slider bar and square.

NB:  One point to ponder when you do all of this is color blindness.  It comes in more than one flavor, and really would take a lot more to cover well than I have any qualification to even attempt, but you might want to look at HTML palettes for color blind spectra.

Results  ^{Contents ↑}

  [Confounded  concatenations   combinations  compositions !]
  ↓  Furigana / yomigana / rubi
  ↓  My early work skin 👈
  ↓  Make your links blue
  ↓  Invisible ink
  ↓  Work skin character count limit (How long is it?)

After all of that, here's my CSS rule to de-concatenate diacritic marks and the other rules mentioned so far (plus a few related rules) to put into your own skin and work from there, if you'd like — it pushes 15 fairly popular fonts before giving up, so is likely robust against diacritics failing from dearth of font choice (as long as the reader hasn't disabled creator's style, at any rate [and it will also fail in downloads {though this can be fixed after the fact}, or due to browsers / settings thereof, or third party apps overriding it]).
  N.B. 1:  The diacritics rule (in the work skin below) is great for most purposes, but it's not a golden ticket if you try something really... unusual.  Here's a special case: I wanted a minuscule (lower case) letter “u” with combining {caron below, diaeresis, and acute}; the order of applying the diaeresis before the acute matters, though the caron below can be inserted wherever.  Using my computer's character map, I produced “ǘ̬” with ease, but trying to make the three combine using HTML produces an unsightly mess “ú̬̈” (at least in AO3's default site skin on my WIN 10 OS with whichever fonts are in my computer — the diacritics might be perfectly legibly separated on your device).  I tried mixing the character map parts with the HTML parts in various combos, and it was still a mess; I tried a grapheme joiner &#847;, and no luck (maybe there's some HTML for an invisible diacritic spacer between the diaeresis and the acute?); I tried the character map combo with and without the diacritics CSS “...ʔu̬ːǘ̬^h?” [which is without] and “...ʔu̬ːǘ̬^h?” [which is with], only to see the acute shrunken and the caron offset to the right (though the bolder diaeresis was nice) by the CSS; it looked OK only when I used the character map combination alone.
  Similarly, in OpenOffice I can produce the spherical coordinate symbol theta hat (shown here as an image of how it should appear) using U+03B8 and U+0302 on the character map (though with the circumflex offset to the right with approximately zero kerning, rather than actually combining above the theta), but renders on my browsers as a glyph thus (badly on default AO3 font-family, at least for me): θ̂ without the CSS and θ̂ with the CSS (with the same results as the first coming from straight HTML of &#952;&#770;, with more info on the combining circumflex problem on StackExchange, and just general reference in Wikipedia's combining diacritics article, as well as a decently interfaced list and a more linear layout at the Unicode Consortium).
  That later theta-hat problem was 01 Feb 2024 — 28 days later (oh my: RAGE-ZOMBIES! 😲), however: borrowing some CSS from Stanford Encyclopedia of Philosophy Archive's Mathematics HTML Sampler did the trick (NB: though I had needed it for the practical reason of the figure caption in the second [contrasting] illustration in chapter 3 of Sonic's Redemption for quite some time by then, it had already been using just an archived image for so long that I simply left it as-is, rather than fix what wasn't broken, now that I had some functional CSS to correct the original [dissatisfactory] issue):

#workskin .abovestrike { /* renamed here from “overstrike” to abovestrike because this set of rules is to place glyphs above other glyphs (I just felt the Ghost of the Curse of Zalgo walk over my grave...), not to make a palimpsest (as by overstriking on a typewriter) */
  position: relative;
}

#workskin .abovestrike span {
  position: absolute;
}

#workskin .abovestrike .up { /* for above <i>italics</i> (and “<em>emphatics</em>”, if that will ever make more than a pedantically semantic difference) */
  top: -0.5ex;
  left: 0.2ex;
}

#workskin .abovestrike .hi { /* for above UPPERCASE MAJUSCULE */
  bottom: 0.5ex;
  left: 0.0ex; /* modified here from orig. left: 0.5ex */
}

in order to use

<span class="abovestrike">θ<span class="hi">ˆ</span></span> (without my little diacritics selector) to get θˆ

or to use <span class="diacritics abovestrike">θ<span class="hi">ˆ</span></span> to get θˆ (where the diacritics selector actually caused some issue

and turned out to simply need to be attached to the circumflex's class [rather than the theta's] as shown here) <span class="abovestrike">θ<span class="diacritics hi">ˆ</span></span> to get θˆ (though that's still not quite as good as the one without the diacritics selector at all)

failed initially (at least on Chrome on my computer, and I didn't wish to tweak it with multiple special things for multiple environments, even if it were to prove achievable at all), but then I noticed that their CSS had explicitly shifted things to the right (and then that I really should have simply used the circumflex from my computer's character map as I did above, rather than lazily copy one from a quick Google and get an oversized ^ monstrosity... <sigh> 😑).
  A little further experimentation also showed some interestingly quirky results when placing the diacritics selector wholly separately before the others, between them, and as the innermost rule:

<span class="diacritics"><span class="abovestrike">θ<span class="hi">ˆ</span></span> yielded θˆ

<span class="abovestrike">θ<span class="diacritics"><span class="hi">ˆ</span></span> yielded θˆ (depending upon your screen's aspect ratio, you might need to hunt for the circumflex: look up one full row)

<span class="abovestrike">θ<span class="hi"><span class="diacritics">ˆ</span></span> yielded θˆ (below the theta)

  Mind, that was using just a regular [non-combining] &02C6; circumflex, rather than a combining &#770; circumflex.  The same again with a combining circumflex, on the other hand, comes out thus:

<span class="abovestrike">θ<span class="hi">&#770;</span></span> (without my little diacritics selector) gets us θ̂ (same problem as initially, just shifted to the LHS [left hand side] instead),

<span class="diacritics abovestrike">θ<span class="hi">&#770;</span></span> gets us θ̂ (same problem as initially, just shifted to the LHS [left hand side] instead),

and <span class="abovestrike">θ<span class="diacritics hi">&#770;</span></span> gets us θ̂ (same problem as initially, just shifted to the LHS [left hand side] instead);

whereas <span class="diacritics"><span class="abovestrike">θ<span class="hi">&#770;</span></span> yields θ̂ (same problem as initially, just shifted to the LHS [left hand side] instead),

<span class="abovestrike">θ<span class="diacritics"><span class="hi">&#770;</span></span> yields θ̂ (up one full row, though less right-shifted)

and <span class="abovestrike">θ<span class="hi"><span class="diacritics">&#770;</span></span> yields θ̂ (below the theta and left-shifted)

  Word to the wise: there's some chance that something simply can't be done, but if you're stubborn^H^H^H^H^H^H^H^H determined^W bullheaded enough... just maybe you'll find a solution anyway. 😉

  Side-note: for a conlang, I did use a modified rule in order to align an umlaut &#168; over the ⟨l⟩ in “loloöll̈olo” (I mucked around with a combining diaresis &#776;, which is what should be used in this instance, but it wasn't cooperative and I wasn't in the mood to correct it properly, since the semantics of umlaut vs. diaresis were irrelevant to my goal of getting two dots to center above a glyph).  If you need to do the same or similar, I settled upon the following for use with an umlaut over a lowercase ⟨l⟩:

#workskin .abovestrike .high {
  bottom: 0.5ex;
  left: -0.3ex;
}

  It annoyed me though, so I fixed it, the following mod. being for use with the proper combining diaresis &#776; (rather than the earlier and semantically inappropriate umlaut &#168;) over a lowercase ⟨l⟩:

#workskin .abovestrike .high {
  bottom: 0.5ex;
  left: 0.85ex;
}

  Top of results section  ↑

  N.B. 2:  Sometimes a given diacritic or combination of them will render perfectly well (or reasonably so, at any rate) in one browser, but not in another (for example: without the diacritics work skin rule, “gầu” looks semi-OK in Firefox on my computer, but is an unintelligibly compacted pile in Chrome, and likewise “vịt” is aligned properly in Firefox on my computer, but offset [not badly, just annoyingly] in Chrome), so you should check your diacritics' results in the more popular browsers, not just one, if at all possible.

  N.B. 3:  I haven't included any rules for ruby because I originally hadn't wanted to rely on CSS (though if you are so inclined, there's at least Elsepth's Ruby Text work skin) and have it fail when readers disable it (or when downloaded in certain ways, etc.); as of 31 Mar 2023, support of Japanese ruby HTML (furigana, yomigana, rubi) became available (cf. Admin Post 25456, item 0.9.338 re. AO3-6464)

• basically negating the need to use ^superscript workarounds such as 蟲^{^むし} (⟨mushi⟩ = insect / worm) (with these color coded highlights present here only to keep portions clearly separated in different results, and not appearing in your own normal use of ruby unless you add similar such highlights for some reason),
• so that one can now write simply <ruby><rb>蟲</rb><rp>(</rp><rt>むし</rt><rp>)</rp></ruby> and the ruby text will come out on top of the main text as one would expect 蟲(むし) in those browsers that support ruby
• — in those that don't (which would include some of you reading this, I suppose), the fallback parentheses will look like 蟲(むし)
• (personally, I prefer superscripting as the fallback instead, without the parentheses at all, so that <ruby><rb>蟲</rb><rt>^むし</rt></ruby> will give furigana when the ruby works and a following superscript-without-parentheses when the ruby doesn't, looking like this 蟲^むし, but that's just my own preference;
• for those of you who might want to have the fallback use parentheses and superscript: <ruby><rb>蟲</rb><rt>^{<rp>(</rp>むし<rp>)</rp>}</rt></ruby> which does keep it as furigana format when ruby is functioning and does go to superscript text with superscript parentheses upon ruby failure, looking like this 蟲^(むし);
• if you want both, but don't want the parentheses to be in superscript, only the text, then just place the <rp>(</rp><rp>)</rp> outside of the  pair like this <ruby><rb>蟲</rb><rt><rp>(</rp>^むし<rp>)</rp></rt></ruby>, and it will appear thus 蟲(^むし) instead).
• I mention all of this specifically because although the ruby does work in downloaded HTML, .pdf, .azw3, and .epub, it fails [currently] in .mobi.

  Top of results section  ↑

My early work skin:

This is what I came up with, after fiddling around for a while.  I needed only a simple couple of rules for red, green, and blue font for one fic just for a single splash of color, and another rule for legible diacritics (in that same fic), but OCD testing things out led to one thing and another, and ADHD suggested other uses for small splashes in other fics...
  If you have a certain look in mind, but not a font name that you can think of, and so want/need to browse a bunch of fonts for inspiration and font names, you can try Wordmark, Google fonts, Microsoft 365 Cloud fonts, Adobe foundry, Adobe, and probably any other major font source (even a Google for "fonts" might be useful, though less chance of a given font being on any reader's device).
  (NB 05 Jun 2024:  Before you drop a work skin on your fic, or a new declaration into your skin, keep in mind that it will go squirrelly on your readers sometimes / eventually; I was reminded of this today when someone's site skin [with TL;DR no weird fallback fonts] turned the Unicode character U+218B (a 180° rotated 3) = “↋” into a Creepypasta Thin Man glyph (so perhaps an HTML entity of &#8587; [↋] or &#x218B; [↋] might be better choices), much like how years ago I had signed my MS e-mail replies to my second wife with “:-)” [ASCII smiley face emoticon] which it changed automatically to “🙂” [smiley emoji] and her e-mail [Yahoo, I think, though possibly Hotmail] turned the “🙂” into “J” [the capital letter J — it was a while before she bitched me out, thinking that I was signing off with my first wife's initial... I was able to prove that I hadn't been, but the takeaway here is that what you write might not always be what the reader reads [come to think of it, a similar issue arose once in a Facebook geek-dating group: I had written my bio, and there was a smiley face “🙂” in it, but when I copied the bio from OpenOffice and pasted it to the FB Edit Field, the smiley had become a camera “📷” / “📸”, which I didn't notice until much later, and that portion had been an aboveboard reasonable spot to have a smiley, but a sickening one to have a camera]; the same caveat applies to websites the links to which you send to someone: they might have “adult” ads on them that you have no idea about because you use multiple ad-blockers and almost never see ads anywhere, as when I sent my [adult] daughter a link to a site for online copies of the original decades-running The Fabulous Furry Freak Brothers comics]):

#workskin .diacritics {
  /* This is the rule that fixes the broken diacritics in Tiếng Việt (as demonstrated right there, vs. the way that it comes out without the rule applied: Tiếng Việt in the “<code>” font-family [i.e.: font: normal 0.857em 'Monaco', 'Consolas', Courier, monospace], and Tiếng Việt in the regular AO3 default font-family [unless you have a site skin or third party app overriding this]) and all other diacritics issues that I've run into so far except for the spherical coordinate symbol theta hat , which is an image there of how it should appear, but renders as a glyph thus: θ̂ without the CSS and θ̂ with the CSS (cf. compositions and esp. theta-hat re. details and solution) — though if you want your diacritics' color(s) to differ from your letters' color(s), that could be trickier */
  font-family: Lucida Console, Arial, Ebrima, Helvetica, Verdana, Segoe UI, Calibri, Candara, Corbel, Microsoft Sans Serif, Tahoma, Times New Roman, Cambria, Constantia, Trebuchet;
}

#workskin .handwriting-printed {
  font-family: Segoe Print, Ink Free;
}

#workskin .handwriting-fluffy {
  font-family: Noteworthy;
}

#workskin .handwriting-cursive-scrawl {
  font-family: Bradley Hand ITC;
}

#workskin .handwriting-cursive-neat {
  font-style: italic;
  font-family: Segoe Script, Lucida Handwriting;
}

#workskin .handwriting-cursive-fluffy {
  font-family: Sacramento, Lucida Handwriting;
}

#workskin .handwriting-cursive-fancy {
  font-family: Freestyle Script, Snell Roundhand;
}

#workskin .handwriting-calligraphy {
  font-family: Monotype Corsiva, Harrington;
}

#workskin .typeset-manuscript {
  font-family: Lucida Blackletter, Luminari;
}

#workskin .red {
  /* This is the rule that gives you red ink */
  color: red;
}

#workskin .green { /* If you want something fancy, such as splitting a character into one color on the left and one on the right, then try these suggestions on StackOverflow */
  color: #27b300;
}

#workskin .blue {
  color: blue;
}

#workskin .highlight-bright-yellow {
  /* This is the rule that highlights letters, words, spans, paragraphs, entire divs (really any element, basically) in bright yellow... just like the paragraph that you're reading right now, for example */
  background-color: #ffff0099;
}

#workskin .highlight-pale-yellow {
  background-color: #ffffb399;
}

#workskin .highlight-blue {
  background-color: blue;
  opacity: 0.7;
  color: white;
}

#workskin .large-friendly-letters {
  font-style: italic;
  font-family: Segoe Script; /* NB: this is the original rule, which changed later */
  font-size: 5em;
  font-weight: bold;
  color: #27b300;
}

#workskin .greek {
  /* This is the rule that produces satisfactory Greek letters, for my purposes */
  font-family: Times New Roman, Georgia, Cambria, Constantia, Sylfaen, Candara, Sitka Banner, Microsoft Sans Serif, Palatino Linotype;
}

#workskin .edwardian {
  font-family: Edwardian Script ITC, Edwardian Scr ITC TT, ITC EDWARDIAN SCRIPT, Adine Kirnberg Script, Ballet, Medusa, Kunstler Script, Palace Script MT, Zapfino, Snell Roundhand, P22 Zaner, Aphrosine, Italianno, Slight;
  font-size: 2em;
}

#workskin .red-dwarf {
  /* This is the rule that gives us a reasonable facsimile of the font from the TV show Red Dwarf (the extra space around it is not necessary, it's there only in order to set some indent that I needed in a fic's emergency distress call opening; you can remove it by deleting the padding declaration) */
  font-family: MicrogrammaDBolExt, Eurostile Bold condensed, Microgramma, Eurostile extended, Newton, 'Pathway Gothic One', serif;
  color: red;
  font-weight: 600;
  letter-spacing: 6px;
  text-align: justify;
  /* There is not an issue with text-align: justify, but that linked comment is a learning moment: always check for typoes and that you've properly closed your elements (and HTML tags and CSS selectors) in reverse order of having entered them (though if it does cause you any trouble, then try adding display: inline-block; width: 100%; and note that the linked comment includes a link re. float: left; being potentially problematic). */
  padding: 5%;
}

#workskin .large-rosy-letters {
  font-style: italic;
  font-family: Edwardian Script ITC, Ballet, Medusa, Kunstler Script, Palace Script MT, Zapfino, Snell Roundhand, P22 Zaner, Aphrosine, Italianno, Slight;
  font-size: 3em;
  font-weight: bold;
  color: deeppink;
}

#workskin .large-rosy-shadowed {
  font-style: italic;
  font-family: Edwardian Script ITC, Ballet, Medusa, Kunstler Script, Palace Script MT, Zapfino, Snell Roundhand, P22 Zaner, Aphrosine, Italianno, Slight;
  font-size: 3em;
  font-weight: bold;
  color: deeppink;
  text-shadow: 6px 6px 12px #20202099;
}

#workskin .rosy-outline {
  font-family: Edwardian Script ITC, Ballet, Medusa, Kunstler Script, Palace Script MT, Zapfino, Snell Roundhand, P22 Zaner, Aphrosine, Italianno, Slight;
  font-weight: bold;
  font-style: italic;
  font-size: 3em;
  color: #FF1493;
  -webkit-text-stroke: 2px #FF1493;
  -webkit-text-fill-color: #FFFFFF;
}

#workskin .rosy-outline {
  color: #FFFFFF;
  font-size: 2em;
  -webkit-text-stroke: 2px #FF1493;
  text-shadow: 0px 4px 4px #0000FF;
}

#workskin .rosy-outline-blue-shadow {
  color: rgba(255, 255, 255, 0.9);
  font-size: 2em;
  -webkit-text-stroke: 2px rgba(255, 20, 147, 0.9);
  text-shadow: 0px 4px 4px rgba(0, 0, 255, 0.9);
}

Why is some of my hex code running four pairs?  The “99” at the ends of the highlighting color codes is to reduce the opacity so that they don't block text that they overlap on other rows (I went with a higher value so that I didn't have to fiddle with the colors themselves), just like the blue highlight includes “0.7”; for the record, AO3's CSS also accepts RGB and RGBA (i.e.: there are other color encodings that are not supported on AO3 at this time — though HSLA is now OK too, as of 31 Mar 2023!).  You can check the list of AO3's allowed CSS properties for more variables once you get the hang of the basics above.  And if you're thinking of changing from one font to another, but aren't sure which ones most people might have (and hence are likely to actually work as you want them to), then you might want to start with “core fonts” and then research further as needed.

Those last two on the outlined text-stroke property are a little iffy.  -webkit isn't supported by all browsers (though I had no problem on Chrome, Firefox, Opera, TOR, or Edge in a WIN 10 environment, nor on Safari in an iOS environment), and the color codes are funky in it on AO3's parser: the parser (which clearly accepts deeppink and other standard HTML names in the CSS rules) stripped standard names in that rule when I tested it (so: no “white” or “deeppink” or “blue”).  I included them for demonstration, using the hex values for a white fill #FFFFFF, deeppink outline #FF1493, and blue shadow #0000FF in order to make each section apparent, though the respective RGB equivalents of rgb(255, 255, 255), rgb(255, 20, 147), and rgba(0, 0, 255, 0.9) also functioned; even adding :hover to the end of the work skin name functioned with it (causing text of one look to take on a whole new look upon hovering one's cursor over it [which won't work on a 'phone]; you can test this quickly at JSFiddle).  Failed CSS might mean only no effect (as with a downloaded fic or disabled creator's style), or perhaps as bad as no text at all, but just as underlying HTML can act as a partial backup with boldface and such against failed CSS, one can likewise use a fail-forward trick to allow regular CSS to act in the event of .-webkit failure:

#workskin .large-rosy-shadowed-outline {
  font-family: Edwardian Script ITC, Ballet, Medusa, Kunstler Script, Palace Script MT, Zapfino, Snell Roundhand, P22 Zaner, Aphrosine, Italianno, Slight;
  font-weight: bold;
  font-style: italic;
  font-size: 3em;
  color: #FF1493;
/* If -webkit [below] fails, then color: #FF1493 [pink, above] will act as a failsafe (test your own with text coded for color: #0000FF [blue] which will be blue only if the -webkit code [below] fails to make it pink). */
  -webkit-text-fill-color: #FFFFFF;
  -webkit-text-stroke-width: 1px;
  -webkit-text-stroke-color: #FF1493;
  text-shadow: 2px 2px 2px #000000;
}

While not absolutely necessary, I imagine that you might wish visual examples of those effects, and many might not be able to visualize them from the raw code alone (though the following might not show you the results that I hope for, if your device doesn't contain any of the fonts in a given example's font-family declaration).  I haven't used any of my fonts very much (I see them as useful small touchups, to accent the fic sometimes, but not to rely upon them since too much takes away, and they won't be there if the fic is downloaded or the author's style is overridden), but you can see examples of them below, or if you'd prefer to see them in fics (live samples in their natural setting, as it were), then you can find the handwriting in my Walking Dead / Middle Earth fic (ch. 2, bottom), diacritics strewn in small places through a number of my fics (they don't really stand out unless you pay attention to detail, so I'll skip these: they look much the same in my fics as what you saw in this work's Preamble section's third paragraph where I'd written “Hồ Chí Minh” and “phở gầu trứng vịt” ), the “Edwardian” set (which you can see starts off with Edwardian, but contains other similar fonts) in ch. 17 of that same TWD / Hobbit fic, Red Dwarf in my Red Dwarf fic's opening scroll, Large Friendly Letters (and a bunch of colors and highlights) you've already seen at the top of this work (and can see in the sequel on making a series in AO3), and several cases of rosy letters (Large Rosy Shadowed and Large Rosy Shadowed Outline at the bottom of ch. 12 of my HP / Shield Hero / HSotD smut fic, and Rosy Outline Blue Shadow at the top of ch. 13 of that same smut fic).  I can't say which ones I've used the Greek in, since I do a fair bit with physics and stuff for fun, so it doesn't stand out in my memory, but probably the one with the most is the meta-piece on Gen 0 quarks, if you want to see how that font family looks in an otherwise typical Latin font setting.
  Alternatively, you can simply see them immediately below, albeit a little clashingly and not as they'd normally be used:

Greek, in AO3 default: Α α, Β β, Γ γ, Δ δ, Ε ε, [Ϛ ϛ], Ζ ζ,
Η η, Θ θ, Ι ι, Κ κ, Λ λ, Μ μ,
Ν ν, Ξ ξ, Ο ο, Π π, [Ϟ ϟ], Ρ ρ, Σ σ/ς (Ϲ ϲ),
Τ τ, Υ υ, Φ φ (ϕ), Χ χ, Ψ ψ, Ω ω; [Ϡ ϡ].
 
Greek, per my font-family: Α α, Β β, Γ γ, Δ δ, Ε ε, [Ϛ ϛ], Ζ ζ,
Η η, Θ θ, Ι ι, Κ κ, Λ λ, Μ μ,
Ν ν, Ξ ξ, Ο ο, Π π, [Ϟ ϟ], Ρ ρ, Σ σ/ς (Ϲ ϲ),
Τ τ, Υ υ, Φ φ (ϕ), Χ χ, Ψ ψ, Ω ω; [Ϡ ϡ].
Edwardian
Padding start ►|RED DWARF (from the TV show)|◄ End of padding
Large Friendly Letters
Large Rosy Letters
Large Rosy Shadowed
Rosy Outline
Rosy Outline Blue Shadow
Large Rosy Shadowed Outline

NB:  All of these look decent enough to me on a regular computer screen (though that last one, “Large Rosy Shadowed Outline” could use a little work), and might generally be alright on smaller screens (such as modern cell 'phones), but Anonymous brings up a key point in their excellent piece — the idiot's incoherent guide to learning css & html for ao3 in dystopia — in mentioning (in a comment) that “Dark font colors usually blend in the background if you're using Reversi Site Skin”; luckily, they also provide a viable workaround, by “...making use of the grey highlight so the important parts are legible and emphasized for users using either dark or light background.”  That's a point to consider when changing your font colors, since some site skins won't disable your CSS, but (as with the case of Reversi) might still make for difficult reading if you change your fonts' colors and don't account for potential site skin interaction.
 

BIG (or BUG ?) IMPORTANT NOTE:  Look again at the shape of my “Large Friendly Letters”.  Notice anything interesting?  I'll give you a hint: the letters in the example a few lines up from here are in a CURSIVE form, but the ones at the top of this tutorial are in PRINT.
  I changed my work skin before hitting the next 3 tutorials and so didn't pay it much heed (assuming that somehow the original printed form welcoming people to this tutorial was unaffected for some weird AO3-programming reason).  When I made the [chronologically later] tutorial preceding [in series order] this one (my AO3 primer), I copied this tutorial's “Large Friendly Letters” welcome mat (the big splash at the very top of this tutorial, as soon as you get past the header-notes) directly [from within its edit page source material, not from the resultant displayed reading page] but found that the result was still in printed letters even though it was long after having changed my work skin's rule (very obviously)... I copied the same material from my series tutorial [again: from within that one's edit page] and it came out in cursive letters even though they used the same CSS selector; I tried it again with the cursive sample above and it came out cursive (which was at least in keeping with the other case of the cursive form staying cursive).
  Just for the record, here are those same pieces copied from the originals and pasted here, so that I don't accidentally type them a certain way by memory, my only changes here being that I then wrote the HTML entities “&lt;” and “&gt;” explicitly over the less than “<” and greater than “>” symbols so that you can read them instead of the HTML performing its function:

• From this font tutorial's welcome sign (print):
  <big><b><i><span class="large-friendly-letters">DON'T PANIC !</span></i></b></big>
• From the series-tutorial's welcome sign (cursive):
  <big><b><i><span class="large-friendly-letters highlight-pale-green">Don't Panic.</span></i></b></big>
• From the example set above (cursive):
  <span class="large-friendly-letters">Large Friendly Letters</span>

Below is a set of those same three things' cropped screenshots (as they display for my tower's hardware, OS, monitor, browser, etc.) for your immediate reference (though this is only to show the font shape differences, since your hardware/software might render the color differently):

Aside from adding the <big> recently as back up against CSS failure (and <b> and <i> at some prior point), I hadn't done anything else to any of them (in fact, when I went to do that is when I noticed the print of the one and cursive of the other) — and fiddling with the highlighting didn't cause anything to change (other than the highlighting being present or absent, which is to be expected).
  I have no idea what's going on there.  I started testing it by changing the work skin font-family declaration, but decided against it; it's quirky, but I like it.  My reason for mentioning this isn't simply shits and giggles, it's to point to some of the odd glitches that can come up.  Copying directly from the print or cursive forms and pasting directly to the primer tutorial did result in the pasted form being the same as the copied form (if printed copy, then printed paste; if cursive copy, then cursive paste), even though they're calling the exact same CSS selector, hence the exact same work skin rule, hence the exact same font-family set.
  Before you say that I just need to clear my page cache, I did accidentally screw up the next tutorial's cursive form by typing over it (or was it pasting?) and turning it into the printed form without thinking.  That was disappointing, since I wasn't sure how I was getting either one of these per se (which is when I remembered the cursive form in the example set ❤️), and the page most certainly showed the print version then (vs. its previous cursive) and then the cursive again after pasting in from the example set.  It's not my cache.
  Just for the record, again, the entire rule's current form at the time of my telling you this is:

#workskin .large-friendly-letters {
  font-style: italic;
  font-family: Segoe Script, Noteworthy, Comic Sans MS, Comic Sans, MV Boli, "Ink Free", Lucida; /* NB: this is the later-updated font-family */
  font-size: 5em;
  font-weight: bold;
  color: #27b300;
}

  Top of results section  ↑

Links that actually LOOK LIKE LINKS <le gasp!>

One last thing.  I didn't waste my time marking every single link with HTML tags to <u>underscore</u> and CSS selectors to call a work skin rule to <span class="blue">turn the font blue</span> — it'd be easy enough, but think of the character space taken up in the footnotes! 😲  I did one better: created a rule that lets all of my contents' links (in the header, footer, summary, and main body... and even my author's name link, for some reason [meh: that's cool, too, I guess]) automatically become blue and underscored (i.e.: they just do it — period — no adding the CSS selectors anywhere within my work!).  I can't guarantee that it'll work on all browsers (I checked on Chrome, Firefox, Opera, MS Edge, and TOR in a WIN 10 environment; can't be bothered trying my iPhone's Safari, but ran it through some emulations [here's a page that tells you how to change your browser's user agent to test that way, though that doesn't seem to display as one would expect, so here's a free webpage to actually see the results]), but it'll surely help make your links pop for any readers not using a site skin or a third party browser add-on!  I pulled the link rule from cherryblossom's Dark Mode site skin, tweaked the font color for my own taste, added an underscore (not strictly necessary), dropped it into my work skin, and badda-bing (it works well enough that I even wrote a downloadable style for the browser extension Stylish [according to its download stats {edit: the site changes around, and I don't know when they changed this, but I checked just now, 14 Dec 2023, and one can no longer see the d/l stats on any style that you created, e.g.: I can no longer see them for https://userstyles.org/styles/stats/241963 — maybe they'll bring it back, but at least for the moment it's a “used to could” situation, and I figured that I should mention this in case you were to try to see yours and conclude that I'm full of shit here}, it can be had in {Firefox, Chrome, Opera, Safari, Dolphin, User JS, and Opera CSS}, though my only goal was so that all links on Chrome should become blue and underscored, since Chrome currently doesn't support such user-adjustable settings directly], though there are periods when some update or other mucks with it a little [I find that toying with AO3 site skins can make it go wonky for a bit, too, but oddly, when I update my fics' work skin, somehow that seems to get Stylish functioning properly again; go figure]).
  Wanna know how?  The work skin rule for it is below, but the underscore is pretty irrelevant, since AO3 already uses some non-zero border-bottom (OTOH, having the underscore does make it stand out, given the weird doubling effect with the border below it [just imagine the extra-weirdness, had I used double-underscore and left AO3's border-bottom to make a third — you'll see the work skin rule for double underscore in a little bit 😉]).

#workskin a,
#workskin a:link {
  color: #0000EE;
  text-decoration: underline;
}

NB:  That should turn all links blue (and underscored).  It's just a basic arrangement though (and sometimes some websites will work with it and sometimes not — Google and Wikipedia, for example); if you want different colors for visited/etc. links, then see next subsection.

This will work as long as your browser settings, third party apps, and AO3 site skins permit it (and won't work in a download, of course, since downloaded fics don't include the external CSS rules that AO3 uses).  However, you can still override this global work skin rule for link anchors directly by applying some specific other rule, for example: with only the workskin applied to the tutorial that you're reading right now, <a href="https://archiveofourown.info/works/28934610">this link (which happens to be this tutorial)</a> should appear to be blue (and underscored), <a href="https://archiveofourown.info/works/28934610" class="red">but this one</a> should appear to be red instead — and all that I did was add a specific class class="red" to that link there (NB: this was working fine, then I tested some other unrelated CSS, and now this red-link no longer appears red to me, even with my third party apps turned off; lesson being that your code might work without your knowing it due to other apps' interference with your ability to see it properly [and that functional code won't necessarily work on other people's setups, obviously]).

NB:  You might have noticed there that I wrote <span class="blue">turn the font blue</span> with "straight quotation marks", not with “curly / smart” quotation marks, and that there are similar instances where I've written URLs as something to the effect of <a href="https://archiveofourown.info/works/28934610" rel="nofollow">this tutorial's URL</a>.  There's a reason for that.  Some things HTML is forgiving about, some it isn't, and quotation marks fall into the latter category.  If you write offline in a document, and copy-and-paste into AO3, and your document settings are set to make “curly / smart” marks automatically, then your pasted HTML will contain curly marks instead of straight marks and your link won't function.

Sound silly?  I agree (since they're both quotation marks), but here, try these and see for yourself (the HTML with "straight" marks isn't just the only one that functions, it's the only one that AO3's parser didn't strip of the href=... section — I didn't remove those or forget to put them in) — click these and see which one works and which ones don't, and then copy-and-paste to your own thing so that you know that the href=... sections are definitely there in your version and see if it makes any difference:

• <a href="https://www.google.com" rel="nofollow">linked words here, normally, but I changed it for emphasis in this example</a> ("straight quotation marks" in the HTML as shown explicitly in the linked portion for emphasis [in order to demonstrate the differences between this example and the next two]) vs.
• <a href=“https://www.google.com” rel=“nofollow”>linked words here, normally, but I changed it for emphasis in this example</a> (“curly / smart”, as often used in “English punctuation”) vs.
• <a href=”https://www.google.com” rel=”nofollow”>linked words here, normally, but I changed it for emphasis in this example</a> (using the end-closing curly mark of English, but at the start of the HTML as well [not just the end]) vs.
• <a href=“https://www.google.com“ rel=“nofollow“>linked words here, normally, but I changed it for emphasis in this example</a> (using the end-closing-top curly mark of „German punctuation“, but at the start of the HTML as well [not just the end]).

If you're writing somewhere that your keyboard doesn't really offer an easy access to "straight" quotation marks and can only get them by copying from an English source (which someone had mentioned being a problem for them in a Facebook thread), there are some workarounds that might work for you:

• When I write in an offline document and type my quotation marks (which I have set to come out as “curly / smart” marks), they can be turned into "straight" marks by hitting CTRL-Z once (twice will erase the mark entirely, but just once turns the “curl” into "straight")
  • the undo button (in the document, since there isn't one on the keyboard) should do the same thing, of course (though I don't know how you might do this, if you are working on your 'phone);
• I also keep a document open where I put all of my constant-use symbols, so that I can get to them at any time, so it might be worthwhile for you to keep a similar document with whatever snippets of HTML and such you find a need for often (such as "straight" marks).

Final note on links: if you're trying to get rid of the standard underscore of the links (within your fic), you might want to try the following work skin rule (courtesy of robinainthood's request for just that — and you might want to look through the struckthrough portion of my answer, since it covers a few of the dead ends that I tried [they could work for you for some related matter] and links to one of ElectricAlice's site skins for readers to remove titles' and tags' underscores):

#workskin a,  /*  unvisited link  */
#workskin a:link,  /*  unvisited link  */
#workskin a:visited,  /*  visited link  */
#workskin a:hover,  /*  mouse over link  */
#workskin a:active,  /*  selected link  */
#workskin .actions a:hover,  /*  onhover mouseover  */
#workskin .actions a:focus,  /*  while clicking or tapping  */ {
  border-bottom: 0px;
}

Alternatively, you might want to remove only some links' borders rather than all links' borders:

#workskin .removeborder {
  border: 0px;
}

in which case you would then call that rule in your <a href="https://archiveofourown.info/works/28934610" class="removeborder">fic's link</a> like this (compare this one with my other links and you'll find that although this has my work skin's underscore, it doesn't have the AO3-automatic border beneath that).

Note that in one case I used border-bottom: 0px and in the other I used bottom: 0px.  Either one should be fine used in either case, pick whichever one you like and use only that one in both rules, if you like (though if you have the global rule in your work skin, you probably wouldn't need a specific case rule to remove the border, only one to add them back in if you wanted).  I used them both here in order to show that there are options, and sometimes that's necessary (sometimes — whether CSS declarations or whatever else — glitches happen and one wording works instead of another, when neither should have any problem at all in the first place).

NB:  Last item here, I promise.  You've probably noticed that I was lazy in each case, making any and all links blue, no differentiation for hovering or visiting or anything, with underscore the only decoration.  You might want to pick a slightly different blue, or make visited links purple, or get creative and highlight their spans.  These are all possible, of course, though best practice would argue to go easy on the bells and whistles, and either pick standard link colors (or very nearly so), or aim for similar ones that take into account color blindnesses.

  Top of results section  ↑

Hidden text

Londo Mollari:
But this... this, this, this is like... being nibbled to death by, uh... Pah! What are those Earth creatures called? Feathers, long bill, webbed feet... go “quack”.

Vir Cotto:
Cats.

Londo:
Cats! I'm being nibbled to death by cats.

`.__(*)<......Meow!
  \___)
~~~~~~~~~~~~~~~
 
Congratulations: you've found hidden text! 🙂
(...most of which isn't hidden in .pdf)

As a side-note, one can even make text become invisible with a simple CSS rule (just declare width: 0px; [though I also did that to the height] and overflow: hidden; — I've tested it, and it works on AO3, as you can “see” [or rather not see] between these two pointers: ►See?  Toldja so!...◄ [don't believe me?  Highlight that and right-click and Inspect the Element]), and InfinitysWraith's tutorial's 13th chapter appears to be fairly empty, but clicking a link in the 14th chapter reveals some hidden text in 13 that's called directly from the CSS (not stored within the HTML).
  NB: As with any CSS (almost any, since some few effects manage to carry over), the hidden text is NOT hidden in element inspection or downloaded .pdf / .html files (becoming visible: you might find a surprise or two in this very page, in fact... like being nibbled to death by cats) — amusingly, sometimes text can become sort-of-hidden through non-CSS causes, e.g.: CTRL-F for the word “inane” in ch. 6 of InfinitysWraith's tutorial and you find the whole paragraph in the source code or the downloaded .html page, but it's cut off [visually] in the .pdf after the word “couldn't” for some reason (I say “visually” because copying that paragraph and the next will show one further word when pasted: “create”) — but as an extra quirk, the zero-width CSS-hidden text remains hidden here on AO3 even with creator's style turned off (at least for paragraphs and spans, not for description lists [though that could at least be subdued by minimal opacity, I suppose]; haven't checked other element types).

Alternatively, you could simply use <span class="hidden">a method of calling CSS selectors without having to write it as a rule in your own work skin</span> to hide things (though it won't remain hidden in a .pdf download... or page source, .html, .mobi, .epub, or .azw3).  This might be useful in a basic-hacking-oriented mystery fic (online-only, obviously, since there wouldn't be anything hidden in the downloads), or to leave notes-to-self within your fic — hmm, almost sounds as if I were hinting at something there.

StackOverflow has some leads for a CSS equivalent of Java's onclick, but I haven't gone down that rabbit hole yet (since I'm not looking to write interactive clickable fic material), so I don't know how much of that might function within AO3's CSS constraints.

And last of all (so far), there is a way to make invisible text with just CSS selectors calling either from AO3's parent skin code or that AO3 allows automatically (i.e.: I'm not sure which one it is, but you don't need to write a work skin rule for this), and I only just this morning (~3.5 hours ago, 20 Sep 2023) discovered it and tested for variables.  I've streamlined the original material (you can find that in an Explicit fic that's marked as General for some reason: the General rating looked odd, given that the title is 12-5 Panties for sale [it came up during one of my 48/7 multi-tab multivariate searches for the upcoming 2024 AO3 traffic analysis piece], though there aren't any additional tags on it [warning: it definitely needs some tags, beyond the fandom being named “Fetish”, so I've linked here only to the comment thread; clicking from there to the fic is possible, but I chose not to link to the fic directly], so I popped in out of curiosity only to face an interesting surprise of blank text in the body and a short empty space that certainly wasn't long enough for more than a couple of short sentences, but an AO3-displayed word count of 1,992 and no work skin in the page source).
  Pared down, all that's definitely needed is:

<div class="mail-message expanded">
/* creates a magically non-searchable up-arrow ↑ to indicate the presence of invisible text */

<div class="clear">
/* class="clear" is what makes the text invisible */

<p>
[insert paragraph here]
</p>

<p>
[rinse and repeat in normal fashion with more paragraphs]
</p>

</div>
</div>

Here's an example of it — right after I say “GO!”, I'll stick the CSS selectors in (though if you check my page source, you'll see that I'm not calling any CSS from my own work skin), and you'll see no words until I say to stop if you're reading it online (if you're reading the page source, the save .html, or a downloaded file, then yes, the bit in the middle will be fully visible to you)... a-a-and... GO!

...a-a-and STOP!  So, did you see anything between “GO!” and “...a-a-and” (other than the magically non-searchable non-highlightable up-arrow ↑ that simply inserts itself there)?

OTOH, here's what you get without the <div class="mail-message expanded">, just the <div class="clear">:

See?  No arrow that time.

  Top of results section  ↑

CSS character count limit — it's how long?!?

Belatedly (07 Sep 2023), and on a whim spurred by a rhetorical question in an r/AO3 thread, I tested the character count limit for work skins (or site skins, for that matter).  It doesn't (they don't) list the character count limit (nor do they provide a countdown) the way that the fic edit fields do.  You can write up to 68,937 characters total (not 68,938 — ask me how I know), which includes two characters counted per carriage return (ENTER)... which means a lot of rules before you've hit the wall (even if they're big rules).

That came about due to the question of using InfinitysWraith's hidden text technique (I swear that it sounds like I'm referring to a gōngfu/wǔshù technique).  If you absolutely need to use more than 500K char in a single chapter, you can:
  One can write a CSS rule that will produce text inserted into the chapter, which would count the CSS selector's characters, but wouldn't count the characters that are shown from that rule... but work skins are limited to only 68,937 characters total (and that means that the characters inserted into the fic would be fewer than this, since the CSS rule itself requires 29 characters, assuming that you don't add formatting declarations, so it would actually add only 68,908 characters' words in the rule, and the CSS selector's 22 characters [and the 1-character minimum name length] means an effective 68,885 characters to the fic [the 23 total characters would actually be in the fic itself, eating into the 500K, but I'm counting it here for simplicity]).
  However, while it's true that one can apply different rule sets to different chapters without having to come up with new names for each rule every time, the work skin itself is still limited in total length, and we still cannot apply more than one work skin to any one fic.
  And... that's as far as we can take it (I think); we can't chain work skins (so we can inject external text this way only once), only site skins, and an author's site skins can't (in the inverted sense here, where the author might hope to use the site skin in a work skin fashion, unless there's an exploit that I don't know of [and don't want to, thanks]) affect a fic from the readers' perspective, only from the author's perspective (though I suppose that logically one could upload a site skin for one's fic/fics and leave a link to that in a header note that specifically states that it's helpful [or necessary?] for the reader to apply that site skin when reading that specific fic, opening up 500K site-skin-characters for fewer-than-500K CSS-added fic-text-characters per chained site skin...).  I suppose that one could call (using only a few characters) an image of text (with many characters) and finagle the display (NB: if trying to “blur” irrecoverably anything important [SSAN, for example], then you would want to cover it with a rectangle with thick borders [at least if in MS Paint or something] and a second one within that [since one alone doesn't quite cover the entire text height], then cut that portion entirely and re-cover with brand new pixel-fill [possibly save, close, and re-open before each step, though I'm not sure if that's necessary or even helps at all]; info. that's simply covered/blurred can be retrieved with deobfuscation techniques and appropriate software — though if working with actual text material before a screenshot, then simply first replacing the text with obviously fake info. [e.g.: SSAN 987-65-4321] might be easier [though then covering that with a solid block of color, rather than scratching trough it and leaving small random bits here and there, might give it a pleasanter redaction appearance as if it were real, unless you want it to look specifically like some random Joe had used the more common line-scratching method]), but that would be only a technical feat, not an actual direct character count thing (then again, I suppose that one could perhaps manage to point a portion of the page to display the text contents of some other webpage, repeating the pointer with only a few characters used, and thus end up with a cumulatively enormous count of displayed words, without having written many characters at all, but I really don't know if that's do-able [though worse, and certainly do-able: SPAM a max-length CSS content many-multiple times with a min-length CSS selector, and end up with a page that's effectively far, far longer than it would be with 500K char. of plaintext... and even worse still, if one were to use chained site skins for that same CSS content to be multiple factors longer and a link of “<a href="https://archiveofourown.info/works/88888888?site_skin=XXXXXXXX">This work is best viewed with such-and-such site skin</a> ” linked to the final child site skin...], nor do I wish to put in the effort or risk breaking TOS in some way).
  Final upshot: {500K char limit per chapter in the fic, plus 68,885 char external to the fic from CSS (including any blank spaces or punctuation), minus an uncertain extra}, not including the aforementioned conjectured CSS-addition of text via reader-applied author-site-skin-chain.  What “uncertain extra” am I subtracting?  Meh, it could be zero if this effect in notes doesn't happen in the main body, but when you write a note that pushes the 5K char limit of chapters (or 1.5 for the fic header, though a fic endnote is still 5K), the parser sometimes is OK with that and sometimes claims that you're at your limit when you submit it (even though the character count shows 15 to 80 remaining characters available to you)... and since I tested it just now, I can safely state that the parser told me that my exactly 500K char test fic was OK (I didn't test it with the work skin CSS trick though, much less a reader-added site skin or chain of site skins), which would bring us to 500,000 + 68,885 − 0 = 568,885 (plus any more via reader-added site skin [chain]).  Not an enormous boost, no, but longer than some novellas and beginning to push into novel length (71,429(-) to 81,269(+) words, assuming ~6 char mean average word length, +1 space per word; of course, if we consider 4.79 per Peter Norvig's Mayzner Revisited +1 blank space glyph = 5.79, then 500,000 and 568,885 characters become 86,355.8(-) and 98,253(+) words, landing this hypothetical chapter squarely in full-novel-length territory) — and honestly, a one-time +≤13.777% return ain't too shabby.
  If we were to try to account for character count lost to punctuation (I'm not going to consider average paragraph length in order to account for those further lost characters), then things depend on sources again, and individual styles vary, but the ballparks are around the high-novella to low-novel length range:

• assuming a corrected average of ~1,253.6̅ punctuation glyphs per 10,000 words from a 1924 study (of 38,638 words, from a number of sources), then these become 76,736(-) and 87,307(-) words;
• a larger (~459K word) 2013 study's quoted average of 208.7 per 1K words in a quoted 276K word corpus would mean 71,445(+) and 81,288(+) words;
• note that averaging the bottom row totals of the second table (which shows that same 208.7, but also starts with column headers that total out at 723,759 rather than 276K: books 2 through 4 total 276,201, so somewhere they're adding or forgetting the first column book; clearly I'm missing something though, since they also state that the newspapers' word counts total out at 55K, but the second table's columns show them at 24,024) would give a calculated 234.3(-) punctuation marks per 10K words, and hence 69,964(+) and 79,603(+) words;
• taking that same 2013 study's apparent corpora table (“apparent” because they total out at 723,759 words, not ~459K nor 276K) and averaging the individual entries at 268.9(-) would mean 68,058(-) and 77,434(+) words;
• looking at the 2013 study's individual corporum totals, the smallest corpus-average of 145 punctuation marks per 1000 words would mean 75,420(-) and 85,811(-) words — though correcting that by taking the column's entries' average of 145.6(+), we get 75,377(+) and 85,762(+) words;
• looking at the 2013 study's individual corporum totals, the largest corpus-average of 315.5 punctuation marks per 1000 words would mean 65,645(-) and 74,689(-) words — though correcting that by taking the column's entries' average of 316.1(-), we get 65,615(+) and 74,655(-) words.

Purely as a tack-on to the question of characters-per-CSS, it's been noted (27 Aug 2021) that a broadly technical chapter count limit sort of exists, though the wording implies to me that there might not be an actual limit set in place as such:

Is there a chapter limit?

In theory, it's in the mid to high tens of thousands.

That said, when your work goes past about 500k words, or about 100 chapters, the piece of code that provides the download files starts choking badly.

And before any bystander jumps up and down at that "limit": a) it's a bug we haven't had a chance to fix yet, b) the entire "Lord of the Rings" trilogy - all three (six) books combined - are only 558,003 words and 62 chapters.

“...about 500k words...” is probably the key factor, rather than “...about 100 chapters...”, but given that the minimum character count requirement for a chapter on AO3 is 10 characters... yeah, 500K words / 10 characters = 50K chapters (i.e.: 5 tens-of-thousands), which would be dead center of the “...tens of thousands” range.
  And for those itching over the numbers there: combining the above blockquote (and bearing in mind that different sources will give LotR different word counts) with the preceding letters-and-punctuation estimations, one could (physically, not legally) basically write the entire LotR as just over 7 chapters (something like 7.44±~13%, depending upon the actual breakdown of word length and punctuation in LotR) in AO3 (still somewhere around 7.15 or so, even if one were to utilize the 68,885-char CSS trick).

P.S., 14 Jul 2024:  So... how much of a difference does it make to character count by adding HTML and maybe CSS?

Right now, according to AO3, this tutorial [before my adding this note] contains 29,551 words, with the Edit page claiming [unreliably] 107 char. remaining in the summary, 151 for the header-note, 73 for the footer, and 249,568 for the footer.  In principle, if these counts were actually accurate (and no, you can't trust them: somewhere between 25 [usually] and 75 [usually], the edit field will say that you have n-many characters remaining, but the posting-attempt will often throw up a banner warning that says that you have used too many characters), then that would mean that they contain (at the time of this addendum):

I was wondering about that, so I copied all of the text from the page as presented within these modules and pasted them into OpenOffice (which admittedly does count things differently, which is a problem when going from any one word processing interface or program to another) in order to see how the surface content that you read compares with how many characters in this tutorial (as an example that's obviously conveniently at hand).  Here's what OO thinks the counts are (I'm only curious about the character count that's added by making paragraphs [necessarily HTML], pretty colors, etc., but am including the word count [which AO3 identifies as being 29,551] for generic reference)

For reference, that means that the AO3 counts and OO counts differ to the following extent (and this difference wouldn't be the same amount if I were to check in LibreOffice, Google docs, MS Word, etc.):

I then went into the Edit page and copied all of the contents from each module.  Under the hood, including all visible HTML tags that are explicitly present and all visible selectors to call the CSS, though obviously not the CSS itself, since that's in an external sheet (the work skin), and excluding the extra “hidden” footnote, we get slightly larger numbers (since this includes all of the fancy stuff to adjust the formats, not simply the actual written text alone):

So, according to OO, the number of characters (and internal-only “words”) added to the plaintext by HTML layout and CSS formatting (which would be different if I were to check this in another word processor) is:

And there you have it.  How much of that answer is due to unavoidable HTML such as paragraph breaks <p> (unless you choose to write a wall of text, which would then have only 7 characters delineating the start and end of your monolithic mass...) and such versus freaky formatting (not just CSS selectors alone, either, but some HTML stuff such as bold <b> and italic <i>, too) will probably vary between works, but this gives you some idea of how much it can be (and it's surely not an upper limit, if one considers a heavily modded fic).

  Top of results section  ↑

...and that's that for that.  Unless you're now scratching your head with materials in hand and no tools with which to apply them...  OK, yeah, you can't simply plunk that code into a story's Work Text Edit Field and watch it go, even if you know how to code CSS for a web page: AO3 uses external sheets (the other two ways are internal in a page's header and inline at any given element within the body of the HTML ), so you just have to embrace the suck and use external CSS (I say embrace the suck, but actually I think that it makes things way-the-hell easier to write, more reader-flexible, and somewhat easier to explain [there are other good reasons too, on the tech and sec side of the house]).

View a fic's work skin rules  ^{Contents ↑}

If you want the most recently updated [i.e.: complete] version of work skin rules, then go to view-source:https://archiveofourown.info/works/28934610 — yes, just add “view-source:” to the front of this fic's URL, or right-click and select the same — and search for the phrase <style type="text/css">; that row of text (ending in </style>) is where you'll find the entire list of current rules [and in case you're wondering: yes I tried to link it, but the parser deleted the link].
  Try it on other works with work skins applied to them (for practice: try it on one of your own fics, first, where you'll recognize your own skin's rules), and you'll see that the rules in those are different: that row lists whatever the work skin rules are for any given fic in question, as long as you add “view-source:” to the front of its URL.
  To use the rules revealed thus, copy everything in the row between <style type="text/css"> and </style> and paste it into a work skin (and delete those two bits at the start and end) — though some things will need to be fixed (see below re. Segoe\ UI and such), and some old code that still runs might no longer be accepted by the parser for new (or updated) work skin rules.  Then apply that work skin to a fic and test out the variables, change the sizes and colors to suit your taste, etc..
  If you do grab anyone's code (I don't just mean mine, I mean anyone's), then please note in your fic where you got it, even if it's a modified version of it.  It's just the polite thing to do.

That's one way to do it, anyway.  You might find that harder or easier than the alternatives, depending upon your device and settings and such.

• If you're in Chrome, Edge, or Opera, then try the DevTools approach: right-click, select Inspect, go to the Sources tab, and scroll down 'til you find the <style type="text/css"> row (or just hit F12 [the 12^th function key] or CTRL-SHIFT-I or CTRL-SHIFT-C or CTRL-U [this last for viewing page source] directly [there are a few more ways to do this] and then scroll down to that row — it should be around row 300-350, since it varies some, so you might need to budge up or down some in that general neighborhood, but if you take a look at the Inspect Element, you'll see that the Styles section shows each little subsection of separate rules that are applied to a given highlighted element, and that the View Source row is named in that subsection's top-right corner [in this example, you'll note that it says 31387700:316; ignore the “31387700” since that only tells you which AO3 fic it's from {How to make and fix a series on AO3, in this case}: the key part that you want is the “316”, which is the approximate row of the view source page in which to look for the CSS — I say approximate because when you do that, it'll tell you the exact row of the moment, but as you can see from the screenshot, it had been 316 and you'd find it to be 315 today; something changed, it happens]);

  
  Open image in new tab to zoom.

• alternatively, if you're in Firefox or TOR, then: right-click, select Inspect (though I highly recommend the View Source approach instead), go to the Style Editor tab (or just hit F12 or CTRL-SHIFT-I or CTRL-SHIFT-C or CTRL-U [this last to view page source] directly [there are a few more ways to do this]), and find whichever inline style sheet has #workskin entries in it (right now, that's <inline style sheet #3>, but that's changed before, and so might again).

  
  Open image in new tab to zoom.

Regardless of the method that you choose to find the rules, if you copy them, then you'll probably have a long rambling string of incomprehensible gibberish.  You can use a CSS beautifier to clean it up into something that you can read more easily once you paste it into your own work skin, but you'll still need to look it over with a fine-tooth comb because it might very well have a bunch of GIGO along the lines of Segoe\ UI.
  Update Sep 2023:  I hadn't thought to mention this, but some time around a month or two ago, AO3 (or perhaps Chrome, Firefox, Opera, Edge, MSIE, and TOR each decided separately to do this...) changed the layout of the view source page, so the CSS rules are laid out legibly now (in the same fashion as you'd see them in your own work skin page), starting around row 250-300 (varying from one fic to another)! 🙂  (You might still keep a CSS beautifier in mind when checking out non-AO3 CSS rules, of course.)

...and now that you know how to PEEK at the underlying work skins, you can skim through all of the AO3 "work skin" search results (and the further, different set of "workskin" search results [one word this time, not two]) and not just see the work skin rules in those that include them in the visibly written material, but even find out what they are in those that merely display the results without having included the actual rules that they used! 🙂

MAKE YOUR WORK SKIN  ^{Contents ↑}

Before we deep-dive into making a work skin, I need to repeat what I mentioned in the site skin gloss: what you see (per how each browser processes things differently, each user's browser settings, site skin, work skin, third party browser extensions, and a device's resources [e.g.: fonts]) and what the author intended / your readers see can vary greatly.  Even with something as simple as a standard HTML character (in this example, taken from a comment on my Green Rain font header-note explanation: U+218B, which should appear as the number three “3” glyph rotated 180° to be upside-down — ↋) can go unexpectedly oddly awry (in which the rotated “3” glyph appeared as a Creepypasta Thin Man, for some reason [so perhaps an HTML entity of &#8587; {↋} or &#x218B; {↋} might be better choices]):

(zoom)

OK, now on with the show!

The basic instructions:

1. Copy my CSS rules from the Results subsection, above.
2. Go to {My Dashboard ► Skins ► My Work Skins ► Create Work Skin}.
3. Paste that copied material into the CSS Edit Field.
4. /*  Don't bother putting in any notes: AO3's parser will strip 'em right out.  */
5. Fill in all of the other fields of course, just as you would if you were writing a story or chapter.
6. Save (edit later, as much as you need/want, as often as needed/wanted).

Want to add something?  No problem, toss it in — here, try these grey highlight (the line-height lowers its ceiling, the height raises its floor) and double-underscore options:

#workskin .highlight-grey {
  line-height: 0.3;
  height: 1em;
  background-color: #d9d9d999;
}

#workskin .double-underscore {
  border-bottom: 0.18em double;
}

• N.B.: Look at these 3 “L”s (normal vs. code surrounds highlight vs. highlight surrounds code) and spot the highlight differences (and it isn't that one set is grey and the other is blue, the extra set being present only for potential viewscreen contrast issues and/or color blindness):
  • ...l......l......l...
  • ...l......l......l...
  • The first one (of either row) is just highlight's normal size font, but the second and third (of each row) are both highlighted and HTML tagged for coded font.  The difference is that the height of the highlighted span is either short to match the shrunken font size (code outside / highlight inside) or tall (highlight outside / code inside).  The latter looks awkward to me, but the point is that one's results depend upon one's input sequence: which one (CSS selector or HTML tag) is applied first (surrounding outside) will determine what the overriding effect will actually be (like a pizza: dough then stuff, not stuff then dough).
      E.g.:  <span class="highlight-blue">...l...</span><code><span class="highlight-blue">...l...</span></code><span class="highlight-blue"><code>...l...</code></span>

Perhaps the double-underline whetted your whistle, and now you've caught a hankering for a double-strikethrough option?  Can do, courtesy of a few answers, or one particular answer, at StackExchange (things change over time, but right now the rule below is functioning for me, and attempting a single combined declaration of text-decoration: line-through double; failed for me; I didn't test out the other approaches):

#workskin .doublestrike {
  text-decoration: line-through;
  text-decoration-style: double;
}

Once you've done that, your work skin is complete (but keep in mind that if you also have a Site Skin turned on, then that will override your Work Skin, so you won't necessarily see your fic's Work Skin mistakes, or might think that it's broken [due to the Site Skin overriding it] when it's actually working perfectly well).  You've made it, and now need only apply it to any fic(s) that you wish to.  But... how do you do that?  No problem!  When you post a new work, or edit an old one, scroll about halfway down the page to the Associations section (below the Preface section, and above the Privacy settings), and at the bottom of this section you'll see a field named Select Work Skin; click the Edit Field's pointer and it will present you with a list of all of the Work Skins that you can choose from.  Pick one (and you can always pick a different one instead, later), which will presumably be the one that you've just now made, then scroll to the bottom of the screen and hit the Post button:

Font size  ^{Contents ↑}

I held off on font size 'til now for reason (this gets detailed, but you can cut to the chase, if you'd like).  You can change font-size in a couple of ways.  In a normal web page, you might have used something like HTML (inline CSS, which I don't address here, but you can find more on it at Khan Academy as a starting point) <p style="font-size:30px">for a 30 pixel font</p>, but that's deprecated in HTML 5 and isn't even an option within AO3's HTML Edit Field anyway and some of the lesser HTML tags don't work right on iOS (more on that in the bonus section).  That leaves us two alternatives:

• Use headings in HTML (the styles of which are controlled by AO3's parent skin, and you can adjust for this, but it's well beyond our scope here: see the bonus round at the end), e.g.: <h1>Heading h1 is pretty big</h1>, <h2>Heading h2 isn't quite as big</h2>, etc.
  • (or similarly: <small> and <big> [effectively ≈1.2x multiplier, actually only bumping a 16px font into the next text size category of 19.2→19px], which you can nest for n-tuple effects — certainly as far as 100 <big> tags and still see the increases, though <small> decreases only once, no matter how of them you use);
• Adjust them in a CSS skin (and hope that the reader hasn't disabled creator's style).  The explanation for the different ways to change font size is a bit complicated, so I'll forego that and simply list what they are and how to use them (test and see which one(s) below feel right for you  ):
  • The simplest answer is to use absolute value names (e.g.: “small”, “medium”, “large”, etc. — used like this: font-size: xx-large; } [where xx-large would yield 32px]),
    • but for that, you might prefer more control over the actual sizes themselves, so just take normal font size to be 16px normally (which for me is actually 15px, which might be from my browser or monitor or AO3 or other reasons), hence if you wanted to almost double the height of some word, then you might code the CSS as font-size: 30px; },
      • AO3 also permits mm (millimeters), cm (centimeters), in (inches), pt (points: 1/72 of an inch, 0.3528 mm), and/or pc (picas: 1/6 of an inch, 4.2(3̅) mm) — and you can find conversion charts, but other than points, these might not be a good idea,
    • alternatively (because some pixel counts don't change enough to be particularly visible: 15px comes out the same as 16, for example), if you had some specific multiple in mind, then you could code it as font-size: 1.9rem; } and get that word's height to 1.9 times the height of the words around it;
    • each of these yields the exact result that you aim for, but leaves readers locked into your specific sizes, so that zooming in/out won't help them with visual display (imagine that they don't have their glasses with them or something).
  • Sometimes you don't have an absolute size in mind for a specific element (or do wish to permit readers' zooming to affect the text's displayed size), and want them to scale relative to the element that they're in, in which case you might instead choose em, which is just like rem in multiplying a font by some amount, except that font-size: 1.9em; } will scale with window size (AO3 encourages this approach specifically, due to readers' varied browser and font settings),
    • though font-size: 190%; } should(?) come out the same (TL;DR: em on AO3 turned out to be round-down integers only, but % worked very well for me),
    • and relative keyword names (i.e.: smaller; } and larger; }) are an OK 3rd choice: not as much control, but easy to use, the increase being basically around the range of +1/8 to +1/4,
    • but the remaining possibilities might not be so great: 1.9ex; } (the height of which is relative to the height of the root element's font's lowercase “x” [e.g.: a paragraph font-size being p { font-size: 2ex; } would double the size relative to however many pixels were defined in the CSS initially, so had that been HTML { font-size: 20px; }, then the resulting doubled height would be 40 pixels for some fonts, but a bit shorter/taller for other fonts]),
    • or even 1.9ch; } (this works almost the same way as the ex method, but instead of being relative to the height of the root element's lowercase “x”, the ch is relative to the width of the zero [which can be wider/same/smaller relative to the letter “O” from one font to another]).
  • Then there are size changes that are relative to the viewscreen itself, specifically font-size: 20vw; } and font-size: 20vh; } (NB 05 Feb 2024: and the related dynamic viewport dvw/dvh, small svw/svh, and large lvw/lvh, along with a few others, yes... and there are reasons for not using these under the circumstances).  These will greatly affect the font size relative to the screen itself, rather than the rest of the text — and viewscreens for computers aren't the same size as those for 'phones, so 20vw would give a result that's 1/5 of the screen width in either case, with the visual flow of text probably(?) rendering differently from one aspect ratio to another² (I've used vw only once so far, and that was to adjust a paragraph to resemble an admission ticket [I'm disinclined to use a public domain image as a background or sketch my own, and I don't know if AO3's CSS even supports SVG to code for a fancier border {though I suspect that the ORV System Work Skin could be modified just right, and it's an amazing piece of work}, though it might be do-able], so I'm not very experienced or well-practiced with vw).
      The CSS and HTML for that ticket are shown below, for those who might be curious:

    #workskin .ticket {
  width: 20vw;
  text-align: center;
  background: #ffffb399;
  min-width: 15em;
}

#workskin .borderdouble {
  border: 6px double;
}

    <p class="ticket borderdouble" align="center"><a name="AcmeTicket" rel="nofollow" id="AcmeTicket"></a><br />
    <b>Ticket number 1729<br />
    Seat 10F2C<br />
    Acme Building Auditorium<b><br />
    <br />
    </p>
    

    
    Ticket number 1729
    Seat 10F2C
    Acme Building Auditorium
    
    

      (NB:  There's also a much nicer-looking arrangement for a prophecy [earlier on in that same fic] using a slightly modified version of a note work skin from La_Temperanza's How to Mimic Letters, Fliers, and Stationery Without Using Images — and it's within a <dd class="..."> so that the inset effect of the <dd> will still stand out even with creator's style off.)

  • I gave in to my OCD and tested them out in a skin to see their effects (except for vw/vh, for reasons).  For whatever it's worth, here are my results (taking the unaffected 100%-zoom 12px height lowercase-"h" as my standard, so that 190% = 22.8px [rounded to nearest integer would give 23px] and 200% = 24px), though I resisted checking multiple zooms and nested elements-within-elements (NB 10 Sep 2023: skipping the nested elements test might have been a mistake — you'll see why in the em portion); your mileage might vary:
    • CSS declarations to the effect of font-size: 1, font-size: 2, font-size: 3, etc. (then called in HTML with the CSS selector and what I named the test-rules) FAIL: no change (though surprisingly, the work skin parser did permit them);
    • h1, h2, h3, and big = remained 12px tall... FAIL: no change (I didn't expect these to work in CSS);
    • xx-large = 25px [x-large only 19px] — OP CK GOOD (these working surprised me);
    • 30px in CSS gave 22px(?!?) as a result... EPIC FAIL: can't rely on an “exact” measurement;
    • 22pt = 21px, and 22.5pt & 23pt both gave 22px... WORKAROUND: these should've been 30px(±0.7), but functional enough if one pretends pt≈px (30pt = 29px) but this is still my least favored of the options (and probably a terrible idea for wide application, since there's no telling the set-up on others' devices);
    • 1.9rem = 22px, 2rem = 23px — OP CK GOOD;
    • 1em & 1.9em = 11px (not 12px: these shrank my sample by 1px), 2em = 22px — OP CK GOOD ENOUGH FOR GOVERNMENT WORK
        NB 10 Sep 2023: it turns out that em doesn't nest well due to it being relative to the parent elements, and so rem might be a better choice in nested element situations since it relates to the root element (see today's comment thread for further details, courtesy of DigitalThespian attempting nested DIVs with cursive fonts that needed different sizes in order for them to be legible);
    • 190% = 21px, not 22.8px→23px (N.B.: but finer control than em...) — OP CK DOUBLEPLUS GOOD, this is my MOST FAVORED of these options (unless rem is needed to cut through a mess of all sorts of size changes applied to multiple nested elements such as <div>s, <p>s, <span>s, lists, onhover popup alerts, etc.);
    • larger = 13px (1px larger), not 14.7px(=15px)-16px... FAIL: no significant change (didn't expect it to work at all, so this +1px increase is something anyway);
    • 1.9ex = 11px, 2ex = 12px, 3ex = 17px, and 4ex = 23px... EPIC FAIL: with a lowercase “x” height of 8px, these should've been ~15.2px, 16px, 24px, & 32px, respectively (i.e.: results were ~71-75% of expected values);
    • 1.9ch = 14px (2px larger), 2ch = 15 (3px larger), 3ch = 22px, and 4ch = 29px... EPIC FAIL: with the width of a zero “0” being 9px, these should've been ~17.1px, 18px, 27px, & 36px, respectively (i.e.: results were ~81-83% of expected values).
  • In every case, it might be a good idea to check their browser-compatibilities, if only to at least cover the major bases.
  • N.B.: I found that the em approach works a little differently for images, or at least on AO3 using straight HTML (not in a CSS skin, where one might expect em to be used): in the img tag, I wrote width="40em" directly within the HTML Edit Field, and it sorta worked.
         Based on how em should work, I had initially scaled an image's width to 2em (which at 15px height per em should give 30px of width for this image), on the assumption that this would yield a width of approximately 2 text-heights (I'm trying to control image height directly, but seem constrained to controlling it by adjusting the width); instead, the result was perhaps 2 pixels of height — but it did work (albeit not as intended).  That said, I found eventually that 40em worked optimally for my purposes; what should have resulted in an image width of 40 text-heights came out as ~2 text-row heights.
         I take this to mean that to some extent "em" is read for images as the object's pixels (that is: a row of text isn't just the height of a font, but includes some padding above and below: highlighting [with class=] some normal text at 100% zoom, a screencap dropped into MS Paint showed the letter "h" to be 12px, but the height of the row's highlighting to be 24px; this is exactly in keeping with my earlier need to adjust highlight opacity, since each text-row's span height turns out to be 20px non-overlapping + 2px overlapping padding below [merely selecting a few rows of text via cursor gave seemingly-less relevant results of 14+5]).
         For the curious: see the gilded capital-O image (basically a mediæval illuminated text image) that opens the first paragraph of “Zelda Invictus” (the chapter note of which explains a bit more detail of the image size tests).

  After the rigmarole of which font size methods work in one fashion vs. another (if you clicked to here by the TOC instead of reading all the way through: try to use em, not px), here's an example of how to skin them (pick any one type of font size per rule: not more than one in a given rule, but yes you can use one type of font size in one rule and another type of font size in another rule  ):  ^{Contents ↑}

  #workskin .courier {
  font-family: courier, monospace;
}

  #workskin .courier-30 {
  font-size: xx-large / 30px / 30pt (maybe others) / 1.9rem / 2em / 190% / larger / 1.9ex / 1.9ch...;
  font-family: courier, monospace;
}

  Notice that I said that although you can't use more than one type of font size in a single rule, you can still use one type of font size in one rule and another type of font size in another rule.  In the above rules, you might choose to write .courier { font-size: 110%; } and .courier-30 { font-size: 2em; }, for example.  Here, the term “value” is fuzzy: in English, it means “how much” (which might lead you to think of something like 2 or 110), but in coding means [roughly] “a variable” [in the mathematical sense] (e.g.: em or %), so I chose to avoid ambiguity by calling that a “type of font size” (to make it explicitly clear that I was referring to em and % and all of the others listed above).

And... badda-bing, you're G2G!  Except that you might not know how to actually apply any of this; there's a decent chance that you know some common HTML tags such as <b>, <u>, and <i> (and speaking of italics, by now you might have enough to work with to consider changing font angles through the work skin using font-style: oblique 10deg; } or some other angle [a back-sloped angle being in negative degrees, which is browser-dependent at the time of this writing]; I gave it only a quick try, no dice)... but how do you use CSS selectors in your story?

Using CSS selectors in your chapters' HTML:  ^{Contents ↑}

If you need to learn how to tag paragraphs or spans with an #id selector or a .class selector, then I strongly suggest Khan Academy (or search there for another CSS course), and maybe a brief stop at W3Schools and CSS-Tricks (and CodePen, JS Bin, JSFiddle, and CSS3please can all be useful for testing purposes, but a bit of a hassle that might be prettier than actually of value if you're new to HTML, much less CSS), but here's a quick and dirty demo.  If you do have some clue, but not much, then consider this AO3 FAQ instead (or as well), and possibly AO3's allowed HTML FAQ.  If you're already a wiz, you might not be reading this — granted — but you might wish to work on some advanced special effects.

First: check my code.  Notice how the first one is called “.diacritics”?  Ignore the word diacritics, that's just a convenient choice of word for me (you might prefer to name it accent-marks or semantic_marks or IshKabibble : don't worry [anyone get this joke?], that part is entirely up to you as long as you don't start the name with a number, so .answer42 is OK but .42answer will stay in the CSS skin but the HTML parser will strip it right back out [just don't leave a space in the name, and avoid most special symbols; I prefer the underscore conceptually, but the dash makes it so that I can double click just one word and replace it, rather than click-and-drag across the characters that I need to change in the name]).  Instead notice how that selector begins with a “.” period; that makes it a class selector, and one of those can be applied to as many different spots as you want, like a generic bar code (a can of soup at the store will have the same bar code as any other can of the same brand and type).
  For more info on classes and illegal characters, cf. which characters aren't permitted to begin a class and some functional though arguably inadvisable workarounds.

Sometimes you might want to identify a unique section for some reason; I had no need for that, but had I, then I would have written “#diacritics” instead.  Notice how this one starts with a “#” pound sign instead; that makes it an ID selector, and they're like a serial number: one use only and that's it.  These are partly functional on AO3 (you'll see why I say this just a little farther down from here).

To make the word “red” turn red, I'd simply tag that word (or set of words, or whatever) as follows:

<span class="red">red</span>

Maybe the word “span” (a term for distance) isn't familiar to you.  Let's try something more familiar: raw HTML.  Is this paragraph example a little better?

<p align="justify" class="red">
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
</p>

We can even use multiple class selectors on the same element.  For example, if I wanted to mix <span class="diacritics">ầ</span> with <span class="red">ầ</span> in order to achieve ầ (I made these bold to draw attention; they wouldn't automatically become bold just from the CSS used here as-is), then I could simply write it as³

<span class="diacritics red">ầ</span>

Cool.  What if you have 20 paragraphs that you want in red, then 10 in red and italic (or a different font size, or whatever), then 20 in just italic?  Well, aside from writing a new CSS rule that turns text into italic form and combining the class selectors in your HTML (or writing a CSS rule that does both, if you're liable to use the combination often), you might have a lot of copy-and-paste on your hands — or you could just start with a <div> tag right before the beginning of that first paragraph, go to the end of those first 20 paragraphs, toss in a </div> tag, etc., and add the appropriate class selector(s), of course.

<div class="red">

  <p>
  The first paragraph that you want to be re-formatted.
  </p>

  <p>
  A zillion more paragraphs in the middle.
  </p>

  <p>
  The last paragraph of this set that you want formatted in one swell foop.
  </p>

</div>

Rinse and repeat for changing fonts or highlighting, etc..  Don't forget that you can write CSS selectors to perform the same functions as HTML tags (<b>, <u>, <i>, etc. — deprecated these days in favor of things like <em>, but I'm old school [muscle memory]: the AO3 RTE will write “<em>” if I drop a fic in, pre-formatted, but I'll use the HTML editor and write “<i>” when formatting directly); I haven't, but you never know when you might want to change all of one to all of another (or some portion of them, on a case-by-case basis).  Now consider the reduced time factors involved with one method vs. another:

• Scrolling through the entire document and manually hitting the button-on for one and button-off for the other (or even hitting CTRL-whichever for each) in every single instance in RTF vs.
• hitting CTRL-F / ⌘-F / grep to jump to each relevant tag in your HTML, then hitting CTRL-V vs.
• swapping between AO3 and your offline copy for find-and-replace-all vs.
• simply going to your work skin and changing the single value of that class selector's rule (e.g.: “.SecretSquirrel'sAddress { color: red; }” → “.SecretSquirrel'sAddress { color: blue; }”).

That might explain some use for class selectors, but why bother with an id selector?  Well, what if you don't want to sift through a hundred chapters or load them all as a single page (and CTRL-F / ⌘-F / grep) in order to find and change the properties of a specific comment in a thread or a crucial NSN (National Stock Number) somewhere in your document?  Yeah, sometimes a unique identifier can be useful.

Before you go, please, lemme ask just one last question there, Lieutenant Colombo, if I could have a moment of your time — please: “#workskin” begins with “#”, so it's an id selector calling the work skin rule in the first place, so is nesting id="SomeUniqueName" even possible here?  Let's try it out.

#workskin #testpurple {
  color: purple;
}

If ►THIS TEXT RIGHT HERE◄ is purple, then yes, it works (I did do a perfectly functional purple font, so had to rename this one with test so that I could use the regular one elsewhere).  Oh look, it's not purple (and I tried colorizing the span using both id=... as one would here and class=... just in case).
  On the other hand, were I to use that for the name in a link, say... <a name="testpurple" rel="nofollow"></a>, then what? 😉  Well, because my work skin overrides AO3's grey link style, that should look blue to you, unless you've turned off my style or have something overriding it in turn (site skin, browser settings, third party browser extensions, etc.) — but with everything else turned off (i.e.: turning off all but my creator's style), if you then F-12 and inspect that link and turn off (un-check) the box for blue links in the a rule, then that's actually purple (you name a link, AO3 automatically fills in the ID with the same)!

  N.B.: id selectors do work on AO3 mind you, at least in the case of multichapter fics' summaries and header-note / footnote links: FIC_URL_HERE#summary, FIC_URL_HERE#notes, and FIC_URL_HERE/chapters/999999999#chapter_{2, 3, 4, ..., n}_endnotes (where the {2, 3, 4, ..., n} is meant to be whichever chapter number your last chapter is), respectively — though for some reason, those first two seem not to be linkable for a single-chapter work, such as this tutorial.

• Multi-chapter fic's specific-chapter's summary section overall (complete with the 8-digit chapter address) <a href="https://archiveofourown.info/works/88888888/chapters/999999999#summary">like this</a> would go to the summary of whichever chapter that might be (though using <a href="https://archiveofourown.info/works/88888888#summary">only this</a> without the chapter number would bring you only to chapter 1's summary, which isn't much use other than saving 20 characters of space).
    Not sure about how to link to an entire fic's overall non-chapter summary (i.e.: instead going to a multichapter fic's overall initial fic-as-a-whole summary section, or to a single-chapter fic's only summary) without inserting an anchor (though there is a partial-workaround for Chrome browsers: I could highlight a unique word sequence, right-click for a popup menu, select “Copy link to highlight”, and paste the resulting https://archiveofourown.info/works/28934610?style=creator#:~:text=%E2%97%8F%20how%20to into one's referring link).
• Multi-chapter fic's specific-chapter's header-note section overall (complete with the 8-digit chapter address) <a href="https://archiveofourown.info/works/88888888/chapters/999999999#notes">like this</a> would go to the header-notes of whichever chapter that might be (though using <a href="https://archiveofourown.info/works/88888888#notes">only this</a> without the chapter number would bring you only to chapter 1's header-notes, which isn't much use other than saving 18 characters of space).
    Not sure about how to link to an entire fic's overall non-chapter header-note section (i.e.: instead going to a multichapter fic's overall initial fic-as-a-whole header-note section, or to a single-chapter fic's only header-note section) without inserting an anchor (other than that same partial-workaround for Chrome browsers: highlight unique word sequence, right-click for popup menu, select “Copy link to highlight”, paste resulting https://archiveofourown.info/works/28934610?style=creator#:~:text=The%20CSS%20herein into referring link).
• Multi-chapter fic's specific chapter's footnotes section overall (not just one specific footnote), it would be <a href="https://archiveofourown.info/works/88888888/chapters/999999999#chapter_2_endnotes">actually putting the normal number of the chapter in</a> (even though you already have to have the chapter's address in there, which in this example is /chapters/999999999 — without the chapter's address before #chapter_2_endnotes, it'll only bring people to the top of chapter 1).
• Single-chapter fic's footnotes / endnotes section overall (not a specific footnote), it would be <a href="https://archiveofourown.info/works/88888888#work_endnotes">what you see on the left there</a> (no chapter-address, and #work_endnotes instead of #chapter_[number]_endnotes).
    However: there's a way to add an extra footnote to a “one-shot” “single”-chapter (and a way to link directly to that extra, as demonstrated by that link's URL)!
• Multi-chapter fic's endnotes section overall (not the footnote section of some particular chapter) would be <a href="https://archiveofourown.info/works/88888888/chapters/999999999#work_endnotes">actually putting the normal number of the chapter in</a> (even though you already have to have the chapter's address in there, which in this example is /chapters/999999999 — without the chapter's address before #chapter_2_endnotes, it'll only bring people to the top of chapter 1).

Provisos

• Just like you can have a zillion fics, whether you have skins or not, you can just as easily have a zillion skins, whether you have any fics or not.  You can always edit the skin's effects, or change which skin applies to a fic.  You can use a work skin on as many fics at once as you wish — but any given fic can't have more than one skin at a time applied to it.
• This is just my own take on it, but if AO3 permits you to do something with HTML, then go that route instead of relying on CSS solely — if the reader disables creators style, then this will minimize that impact on their reading experience.
  • Aside from layout and style differences if the HTML weren't to parallel the CSS as closely as possible, consider a simple image: one could insert #workskin .pictures { max-width: 100%; height: auto; } into one's skin to automatically scale a map (damned good back-up in case you forget to scale it when you link the image) and hit the image's HTML with something like <img class="pictures" src="URL.jpg" alt="A few descriptive words." />, but without <img src="URL.jpg" alt="A few descriptive words." width="100%" height="auto" /> also in the HTML, that map image could still end up far too small/large if the reader were to disable creator's style.
      UPDATE: not long after I wrote this, I read that AO3 was adjusting the system to ensure that images would be automatically no more than 100% screenwidth; I haven't tested this, since I scale mine to certain percentages for one reason or another, but if so then one might not need to worry quite so much about limiting the size.
• FIFO: First-in-first-out doesn't apply here.  AO3's parser will fix mistakes, but it's still good practice to close your most recent tag or selector before closing less-recent ones.  For example, you could write <span class="blue"><code>.Fo { ob: ar; }</span></code> and it should correct it to <span class="blue"><code>.Fo { ob: ar; }</code></span> for you, but sometimes it will glitch, and you might even confuse it so badly that it can't properly correct it.  (This is otherwise an important practice if you were to write a regular webpage somewhere out there: even if it were to come out OK for you, an older browser might not be able to sort out your mistake.)
  • And here's my code for circling words (a modified version of a StackOverflow answer); I'm still trying to work out how to present a circling that doesn't rely on the border itself (since you can't shrink the border to within the height of the contents without SVG, and I'm still trying to work out if SVG is even supported on AO3 [more on that, here], perhaps a varying gradient could be applied to ch):  ^{Contents ↑}

    #workskin .circle-red {
      border: 0.14em solid white;
      border-radius: 0.3em;
      border-color: red;
      padding: 0.05em 0.05em 0.05em 0.05em;
      text-align: center;
      margin: 0.15em;
    }

    #workskin .circle-green {
      border: 0.14em solid white;
      border-radius: 0.3em;
      border-color: green;
      padding: 0.05em 0.05em 0.05em 0.05em;
      text-align: center;
      margin: 0.15em;
    }

    #workskin .circle-blue {
      border: 0.14em solid white;
      border-radius: 0.3em;
      border-color: blue;
      padding: 0.05em 0.05em 0.05em 0.05em;
      text-align: center;
      margin: 0.15em;
    }

• AO3 does accept the CSS display: inline-block, but keep in mind that whatever it affects won't be able to line break (it will be non-wrapping — ask me how I know  ).
• Also: do keep in mind that even if the reader hasn't disabled creator's style, even though HTML formatting should be OK in a downloaded version, nonetheless the CSS formatting still won't appear in downloads (.pdf, .azw, .epub, or .mobi files)
  • nor will the vertical bar along the left side of blockquotes,
  • nor the overspill of fonts listed in my code after Microsoft Sans Serif (Tahoma, Times New Roman, Cambria, Constantia, Trebuchet;),
  • nor any words copied from https://yaytext.com/bold-italic/ (as in the case of those at the bottom of this tutorial's summary, the {𝑫𝒐𝒏'𝒕 𝒇𝒐𝒓𝒈𝒆𝒕 𝒕𝒐 𝑳𝒊𝒌𝒆, 𝑺𝒉𝒂𝒓𝒆, 𝒂𝒏𝒅 𝑺𝒖𝒃𝒔𝒄𝒓𝒊𝒃𝒆! ❤️} text doesn't show there^{cf. Mar 2024 update} [nor here] when viewed in a .pdf [though that text is visibly different in the summary even in the search lists, implying that the external font pasted in is supported by AO3's overall CSS, therefore CSS effects in a summary can be caused to be visible in search-views to an extent] — though the S̅ from https://fsymbols.com/generators/overline/ will function even in a download, implying that it's maybe an actual font instead of CSS of style="text-decoration:overline" [though inspecting that page showed their “S̅” to be font-family Arial Unicode MS, 'lucida grande', tahoma, verdana, arial, sans-serif;];
    • I assume that it ultimately comes down to whether your own device has any given font available, rather than AO3 embedding-or-not of fonts into the downloads),
    • contradictorily, I tried the other download options and found that the words from yaytext.com (inspect element revealed their bold-italic-serif font-family to be TimesNewRoman, Times New Roman, Times, Baskerville, Georgia, serif;) remained present in the HTML, as did those missing fonts listed in the snippet of my CSS, and the code snippets are in the original code-looking font or similar enough,
    • the words from yaytext.com also remained present in the .azw3, .epub, and .mobi versions, but not those missing fonts listed in the snippet of my CSS (I finally installed Calibre for another purpose, so I finally got around to testing this — though if you grab the work skin's CSS rules, then you can insert them into the downloaded files in Calibre [sadly, the Jay Logan YouTube vid  Download fics from AO3 while keeping custom "Creator's Style"  no longer exists NLT 12 Jul 2024 — but alternatively, here's a Tumblr blog with the same info {I saved a copy of the Tumblr to Wayback if you need it, though it didn't keep the pics, still, the instructions alone are the important bit; NB: there's also html_hell (jihnari)'s method for .epub specifically}; I'm not a Calibre-user as such, and only mentioned the capability here because I know of it — and see my note on adblockers if you're suffering from the YouTube ad-blocker apocalypse]);
      • LingoJam uses Unicode ranges (rather than CSS, SVG, etc.) for the same effect as Yaytext does, and they suggest looking at boldtext.io, who in turn specifically named Math bold italic for the serif Unicode.  Variations of font-family: math bold italic; failed (looking like Times New Roman, given the shape of the lower case “g”), so I popped over to W3's Mathematical Alphanumeric Symbols table and found that the matching subset is U+1D468-1D49B (and Compart offers only a single letter per page, but with a potentially useful “Show More” drop-down to compare and contrast that letter in a number of other fonts)... and immediately thereafter discovered that AO3's parser won't accept unicode-range: U+1D468-1D49B;, so we're back to using the sites to convert on the fly by Java (I tried D = &1D46B;, but it stayed raw HTML [AO3's parser inserted the &amp; itself, not I], definitely not a “𝑫”; one could always resort to CSS's \01D46B, of course, but then there's that little issue of CSS disappearing in downloaded fics). 😑
          On that note, however, my heartfelt thanks must go out to JvlyIsVeryTired, who was so kind as to share with me aestheticfonts.app, which is just such a [free] Unicode site in which one can write larger chunks of text and get results (possibly the ones that you want, possibly not, depending upon what you want out of the many choices available there) — by way of example, I copied the page of one of my works (the entire page, CTRL-A; 3,108 content words, according to AO3's header block data plus however many make an AO3 page's standard navigation stuff, the total of the two coming to 4,349 words, according to OpenOffice... to the extent that one trusts any given word processor's counting, since they all differ on what precisely counts as a single word or double, which symbols are words or not, etc.) and pasted it into the site, and maybe 10 seconds later I had a zillion different results to work with at once (4,156 words in the top-left-most result [didn't check the many others], according to OpenOffice's count).
          Helpful suggestion 03 Mar 2024:  This isn't a great fix, since it's not simply naming some font or redirecting things to a specific unicode range, but if you glance through the Wikipedia page on Mathematical Alphanumeric Symbols and check out the page source view-source:https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols, then you'll note that while you can easily copy the letters from the original and paste them wherever, the source shows the HTML for them (to me, this is preferable, though I suppose unnecessary)... e.g.: U+1D46B = &#x1d46b; → 𝑫 (which Compart covers, too), but here's the awesome part: though AO3's parser converts the HTML to the shape shown in the charts, when you check this source page or when I edit it, unlike the copied-and-pasted stuff from YayText, this directly-HTML-generated entry remains present in at least the .pdf download (I'm not gonna check the rest of the formats), as does a copy-and-paste of the directly-HTML-generated-𝑫... and upon performing a double-check, on a hunch, it seems that the original YayText phrase in the summary (which used not to remain visible in downloads) is also now visible in downloads, so perhaps there's been an update since this tutorial's first writing or it had been glitched back then. 😑
      • N.B.: I've mentioned “inspect element” a few times now, but if you've no idea what that means, there are a few ways to open the developer tools:
        • right-click ► inspect [element] ► styles
        • F12 (at least... as long as your keyboard isn't some stupid-ass design... which mine is... [unless you're not too lazy to reprogram the keys' macros, of course, which I am... 😑 😔])
        • CTRL-SHIFT-I
        • CTRL-SHIFT-C
        • CTRL-U (view page source)
        • ⌘-⌥-I
        • ⌘-⌥-J
        • ⌘-SHIFT-C
        • or several ways on different browser menus
        • and apparently on iPhone or Android (I haven't tested these, so I left the search-results link rather than a specific website's instructions, since they'll change over time)
    • and the diacritics in the .pdf don't have their CSS and so are rendered a little oddly in whichever font the .pdf chose (I'm not going to even try to fix that).

• Finally: RED LENS / BLUE LENS.  Your code might be faulty, sure, or maybe you typo'd something, ja.  Sometimes though, it's perfectly valid code with zero typos, and it still glitches.  This can happen simply due to which browser you're viewing the results in, and possibly which OS your computer (or 'phone) is running, hence my “red lens / blue lens” reference to the old 3D movie glasses: things look different when viewed through different filters.

  Case in point: a friend of mine (jld_az) was hoping to make links within her fics display as a normal link-blue font to the readers (highlighted with yellow, rather than underscored, but otherwise normal link-blue), barring readers' site skins overriding this, of course.  That was before I'd glommed the automatic link-CSS, so I just threw down a basic combo of HTML underscore and CSS blue font.  The code was fine, the work skin was applied correctly, and the HTML was wrapped around things properly to call the CSS rules, but it wouldn't display on the 'phone or in her Mac on Chrome (it did display just fine in my WIN 10 on Opera and Firefox, half-functioned with a blue-grey highlight black-font on TOR, and failed on MS Edge and Chrome [once I turned off my 3rd party app so that I could check, since I run an app that forces all links on every site to appear as font-blue and underscored]).

  It gets stranger.  I tested out the code myself, in the very paragraph that you just read (maybe you can see her linked profile name as link-blue and/or yellow-highlighted, maybe not...), and got different results: zero effect on any of those in my WIN 10 (where I know it had worked for her fic in 2½ browsers) except for full functionality on Chrome (in which I know it hadn't worked for her fic).  Go figure (damned Gremlins...).  This didn't change whether the span was wrapped around the outside of the link (as “<span class...><a href...>name here</a></span>”) or placed within it (as “<a href...><span class...>name here</span></a>”).

  The rule is below, if you're curious, but the takeaway point is that you can't count on things displaying everywhere the way that they display for your browser and OS (or apparently even in your own browser and OS from one source to another).

  #workskin .blue-in-yellow {
    color: blue;
    background-color: #ffff0099;
  }

Testing

If you're feeling really froggy, you might even run the page through a few browser emulators to see how it presumably looks through them.  I don't plan to, but you can find them via Google or DuckDuckGo or wherever.  How well they might work is a dice roll.  By way of example: I know how my stuff looks through several browsers in real world (not emulation), but only when running in my Win 10 environment; I went through Chrome and tried http://classic.oldweb.today/ for shits and giggles, where I ran an emulation of Firefox (which I have, and so know how my stuff looks in Firefox on my system) and they set that up as if in Linux (which I'm not running, though Mint looks tempting), and their result wasn't the same, but I don't know if I should have expected it to be since I'm not dual-booted.  This idea becomes increasingly unappealing if one considers that apparently most readers access AO3 via their 'phones, and there are a lot of variables there (worse, if you tried to cover everything possible).

Alternatively (and maybe more easily, though I still don't know that it is or isn't reliably), as mentioned earlier: you can simply emulate other browsers within your own browser, and here's a page (same one as earlier) that tells you how to change your browser's user agent, though there are no doubt many more like it; as mentioned before, that doesn't seem to display as one would expect, so here's a free webpage to actually see the results. 😉

And finally: text below illustrations...
(with some semi-extensive coverage of video, and wrapping things up with one really cool playlist style and a surprisingly invisible audio player )

Incidentally, though this is still in line with the A/V above, rather than fonts-specific, I'd feel like a complete heel were I not to mention La_Temperanza's [AO3-tweaked version of layouttest's LiveJournal] work skin code for How to make a Rounded Playlist; even though I'm not looking to add playlists to my fics, I soooo want to use this thing: it's a smooth and simple interface for the reader, and beautifully clean code.  (And just as a kicker, layouttest's old code testing page on altervista.org is still functional over on its archived Wayback backup copy.)

25 Nov 2023 AUDIO CONTROL PROBLEM DISCOVERED: I plunked a standard <audio src="URL_Here" controls="controls"></audio> into a testfic for unrelated reasons and the audio controls didn't appear to exist, though it turns out that they simply hadn't appeared (they were invisible); poking around, it turned out to show up visible (as one does) without my work skin (and working properly).  Here's what I mean:

  If you can see an audio control there, great, if not, then it might be hovering between this line and the one above, or it could be in the first inch or two of text in this line: hover your cursor around until you get a hand-icon and start clicking (you might get the control list popup, or you might begin playing the SFW audio)
  I have too much CSS in my work skin to try to fix that without good reason (and I don't do audios, so no reason yet), hence can't tell you where the fuckery occurs if you import my entire work skin or whichever chunks are causing this, but even if you don't, it's a lesson: just because none of your work skin has anything at all to do with something (audio in my case, but it could be anything), doesn't mean that it won't somehow manage to dick it over anyway.
  Never mind: it got copyright struck (Wayback isn't immune, it seems).

😸   BONUS ROUND:  you've been patient, so here's your cookie!   😸  ^{Contents ↑}

Before we get to the bit that intrigues me, I'll mention one of the more recent bits that you might have run into of late and which certainly showpieces some flashy potential.  I'm assuming that you've probably dug through available resources on work skins, CSS, and semantically similar variations, but bear with me for a moment here.  (By the way: I didn't use any of the code from “All the emoji” in order to emplace the emoji in this tutorial, I just copied them from Facebook and pasted them right in without thinking; I got lucky, but this also means that maybe copying from Facebook is a workaround, or that AO3's database now supports emoji...)
  OTOH, strange things happen with emoji: this section's header used to have normal yellow-filled cat faces,  but I just noticed (28 Dec 2021) that they'd become non-filled monochrome  — disregard last: they're back to being yellow cat faces, NLT 27 Feb 2022 <sigh... I give up, whatever>.  I checked without creator's style (which I didn't expect to fix it), tried turning off my 3rd party plug-in that forces all links anywhere to become blue underscore (as if that's somehow related?), and even replaced them just in case, but no dice.  Then I swapped them out with a similar set (prettier, too, I think), but same problem.  I even tried the HTML &#128568; and &#x1F638; for them, and then the Windows emoji keyboard.  <shrug!>
  Tested for variables (even as I thought I should maybe update my browser): it's monochrome in Chrome (hilarious, but doubly odd, since they're functioning on Chrome outside of AO3) and MS Edge, but perfectly fine [yellow filled] on Firefox and Opera (even in AO3)... and TOR shat out completely with non-emoji boxed codes 01F638 and 01F604 (even on DuckDuckGo and Google).

As a late edit, this paragraph is probably better fit with the theme of skin873 (farther down), but I'm putting it here because of its intermediate level material (way past this 101 tutorial).  Skin873 is more for the advanced students (which I most certainly am not).

• For those who wish to know just what they can do with their outside CSS skills, or wish to work at a higher level than just fonts, please see AO3's “full list of supported CSS properties”;
• for those who'd like to really stretch what they can do with AO3, but need more intel on what's where here, please see dustnik's “AO3 CSS Selector Ids and Classes”.  You might want to check compatibility of any specific CSS property at caniuse, along with the usual suspects of MDN and W3.
• 26 Jan 2025 update:  Cf. Targeting specific AO3 work sections (not site) with CSS effects for an in-depth breakdown of how to find what's where in your AO3 works, and affect same with your work skin.

I feel that I should mention a couple of tutorials that address some impressive effects.  How to Override the Archive's Automated Chapter Headers is more tutorially dry-seeming (but beautifully concise) and less dazzling than Bleed Gold (I call it that due to the .png header [even though it's green onhover], but the title is actually the slightly less catchy “CSS in Testing”), and one can see the impact far more clearly in Bleed Gold — but Bleed Gold presents a surprising layer of subtlety in its End Notes.  Although these two examples present far more flexibility than I'm liable to make use of, those of you who seek to present eye-catching effects (webpage-like, in the case of Bleed Gold) in AO3 could benefit from it, and there are others:

• comic book thought bubbles (disable that tutorial's style to see their CSS that they plaintexted into the body of their tutorial),
• sticky notes,
• La_Temperanza's OnHover (which can have trouble rendering certain characters without using CSS (ISO)), and Simbeline's OnHover (designed to also function on 'phones, though it might not work on screen readers [and obviously not with creator's CSS style turned off, or in downloads {since those don't incorporate the CSS}]), or the appealing text bubble of Red_Vines's approach,
  • though you could simply eschew the CSS in favor of pure HTML using <acronym title="Here you'd enter the words that you want the hover-box to show">using some inline HTML for a little OnHover box</acronym> (same effect as <abbr title>) from CodenameCarrot's guide to limited HTML (caution: though this OnHover box functions in HTML download for me, it might fail on mobile devices, and semi-fails in .pdf [the hover field appeared, but contained only a clickable link back to this tutorial, rather than displaying the correct text]), or Otter_Von_Bismarck's <span title="Mouseover text goes here">surreptitious mouseover</span> (hover over those words, which don't look as if there's an OnHover, and you'll get a text field [same invisibility effect as you'd get from <dfn title>], though it too might have trouble on 'phones),
  • NB: the <... title...> approach isn't limited to just those, but will instead attach to any HTML element — poke around and you'll find that you can assign a hover field to whole paragraphs <p title...> and list items <li title...> (hint: you're reading a list item right now, so maybe there's something to see here with a hover) and even entire divisions <div title...>, and even images <img src... title...> (haddya think XKCD does it? 😉),
  • Finally, returning to the question of CSS, some might prefer InfinitysWraith's popup CSS text approach,
  • NB: one might wish to avoid the issue of CSS functionality (it doesn't download, creator's style can be disabled, etc.), and simply use linked footnotes to jump back and forth quickly at a click/touch (thus not needing to scroll back and forth constantly),
  • Late addendum: FidgetScribbles made an excellent write-up (Very basic how to: hide text (spoilers) on Ao3) on a spoiler effect that uses only the HTML tag <details> that you might want to check out (note that while being HTML means that it will typically still work in a download, unlike CSS approaches, though apparently at least right now gets lost in epubs),
  • Very late addendum: Skits's OnHover in Testing Work Skins - hover divs is very effective, and well worth checking out (and royjo adds to it with a tweak to the code in their comment [differing slightly both from what's shown in Skits's ch. 2], the execution of which is shown in Workskin Workshop, though that demo's page source, row 249-270 [view-source:https://archiveofourown.info/works/43803639/chapters/110149497] shows yet another variation on the actual specific CSS used),

• Screenplays (though this one might be simpler),
• black backgrounds — I've seen at least one,  but can't find it now  (EDIT 09 Jun 2022: turned out to be in Threadzless's How to make the probe text have colors , chapter 2; I was new to doing CSS in AO3 [I hadn't mucked with such since ~'04/'05], but you might wish to check it out), so here's InfinitysWraith's example from r/AO3, who notes that one can use the nested id pair “#workskin #chapter-1” (etc.) for per-chapter effects:

  #workskin {
  background: black;
  color: white;
}

• Choose Your Own Adventure (La_Temperanza covered these beautifully, and MohnblumenKind hit them succinctly in chapter 6),
• iPhone screenshots (again: disable that tutorial's style to see their CSS that they plaintexted into the body of their tutorial),
  • and ProfessorMotz (Motz)'s fallback that will permit text message-looking sections of a fic to at least stand out as separate ❤️ from the main body (as blockquotes) in the event that the CSS is turned off, overridden, un-downloaded, or otherwise inaccessible,
  • and FESTIVEFERRET's work skin builder tool if you want what appears to be a really easy and intuitive way to get the CSS coded automatically (and even easier if you wish to have a lot of texts in a string and don't relish having to code for it all),
• Even layouts for podfics for readers' convenience,
• or ElectricAlice's “How to make a fanfic header Ao3 Style inside your own fanfic” (with a lot of good material on her Tumblr), which might be a good launching point to modify for those who need more note-space than the header-notes and footnotes permit,
• or unpredictableArtist (wovenstarlight)'s “My S-Ranks: System Windows” (really astoundingly good piece, this, hence my specifically adding it 02 Apr 2022), which could be used to very good end for GUI-looking illustrations in RPG-anime style (for example: Grinagog's “RPGs for Dummies” fic),
• and the beautifully functional spreadsheets of “Learn to (Microsoft) Excel” (a bit too late for me to bother redoing a couple of my pieces, but this baby scales the display width [i.e.: it doesn't disappear off to the right or warp aspect ratio to fit] and keeps the scroll bar where needed),
• though of course, there are the ever-popular Wall Of Tag blockers (soon to be less necessary, given the  upcoming  semi-retroactive limit of 75 tags):
  • site skin rules that a reader can likewise use
  • to block specific works
  • or block an entire author by their user number (UPDATE 06 Feb 2023: this might soon be an AO3 feature though, according to AO3 Admin Post 24853, though one might still need a Site Skin to block specific tags)
  • or simply shorten walls of tags
  • / walls of 'ships,
  • najio's extremely detailed and in-depth How to Block Tags With Site Skins (And Get Real Specific About It)
  • and there are other rules with different approaches to do this,
  • or just using browser extensions,
• etc. (and I keep adding to this list as new rules get published, as in the excellent example of blocking the entire author, though such a shadow-banning approach really should be used only in the most egregious cases).

When actually viewing the fic's page itself, the Bleed Gold effects on its summary contents are present when set to Show Creator's Style, and absent when set to Hide Creator's Style.  The fun trick (that subtle twist that I mentioned initially) comes when you click “(See the end of the chapter for more notes.)” [sic]: it goes to an entirely different chapter (cf. the exact wording of the “note” link vs. standard w.r.t. the URL of Bleed Gold vs. URL of its notes): bluntly, they're actually not that same chapter's end notes themselves at the bottom of the page (though the formal function is pretty much exactly that), but rather a whole new chapter with a somewhat different summary.

Addendum: for those who would prefer some layer of security against plagiarists copying their material (which still won't work against disabling creator's style, or viewing the page source, or downloading — remember: if you can see/hear/feel a page [depending upon browser / TTS / braille reader], then it can be copied, and the whole point of writing AO3 stuff is for readers to be able to read it...), I give you the following code from 0KKULTiC on Twitter (who states that it doesn't work on iOS Safari) — they provided a linked example that I was still able to copy and paste from (without first disabling creator's style, or viewing the page source, or downloading, etc. [EDIT: I checked this much later and found that their example didn't have the rule in its applied work skin, presumably because of the rule messing with accessibility as 0KKULTiC mentions later in the post's comment thread, and can't help wondering now if the rule had been removed before I had checked the source]), but the principle is still worth mentioning:

#workskin p {
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
}

UPDATE 18 May 2024:  Due to all of the hype lately about lorefm (which seems to be being shut down) scraping AO3 fics and turning them into audios without permission (using an automatic opt-in assumption, though apparently one can e-mail them one's username and request an opt-out... hang on, lemme go get my grandmother's maiden name and social security number for you...), I revisited this work skin rule (my daughter ❤️ sent me a Pillowfort thread where they had linked the CSS in someone's Tumblr).  I happen to be logged into AO3 on Chrome from long-standing habit (might swap that to another browser soon, since Chrome's memory hogging again kinda badly lately), so I re-tested this rule and opened this fonts tutorial in Firefox (logged out of AO3 there) and discovered something fascinating:

• it worked fine and prevented my basic copy-and-paste attempt, as one would expect (and of course failed as soon as I hid creator's style, just as it should then fail, and worked again upon re-enabling creator's style, just as it should);
• upon removing the rule from my work skin, copy-and-paste worked fine again, but only in a new Firefox tab, while continuing to fail in the old unclosed-as-yet tab, where I had first tested the preventive rule, even after refreshing (i.e.: the then-removed rule remained in that page's source even after refreshing).

So... takeaway point: when testing any of your CSS, at least if you're checking out the results in a logged-out browser (hence from a reader's perspective, rather than your own as the author), or at least in Firefox at the moment, and you see no change in the resulting page even after having changed your work skin (with any rule, not just this one)... you might want to open a whole new tab rather than simply refreshing the old one.

Now for the bits that I haven't seen mentioned anywhere else.

I looked under the hood [with the usual inspect element and view page source].  Found inherited font-family 'Lucida Grande', 'Lucida Sans Unicode', Verdana, Helvetica, sans-serif.  Couldn't shake a feeling that something was “off”, especially after seeing fonts of .pdf and .html downloads from fics with no CSS in the first place.

Tried identifying fonts through cropped shots of AO3 online vs. downloaded forms using
  https://www.myfonts.com/WhatTheFont
  (NB: yes, you can drop a font into a regular document and see which font it says it is, I know [considering how much I use the “paste special” → “unformatted text” option to avoid text keeping the original format after all... so I tend to forget the ability to identify fonts thus], but that's not a great help [other than narrowing down] if it comes from a rule that lists more than one font option [at least in OpenOffice, anyway; maybe your word processor does a better job of specifying which ones it has available, so that you can bet on the first one]; I'm not certain of how different processors operate, but I want to know for sure which font a site might be using, if they embed their fonts [so that readers will see things in the intended font rather than relying upon those available within the users' devices].)

Right-clicked to inspect element, noticed div.userstuff.module (cf. user agent stylesheet in the flashy pages, e.g.: Sliding Doors [the body of which explicitly includes /* CSS notes */, but was written in 2011, hence prior to the note-scrubbing that occurs nowadays {which I presume was part of the 2016 Archive 2.0 sweep}, therefore its CSS likely no longer includes them])
  <link rel="stylesheet" type="text/css" media="screen" href="/stylesheets/skins/skin_873_archive_2_0/1_site_screen_.css"/>

Long story short: the trail led to skins/873 — not itself a skin, but a parent page (either it simply lists available skins that happen to be linked, or site skins are chained to call 873 itself which in turn calls from any skin pages chained into it).  There are 32 skins listed there right now, so I'll drop only a couple of small sample snippets.  It turns out that it's not a secret though, just not something that you're liable to think about if you were to run into it early on.  Work out which ones are used where, and you might have an easier time doing your own site skins (and probably come out with a few nuggets for work skins — hell, I did [just look at the links in this work] — and CSS in general [those of you with a broader skill-set might prefer OTW's source on GitHub]).

  https://archiveofourown.info/skins/842
  Archive 2.0: (1) core skin by AO3

body, .toggled form, .dynamic form, .secondary, .dropdown {
  background: #fff;
  color: #2a2a2a;
  font: 100%/1.125 'Lucida Grande', 'Lucida Sans Unicode', 'GNU Unifont', Verdana, Helvetica, sans-serif;
  margin: 0;
  padding: 0;
}

  https://archiveofourown.info/skins/843
  Archive 2.0: (2) elements skin by AO3
  From what I can see, it seems that at least some of the raw HTML inline-seeming elements (to wit: “<code>”, if nothing else) that we code in our writing aren't actually running inline, but are apparently instead simply acting as class selectors and calling the functions defined in the relevant AO3 stylesheets (depending upon whether the element is in the summary/notes, body, etc.).

body {
  font: 100%/1.125 'Lucida Grande', 'Lucida Sans Unicode', 'GNU Unifont', Verdana, Helvetica, sans-serif;
}

h1, h2, h3, h4, h5, h6, .heading {
  font-family: Georgia, serif;
  font-weight: 400;
}

blockquote, pre {
  font: 1em 'Lucida Grande', 'Lucida Sans Unicode', Verdana, Helvetica, sans-serif;
  margin: 0.643em;
}

kbd, tt, code, var, pre, samp {
  font: normal 0.857em 'Monaco', 'Consolas', Courier, monospace;
  margin: auto;
}

Well, you get the idea.  The rules that I showed here are only relevant to fonts (since I'm focused on simple typesetting and basic layout, mostly), but the original sheets contain a lot more formatting code than just this stuff (takeaway point if you're looking for bells and whistles).  Have fun!  😉  (I'm going to go back to trying to get my charmap to gen “␢” from U+2422 or ALT+09250 [and no, at least in OpenOffice, the U+337 combining short solidus and U+338 combining long solidus come out like a Cronenberg body-horror, though here are the respective HTML b&#823; b̷ and b&#824; b̸ results as rendered by your browser and site skin and device's available fonts, where the second should almost match the earlier-linked &#9250; “␢” glyph that I'd originally copied directly as a glyph {rather than having written out the HTML entity} from a Google search result; probably the Compart or Wiktionary entry, though this StackExhange CSS solution for combining zero-kerned “|◄” and “►|” and this general overstrike question {even more so}, and maybe this one and this one offer promise for overlaid “b/” for the truly bloody-minded 🤣 {unless you prefer CSS to angle a strikethrough}, but that's a lesson for another day — besides, I think that there's at least a specific application to be had {perhaps it could be generalized} using something like InfinitysWraith's background text {which makes more sense after seeing it with the style disabled view, and a lot more sense after going through the actual source code view-source:https://archiveofourown.info/works/25174384/chapters/87420256} possibly along the lines of the tweaks that I used for a much larger scale background, but aimed in this case at overlapping exactly one glyph {per specific rule} over any given glyph that you span {with as many rules in that span as you wish to select for its class}... though come to think of it, cf. my theta hat's solution for another possible palimpsest lead]... and maybe work on perpetual motion for an encore.)

For the particularly stout of heart, there's also AO3's source code on GitHub.
  Or you could simply poke through their stylesheets at

• https://archiveofourown.info/stylesheets/skins/skin_1_default/1_site_screen_.css,
• only screen and (max-width: 62em), handheld, https://archiveofourown.info/stylesheets/skins/skin_1_default/4_site_midsize.handheld_.css,
• only screen and (max-width: 42em), handheld, https://archiveofourown.info/stylesheets/skins/skin_1_default/5_site_narrow.handheld_.css,
• https://archiveofourown.info/stylesheets/skins/skin_1_default/6_site_speech_.css",
• https://archiveofourown.info/stylesheets/skins/skin_1_default/7_site_print_.css,
• https://archiveofourown.info/stylesheets/skins/skin_1_default/8_site_screen_IE8_or_lower.css,
• https://archiveofourown.info/stylesheets/skins/skin_1_default/9_site_screen_IE5.css,
• https://archiveofourown.info/stylesheets/skins/skin_1_default/10_site_screen_IE6.css,
• and https://archiveofourown.info/stylesheets/skins/skin_1_default/11_site_screen_IE7.css.

Oh, yeah... one last thing: I don't really speak Java, but if you do, then you might like to know that the source code of this work (and any other) states explicitly (presumably for page buttons and such, rather than for fic-body material) “While we've done our best to make the core functionality of this site accessible without javascript, it will work better with it enabled. Please consider turning it on! ”, along with a few links (just CTRL-F for “Java” in the source).  I poked around and found an unofficial 2017 API, if that helps any!
  NB:  With that said, it might be worth noting that in AO3's Terms of Service FAQ (in the Spam and Commercial Promotion subsection, oddly enough, though specifically in the Technical Integrity sub-subsection, which makes sense), they state:

As a practical security matter, we will not be allowing javascript on the Archive, and only a limited subset of HTML. Something elaborately custom-coded would have to go on your own webspace. That is just because there is no secure way to allow people to start uploading unfiltered code. Our limits are designed in part to improve accessibility for all users, but we aren't trying to impose any editorial standard. The basic reason is simply that it's not technically safe to allow unfiltered code.

  EDIT 15 Mar 2025:  In the past month or two, I've run into a couple of instances where external Java was accessed via links in order to affect the fic, so maybe that's an option.

And for extra credit for the real Wizzes out there: can you explain this quirk: chapter-footnote appears in single-chapter work (click it, then look at the extra footnote)?

That's all, folks — but if you like my writing style, then ►please subscribe to my author's page ◄ in order to get constant updates on all of my work, or just browse through ►my collections◄, where I have everything arranged thematically (dice-RPGs, zombies, food porn, sci-fi, romance, comedy, etc.) for easy perusal!  (Unless you'd prefer the straightforward ►chronological order ◄ list of my works, of course.)
  NB:  If the work skin [for this piece or any other] was stripped by downloading, so that you can't see any of the pretty fonts or highlighting or any other special effect, then please see the sub-section on re-inserting rules.
  And PLEASE, if you have any questions at all about the material in this tutorial (or the next one, of course), DO ask!  The classic aphorism that “There's no such thing as a stupid question” is very true (though I contradict this in thinking that I ask stupid questions all of the time, but I also assert that they're still necessary, or else I wouldn't have needed to ask them — and they can always lead to an interesting [and possibly wholly unrelated] new idea) — maybe it's something that someone else needs to know too, or maybe I screwed up the explanation — and I'll do my damnedest to answer it (or try to at least find somewhere to point you in pursuit thereof)! 🙂

Also in this series:

• Part 1 — How to AO3
    (general info. for newb.s, but includes tips and information that years-long veterans often don't know)
• Part 2 — How to make and fix a series on AO3
    (plus unrelated tips re. Wayback, different spaces and dashes, TTS problems)
• Part 3 — Analyzing AO3 reader traffic flow
    (one's own fics' reader traffic)
• Part 4 — A year-long AO3 overall traffic analysis
    (when do people upload, read, comment, kudos, and bookmark?  Reader and new-upload traffic in general, across all of AO3⁠ ⁠)
• Part 5 — Fonts, and colors, and work skins, oh my!
    (change your letters and ink color, see others' work skin secrets, etc.)
• Part 6 — Chess puzzle extravaganza
    (256 randomly selected preconfigured chess puzzles, a new one with every refresh
    [secret message-reveal from BBEG, because of course];
    no JS: just HTML and some CSS)
• Part 7 — Targeting specific AO3 work sections (not site) with CSS effects
    (wanna put some color into your CSS-verboten summary?  Maybe drop an image below your series link, or style your comments section? 😉)
• Part 8 — Inside, Outside, Upside-down
    (a showpiece of fun that one can have with CSS — a challenge puzzle, rather than a tutorial;
    incl. CSS on a single paragraph within the work summary, among other things;
    try to navigate it, work out its little puzzles, and work out how it was all done;
    caution re. volume in ch. 1, and flashing lights on :hover in ch. 2)
• Part 9 — Green Rain font, from The Matrix
    (several ways to drop Green Rain into your background, simulating the digital rain effect)
• Part 10 — Building ConLangs, with a concrete example
    (going about constructing one's own invented language: words, grammar, writing, etc.)

NB:  If the work skin [for this piece or any other] was stripped by downloading, so that you can't see any red ink or yellow highlighting or any other special effect, then please see my fonts tutorial's sub-section on re-inserting rules.

O ~~~ O