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).

 

 

 

Just the tip?  ^{Contents ↑}

Quick AO3 search tip before we begin:  You can easily search for a fic on AO3 by entering a fic title into the search bar's edit field, but did you also know that series can be searched for by using {series.title:SERIES_NAME_HERE} minus the braces (and do please note the dot in series.title and the one and only colon : that's part of the search Boolean before the actual name of the series)?  Give it a shot, though the same issue will occur if a series has a colon or exclamation point (etc.) as does for fics with punctuation marks in them.  Here, try {series.title:TLA: the three letter agency} and then simply {series.title:the three letter agency}, and here's what you'll get: fail with the 'TLA:' colon in the search and success without the 'TLA:' colon in the search (and you can find other AO3 hidden search operators in Admin Post 10851, BTW — with more in Post 329 [some repeats, some not], 333, 349, and 529).  Happy hunting! 😉

NB, 10 May 2025:  Cf. najio's How to Use Hidden Search Operators (And Get Real Specific About It) for an excellent breakdown on the topic (or at least for the really juicy little tidbit in chapter 2 re. searching by authors' User ID number [or just any random User ID number, really] with user_ids: ######## and whatever ID number to replace the pound signs there, which you can find in their profile at https://archiveofourown.info/users/Some_User_Name/profile), and this comment thread with Mewsmodeus (Mewzebub)'s fantastic CSS search term info..

  It kinda came up while considering overall AO3 upload traffic times, w.r.t. the peaks and troughs of one's own reader traffic in Analyzing AO3 reader traffic flow (and it's great to learn, 'cause knowledge is power!).

Just as a side-note on searching in general, there's an entire Tag Search page unto itself.  It seems a bit too trivial to mention, but there's a reason: it's more flexible (at least with tag searches) than the usual Advanced Work Search page.  How so?  Well, try comparing (or rather contrasting, as you'll see) the results of searching for "*[*" in the one and in the other, try again with some other special symbol such as "*:*" — and be sure to include the asterisks, so that the search isn't looking for a tag that contains only that symbol; the asterisks tell the search that you're looking for tags that include the symbol regardless of any other content being present or absent.  Notice the difference?  The regular Advanced Search page fails to find any such tags, but the Tag Search page will cough up 13,443 works with "*[*" in at least one tag ...and oddly 14,576 if searching "*]*" (at least as of 08 May 2023).
  I know that this won't help with finding titles [of series or individual works] that contain special symbols, but I figure that someone will want to know about this anyway. 🙂

On a belated tangent to that side-note, it occurs to me that although many people do know of the Wayback Machine, many others don't or might not think of that when they find a favorite fic deleted.  This is your friend; there's no guarantee that the fic will be there, but it's worth a shot.  All that you need to do is plug a given fic's URL (e.g.: https://archiveofourown.info/works/88888888) into the search box (and press the button marked Browse History).  You might want to append ?view_full_work=true to the end of the URL; likewise, if it's an E rating (or M, IIRC, or Not Rated) and Wayback does have it cached, then there's a Proceed button that should show up in a drop-down banner and is sometimes problematic, in which case you might want to add ?view_adult=true (if adding both, then add the ?view_full_work=true query string parameter-and-value pairing [the ? is a separator, ending the actual address and beginning the query string] and then an ampersanded [used to join a query string's first parameter-and-value pair with the next, and the next, etc.] &view_adult=true parameter-and-value; swapping the parameters' positions the other way around doesn't work).
  You might also want to save a fic onto Wayback, which isn't exactly searching for one, but since I mention the one, perhaps I should cover the other.  If a fic (or almost any webpage, of course, though some are excluded from Wayback, such as YouTube or Quora) exists but isn't already saved, then Wayback will usually offer to save it; if so, there will be a button that says Save this url in the Wayback Machine (click that and you get a new page; there are a few checkboxes, some filled, some not; I leave it as-is other than to add a check to the empty box that says Save outlinks); if it doesn't offer to save the page for you, then go back to first page that I gave you (not Wayback's homepage) and scroll down to the bottom-right where you should find an edit field to enter a URL and a title of Save Page Now, which will bring you to the Save Page Now page, and follow the same process.  At this point, I do specifically add the ?view_full_work=true query string parameter-and-value (e.g.: https://archiveofourown.info/works/88888888?view_full_work=true), and if it's E or M or Not Rated, then I also add the &view_adult=true parameter-and-value (e.g.: https://archiveofourown.info/works/88888888?view_full_work=true&view_adult=true [adding the ?view_full_work=true query string parameter-and-value only makes it easier to save all at once, instead of by individual chapters... which can unfortunately make it more difficult for searchers to find if they include a chapter number {so you might want to save your fic both as a single complete work all at once and by each individual chapter, in order to ensure that it's as fully accessible as you can make it} — but adding the view_adult=true portion {as a standalone ? query string or as a follow-on & parameter-and-value} is vital for >Teen fics or else Wayback will save only the summary page and the potential-adult-material warning banner, and nobody will get to read anything further in that that]).
  Of course, if you're looking for a deleted fic, then that Wayback info is a little late and only as good any prior saves; if that's a bust, then it's worth asking around on r/DeletedFanfiction.

Also, as a tangent to the tangent: when you're searching for anything on AO3, you probably already know that you really might want to be signed in.  Not all fics show up when you're not logged in (which still managed to surprise me while running some simple searches for my traffic analysis follow-up of AO3 overall [not the first one, which is for analyzing one's own fics' traffic] meta-work [to be now uploaded Feb/Mar 2024], when I discovered the distinct disparity between those searches' numbers in one browser while logged in and another browser where I wasn't — how much of a disparity depends upon the type of search [full details in that upcoming analysis], but the resulting counts of various types of searches when logged-out as a percent of the counts when logged-in [02:31 on 06 Jun 2023 through 11:01 on 08 Jun, for reasons] hovered between 90(+)% and 92(+)% [though the non-searched numbers displayed on the homepage showed a ratio of 100.5(+)% on mean average]... there are more details, but they can wait for the big picture analysis in Feb/Mar 2024).
  It being a good idea to be signed in is already a given that a lot of people are aware of, since one can lock fics so that they are readable only by logged-in account holders (mostly to prevent SPAM and abusive comments).
  Just now though (02 Sep 2023), a friend (Foxydemon911) asked me to run a search to see if a certain orphaned fic were available anywhere (maybe AO3, maybe another fic site) in a more-complete form.  This is where it gets funny: the fic in question isn't particularly relevant, but for the purpose of demonstration here, it's Lunchtime, (with a Wayback failed-save [“Green indicates redirects (3xx).”] of 18 Jan 2021, so I fixed that) — it's marked for General Audiences and not locked against random reading by those without accounts, but maybe there'd been a hiccup.  I ran a quick search (on Firefox, where I'm not logged in) within AO3 using two tags that seemed likely to whittle it down quickly (in case the fic existed in another form with the same tags), but got bupkis... 31 results, but this specific title wasn't there (I hadn't even gone digging yet for the same fic under a different title).  Realizing the problem (I thought), I ALT-TABbed to Chrome (where I am logged in) and got 33 results, but still excluding this specific title.  I even tried it with a swap of the relationship, which the Tag Search shows specifically to be synonymous, hence shouldn't matter either way, and instead got 0 [zero] results (though I should mention that it did show up with the title added to the searches).
  Takeaway point: just because you can see that a fic exists, hence know that it's there, doesn't necessarily mean that you can find it by an AO3 search [i.e.: you might need the exact URL instead], even if it's a General Audiences fic that's not locked for Account Holders only and you're logged in with an adult account, so if you want people to find your fics, it might be a good idea to link them, not simply leave only the title for them to search out.

 

 

〽 ♫ ♪  Stop that glitchin'  ♪ ♫   ^{Contents ↑}

NB 23 Feb 2025:  My past couple of uploads to series have functioned properly, without the glitch below having hit them. ❤️  Maybe the issue is fixed, though I'll keep this entry against the possibility of future glitching.

You know that glitch that [sometimes ] kicks in when you edit a series — the glitch whereby “Next Work →” links don't show up in the top data block?  ( Maybe I'm the only one with that luck, but  it seems to kick in once I've linked about 5-6 stories together in a series, and then happens every time that I add a new one to that series — but I just now [01 Aug 2022] walked a friend through the process, and he had only 3 fics in his series. [Update-to-the-update: today, 15 Jan 2023, I posted a sequel as the 2^nd fic in a series, with only that 1^st fic already there and no others, and that damned Jinx Fairy struck, so... you just never know.])
  Or the related series-editing glitch that causes fics to double-enumerate, showing the same number in a series (e.g.: two “Part 4 of...”, but no “Part 3 of...”)?
  Here's a workaround to fix that (each time that it happens):

1. click each affected story's “Edit” button,
2. don't even bother editing anything, just scroll down and hit “Post”, and the “Next Work →” link should now display in that story's data block where it belongs.
3. Rinse and repeat for all other affected stories.

Va bene.  Crisis over; go have a celebratory coffee and cigarette, you're G2G.

...unless that glitch wasn't the problem, and you're instead here because your series has suddenly disappeared from the page that shows all of your different series.  Don't panic.  If your series has any fics in it that are in an Unrevealed Collection, that'll do it (and maybe you didn't do that — someone might have added it to such a collection, probably innocently, or perhaps some collection suddenly became Unrevealed; you'll just need to figure out which fic it is,  and maybe consider going to your user preferences and DE-selecting [turning OFF] the automatic-approval checkbox for fics to be added to collections)  (this last no longer applies, since the Automatically agree to your work being collected by others in the Archive option has been deprecated as of 31 Mar 2023, per Release 0.9.338 as noted in 2023-03-31 22:31:42 UTC Admin Post).  If that's the problem, then you have three options:

• You can remove that fic from the series (and leave it in the Unrevealed Collection),
• or remove that fic from the Unrevealed Collection (and leave it in the series), in which case you might wish to leave a bookmark to your fic in its place (this will permit your fic to be visible to the readers as part of that collection without making the fic itself invisible to everyone else on AO3),
• or make that collection publicly visible (and leave that fic in the series and in the now-visible collection);
• four options, technically, if you count simply leaving the fic(s) in the Unrevealed Collection and in the series... and so don't actually fix the problem at all (or five options even, if one considers outright deleting one's fic, which is seriously cutting off your nose to spite your face).

Side-note:  While this isn't exactly a glitch, do be careful nonetheless when initially posting a fic's first (or only) chapter.  If you spot something right afterward that needs editing, and ALT-◄ (or back arrow on your browser) in order to edit the problem in that first edit field, and proceed to re-post it from there, then you'll generate a new / extra first chapter (the original un-edited version now being the second chapter).  This is easily fixed, of course, by deleting that near-duplicate, but also easily avoided by simply clicking the usual Edit button, making your edit in that next page, and posting from there; should you then need further edits, it's safe to ALT-◄ to that second edit page back and forth as usual without issue, just not to the very first one is all.

(NB:  For the curious, the section title Stop that glitchin' is a shout-out to the 1969 cartoon Dastardly and Muttley in Their Flying Machines [and sorta the tangentially related Wacky Races, too] and its title song Stop that pigeon [not the 2019 instrumental Stop Glitchin]; given the underlying theme of the 'toon, the title here is also a wry and half-joking / half-cynical intertextual commentary on the futility of stamping out a glitch in the carpet, since two more will just take its place — not to mention the ironic Mandela Effect [read as “glitch”] of my knowing damned well that the title was Catch..., not Stop....)

15 Oct 2023:  I was looking around to see if the UTC date glitch was still an issue or fixed yet (see the header-note for details; and yes, it seems to be mostly fixed, but is still sometimes an issue for some people ) when I ran into mention of someone's fics' dates all having re-dated themselves (with a couple of commenters saying that they had had the same thing happen to them).  I'm still trying to run down more info on this, but it seems not to have a lot of press; as well, the only fix that anyone's named so far is to simply edit the dates for each fic manually.

 

 

Serialize the stories  ^{Contents ↑}

Now, with that out of the way, most people probably came for the building-of-series info, not the emergency instruction manual there, so without further ado... to make two or more stories on AO3 into a series:

Click a story's “Edit” button (it doesn't matter if it's the story that you want to come first, last, or in the middle, since you can re-arrange the sequence any which way whenever you want).

 

That will bring you to the familiar editing page:

 

Scroll down ~4/7 of the page, to the section right after where you write summaries and notes:

 

Click the checkbox that says “This work is part of a series” ?:

 

If it's going into some series that already exists, then hit the drop-down menu and select the appropriate series (if you screw this up, you can fix it in a heartbeat, or change your mind a dozen times, or add it to several different series — it's EASY):

 

If it's a brand new series, then just go to the next box instead and type in whatever you want to name it (and you can ALWAYS rename it, since AO3 gives things a URL by unique serial number, not by whatever you name anything):

 

Then make whatever other changes you might like, of course (maybe you want more tags, or fewer tags, or don't like the summary's current wording; whatever), and as usual scroll to the bottom and hit “Post”.  The newly created series-info will now appear in the data block above the title:

 

 

Editing the Series' Description  ^{Contents ↑}

1)  Just click on the name of the series (whether from within one of the stories in the series, or from the “Series” link in your sidebar [between “Drafts” and “Bookmarks”]) to get your series' page.

 

2)  Then on the page that this brings you to, click the “Edit Series” button.

 

3)  Finally, scroll down to the “Series Description” edit field and write whatever you're gonna write to describe your series as a whole.  Note that some HTML ? is allowed.

 

 

 

Weave multiple series together  ^{Contents ↑}

“But wait, how do I add it to multiple series at once?  ” you ask?
  Easy: same as before.
  Click “Edit”, scroll down, and either hit the drop-down to add it to another series as well or add another new series name (whichever applies) — and if you typo or change your mind later, you can always remove it from any series later (and if you accidentally remove something from a series, you can always re-add it right back in again):

 

Got a story in two or more series at once?  No problem!  They'll show up in the data block, though I'm not thrilled with the results' layout.  Worried that people might use skins to block the data block from appearing (or be new and not know that the data block might have useful data, or just brain fart)?  Then go ahead and mention the multiple series explicitly in the summary and/or header note (and maybe the footer note, too), and LINK them, since many people can't really copy-and-paste “<b><i><a href="https://archiveofourown.info/works/88888888">That next/previous story's title</a></i></b> &thinsp;” easily for a search.

Why would I add a thinspace (or two after taller or more rightward-serifed characters)?  Only because the curly quotation marks that I prefer look a bit cramped against italic letters when on AO3.  Don't believe me?  Here are some examples: “Words” “Words ” “Words  ”.  NB:  Everything has its pros and cons, and thinsp is no exception; it can make things look pretty in HTML, but will appear as a normal width of blank space in a downloaded .pdf of your fic, and your readers might scratch their heads and wonder why you add such bizarre extra spaces sometimes (ask me how I know...), and those examples just now will look to them [offline in a .pdf] as if I had written “Words” “Words ” “Words  ”.

In the examples below, I didn't italicize the way that I did in the paragraph above, but italics-with-thinsp would work just fine if added — stay focused on the issue at hand, the question of dropping a linked mention in a Summary or head-Note (and I've had it confirmed explicitly that doing so helped at least one reader click to a prequel rather than diving right into the main fic):

 

“But... people might click the wrong next-story-in-series...” you say?
  Yeah, they probably will sometimes, so include a note explaining which series is which, and where the bifurcation occurred, and include clickable-links for everything:

 

 

Rearranging a series  ^{Contents ↑}

“That's great, but one last question: I didn't make any mistakes, but still wanna rearrange the sequence of which story goes where in the series, so...”
  Yeah, no problem.  Been there, done that, too.
  Go to any of the stories in the series and click the title of whichever series you want to rearrange (or look at the left-hand side-bar any time that you're not actually in a story, and look between works, drafts, series, bookmarks, collections).  That'll bring you to the page for that series, and you can edit the series' summary, delete it, etc. — clearly you want the “Reorder Series” button:

 

Here you just grab-n-drag things up and down as you wish (and  I think that  you can simply enter sequence numbers into the boxes,  but I haven't really tried, so... give it a shot?  and when I finally tried it, it worked exactly as you'd expect: I typed “1” into the newly made item that I wanted to become the first in the series, preceding those that already existed, clicked “Update Positions”... and poof, it was now the first and everything else was budged up one index), and you should be all G2G (assuming that you remember to hit “Update Positions”, obviously):

 

 

Finding out how many bookmarks your series has/have  ^{Contents ↑}

You've doubtless noticed that your Statistics page doesn't list how many bookmarks any of your series have (or who's bookmarked them publicly, or what the public bookmarks' notes say, or if any of them are REC bookmarks).  I feel your pain, but luckily there's a solution.  Rather than rehash it here, I'll point you to where I wrote up the whole [easy] process (in the next tutorial) — and please note that the credit for it goes to destinationtoast! 🙂

 

---

 

This space left intentionally blank.

 

---

 

BONUS ROUND: space sizes & formatting  ^{Contents ↑}

  [↓  Several ways to indent]
  ↓  Special symbols re. screen readers
  ↓  TTS screen readers (various experiences and comparisons)
  ↓  Blockquote (no longer glitching with extra row)
    (includes CSS to remove sidebar)
  ↓  Blank spaces of different lengths (copyable examples and their HTML, plus CSS to stretch symbols)
  ↓  Fix the summary and note sections' glitch (extra rows after HTML)

 

Indents (CSS, center, emspace, dd)

This doesn't help with making series (and thematically would seem more fitting to the previous work on fonts), but it is a direct tangent from the mention of   earlier.  If spaces' widths are sometimes too wide or too narrow for your needs, then please see below.  If a snippet of poetry or verse feels like it needs a specific visual flow in order to convey the metre (those moments when something is said or sung just a few hairs earlier or later in the beat than the previous line had been), not just WYSIWYG, then do read on indeed.
  NB:  I should have noted this long ago, but bear in mind that indented paragraphs are greatly discouraged online (not sure of why, but some people are fine with them in a book, but not on a screen).  This goes so far as even for something like a snippet of poetry or song (when sharing this tutorial, one person in the Facebook group even begged [literally: she said “...beg you...”] that I not do so even for these).  I do use indenting for my song snippets and poetry (and <br /> &emsp; in my tutorials and sometimes my notes), but it probably has some overall adverse effect on my readership, so you might not want to do this.  Ditto for my double-spacing between sentences using &nbsp; and a regular space (it's a somewhat deprecated thing even in hardcopy print, and on a tiny 'phone screen, it makes for larger gaps to the eye than expected, especially when in combination with justified text [straight edges on both left and right side, which some people reading on 'phones find difficult to read; I've been told that this stems from their eyes having trouble tracking where the next row of text begins] using <div align="justify">, which combination then results in streams of whitespace at times).

I drop lyrics into my fics sometimes.  I'm a persnickety bugger, and my OCD isn't thrilled with leaving lyrics centered, and it's not thrilled with thought of adjusting them (an exercise in futility: everyone uses different screens, so adjustments would look totally screwed in various ways to different people), but there aren't a lot of options there (barring a .jpg or something, I suppose).

I wondered if a simple indent [using a CSS rule in a work skin] might be better than the obvious HTML of <p align="center"> for lyrics (note that in the case below, one could as easily opt for width: 0.2em; or something, instead):

#workskin .indent8per {
  padding-left: 8%;
}

If so, then I'd still need to arrange for them to look OK without CSS.  Maybe there's a way to stick the raw HTML around the text, and then have differently formatted CSS override it (or CSS around text, and default to differently formatted HTML if CSS is removed)?

 

Below is the centered method, as a baseline for comparison and contrast (though results will vary between browsers and by aspect ratios, so... grain of salt, guys, grain of salt) — and note that while I chose <p>, one could as easily (and arguably more flexibly, to sandwich multiple paragraphs) choose <div> instead:

<p align="center">
“...'cause I am the man who will fight for your honor,
I'll be the hero that you're dreamin' of,
gonna live forever,
knowin' together,
that we did it all for the glory of love...”
</p>

 

...and an emspaced idea (I've taken the liberty of highlighting the spaces before each row of lyrics, so that [if your browser and settings render the CSS properly] you can see that they've been pushed to the right with non-collapsing blank spaces [if you're reading a download, then the CSS won't be there to highlight them unless you re-insert the rules into your offline copy, but you can still highlight them yourself to see their sizes] —   and   specifically in this case, though I usually just use   and a regular spacebar-space, which works just as well); note that this doesn't guarantee n-many pixels' indentation, since the breadth of an emsp will vary (e.g.: full-justification vs. left-aligned):

  “...'cause I am the man who will fight for your honor,
  I'll be the hero that you're dreamin' of,
    gonna live forever,
  I'll be the hero that you're dreamin' of,
    knowin' together,
  that we did it all for the glory of love...”

 

and the 8 percent padding that I wrote out at the start of this section (not significantly different on a 'phone ratio, clearly inset farther to the right on a computer ratio — but problematically disappears in downloaded HTML or .pdf [since it's pure CSS], unlike the   and <dd> which remain functional in those [since these two methods rely purely upon HTML]), plus some non-collapsing blank spaces to afford some spacing in order to imply the metre visually (I just stick with   and   and a regular space, but there are others listed at the end of this section):

<p class="indent8per">
“...'cause I am the man who will fight for your honor,
 I'll be the hero that you're dreamin' of,
   gonna live forever,
   knowin' together,
 that we did it all for the glory of love...”
</p>

 

Hmm... how about <dd>description lists</dd> (halfway between the emspace indentation and the 8% indentation) to keep them slightly offset and nicely aligned, with non-collapsing spaces to inset short rows (plus those non-collapsing blank spaces of   and  , and some regular spaces)?  It's absolutely not good practice, since lists are meant [semantically] to list things, but it's quick and easy inline HTML right there on the spot (so: no need to go modify your work skin), and won't disappear in downloads (unlike work skins, which do get stripped upon download [aside from some few quirky bits of CSS that sometimes survive])...

<dd>
“...'cause I am the man who will fight for your honor,
 I'll be the hero that you're dreamin' of,
   gonna live forever,
   knowin' together,
 that we did it all for the glory of love...”
</dd>

It's been 4 years since I wrote all of that (I say this 23 May 2025), and I still stick with <dd&> for insetting lyrics without the blockquote v-bar, since the HTML won't go away at the flick of turning off Creator's Style, but for those who might be more inclined toward CSS, you might also like a more responsive rule than a simple indent... however, as I write this, padding: min(5em, 8%) isn't supported on AO3 in order to give a responsive sizing w.r.t. whichever value is smaller per a given device's browser size (and to complicate matters: I'm not sure if padding-left: min(5em, 8%), which is what I would need here, is even a thing).  I mention it as something to keep an eye on in case it does become available here (or for those of you who might need it elsewhere).
  Sidenote: the spacings above, BTW, are just &nbsp; in the second row to account for the quotation mark, &emsp;&nbsp;[spacebar] to give a five-space indentation for the third and fourth rows (plus a spacebar tap for the quotation mark), and another &nbsp; in the fifth row, if you're curious.

Top of Bonus Round section  ↑

 

Screen reader problems with symbols and lists

Anyone happen to notice a little hiccup just now reading the preceding set of lyrics?  If you're reading this visually, then... no; if you're using a screenreader, then some probably had no problem (presumably payware), but some surely completely skipped the lyrics this time.  After proofreading for myself and pasting from my offline document to AO3 (and formatting as needed), I use a freeware screenreader as another layer of proofreading (though, being a freeby, it unsurprisingly fails miserably at reading a lot of mathematical symbols such as ℵ [aleph] and ℶ [beth], or ∅ [null]), so that my ears can catch mistakes and awkward turns of phrase (it helps more than I care to admit, trust me: I really do recommend taking 5 or 10 minutes to grab one and set it up! ❤️).  When I set it to read the whole page, it skipped the lyrics; when I selected only the actual chapter material from top to bottom, it read them.  I use only <dd> and </dd>, so when I caught my screenreader skipping these, I thought that perhaps I had to nest them within <dl> and </dl>, or <dt> and </dt>, and possibly both — but no dice:

1. <dl><dd>...</dd></dl> didn't change anything (still skipped in the full-page read, still read aloud in the selected-material);
2. <dt><dd>...</dd></dt> got screwed by the parser turning it into <dt></dt><dd>...</dd> (and no change with the reading or lack thereof);
3. <dt><dl><dd>...</dd></dl></dt> got screwed similarly, being turned into <dt></dt><dl><dd>...</dd></dl> (and again: still skipping or not, depending as before).
4. naturally, I tried <dl>...</dl> alone and <dt>...</dt> alone, but got the results that one might expect: the former was no longer inset, and the latter compounded that by making it a bold font as well, both of these presenting the same read-or-not issues as the others (care to guess the final disposition of the last HTML-permissible permutation: <dt><dl>...</dl></dt>?);

So... yeah: arguably a better visual result without resorting to CSS (which would be lost in download), but clearly not a good choice for at least one freeware screenreader.  It gets even better: I just discovered (after how long using it?!?) that my freeby screenreader doesn't read ordered or unordered lists, nor headers!  (To be fair, I usually don't use any of these, but it's still a point for the writer to keep in mind [perhaps writing-in some redundant exposition into the next paragraph for people whose screenreaders suck], and likewise for the listener to keep in mind [next time an author seems to flub something, it might have been your screenreader rather than the author].)
  Of course, if you're reading this with a screenreader that has the same problems as my freeware one has, then you didn't even hear half of that list, since mine ignores anything that's visually between greater-than and less-than arrows as with this example: <my screen reader can't see these words, even though the symbols are only HTML entities, not active HTML> — go ahead and highlight that section (including the symbols) and see if yours does or not.
  I don't know if braille readers have the same issues.
  Then again, the same sort of issue also comes up [after a fashion] with <i>italics</i> vs. <em>emphatics</em>: in principle, italics might be spoken with a slight shift of tone (to convey innuendo, nuance, jocularity, or just to stress a point slightly), but aren't necessarily intended to be (as when italicizing a ship's name, for example), whereas emphatics are a semantically different thing in HTML for screen readers to indeed pronounce differently; by default though, it seems that most don't (those that even have such a setting [which mine doesn't, so clearly not all do] apparently are set not to do this by default, and many people don't twiddle around with settings in-depth).  The same seems to apply to <b>bold</b> vs. <strong>strong</strong> in the lack of distinction in firmness of screen reader voice that one might expect in the hard tone of someone speaking and trying to stress a point distinctly.  The same again comes up with entering mathematical and logical symbols — your screen font will probably show them, but just as the average reader might not be familiar with certain symbols (e.g.: aleph null, or intersection), my screen reader usually fails with these (higher-end screen readers might not).  Given all of these issues, I guess that the other issues shouldn't be surprising, but the takeaway point is that while you can't fix everything, and might cause one problem in solving another, you might still want to test your results and see if you can find a fallback when possible.
  Belated side-note: I forgot to add that at least my screen reader also fails to read at least some Unicode glyphs (which a friend of mine uses from her 'phone's font options in her fics), as in the case of my own “𝑫𝒐𝒏'𝒕 𝒇𝒐𝒓𝒈𝒆𝒕 𝒕𝒐 𝑳𝒊𝒌𝒆, 𝑺𝒉𝒂𝒓𝒆, 𝒂𝒏𝒅 𝑺𝒖𝒃𝒔𝒄𝒓𝒊𝒃𝒆” catchphrase in the summary.

Addendum, 06 Nov 2023:  ...and just now I'm fiddling with a ConLang tutorial (for Mar/ Apr 2024), when what to my wondering ears should appear?  I find that my screen reader is skipping any material after <br /> break tags (but only certain ones: those that follow a period “.”, it seems, but not those on the heels of a close bracket “]”, for example?!?), such as when I introduce a new paragraph beneath another one rather than giving a full row of empty space to create a gap between them with wholly separating <p> paragraph tags, for example (I do this only in my tutorials and some notes, not in my fics' main bodies, because I feel that the break gives certain thoughts a visual closeness attaching them to the preceding paragraph in a way that gap after gap loses, but bow to the hivemind popular “wisdom” of gapping paragraphs in fics simply because so many people seem to “need” this when reading on their 'phones — though they won't take away my justified block margins 'til they pry them from my cold, dead hands).  When this began, I don't know, but it certainly hadn't been this way the whole time, since I always test out newly written AO3 uploads; I've spent this year collecting data for an AO3 traffic analysis (a multivariate one re. AO3 traffic in general, to be released Mar 2024, and following the next tutorial in this series, which looks at only working out one's own fics' traffic), so haven't been uploading weekly as I had been in 2022 and earlier, but I did happen to let the bug bite me and released that How to AO3 piece on 24 Sep, which I surely TTS-tested, so this must be some new development.  Word to the wise: don't assume that just because your software works well (or even simply hobbles along barely well enough...), they won't fix it 'til it's broken.

Top of Bonus Round section  ↑

 

Experiences (mine and others') with and comparisons of TTS screen readers

UPDATE on description lists:  I noticed something funny in one of my fics around Dec 2022, but thought that it had been my own typo; now in Jan 2023, I've noticed it some more in other fics and chapters, and I'm pretty sure that it's universally the case.  This problem doesn't occur in chapters from 26 Jun or earlier (the only exceptions seem to be earlier uploads that had been edited later), but chapters edited at some point after 10 Jul show it (those that were uploaded as late as 11 Dec had been OK at the time, but minor edits since then seem to have triggered it).  Since then, where a given song snippet had a blank row between two stanzas using only the break tag <br />, that blank row no longer shows (the break tag isn't there if you inspect the element, though the page source code still contains the break tag).
  Simply adding a non-breaking space   before the break tag <br /> solves this issue (a minor pain of time to fix manually for every case, but it works).

Top of Bonus Round section  ↑

 

Blockquotes for indentation and profit!

Though yes, there's always the <blockquote> / </blockquote> option (which sets the lyrics ever so slightly less inset to the right [that is, it's a tiny bit closer to the left]), plus the non-collapsing blank spaces of   and  , and regular spaces — five times as many characters (10 letters in “blockquote” vs. 2 in “dd”),  sometimes awkward to adjust,  leaves a big old vertical bar to the side of the stanza (which might be good or bad, depending upon your needs and taste),  and is generally more of a fiddly pain in the ass to adjust properly than <dd>,  but it's an option (and I have to admit that an HTML purist would be right in pointing out that that's kinda the purpose of a blockquote, after all; semantically very different from a description list), and one that does stay functional upon download (just like <dd>):

<blockquote>
“...'cause I am the man who will fight for your honor,
 I'll be the hero that you're dreamin' of,
   gonna live forever,
   knowin' together,
 that we did it all for the glory of love...”
</blockquote>

Blockquotes are certainly an easy approach, and have that clean vertical bar to add the visual alert (which might make these easier for a 'phone reader to distinguish, given the narrow real estate), but I also called them “awkward” and “fiddly”.  Here's what I mean.  When I wrote the above blockquote, I had simply finished the paragraph about them and didn't hit ENTER [twice] in order start the blockquote as its own paragraph, instead continuing (without even hitting the spacebar) directly from the period to the opening of the blockquote, like this.<blockquote>  That looks ugly here, but it disappears when executed as HTML (as you can see in the previous example, or any other blockquote).  I did that because if I hadn't, and had instead hit ENTER [twice] in order start the blockquote as its own paragraph (as one might expect to do just as with any other paragraph), then the resulting blockquote would have had an unsightly extra-tall space at the start (in addition to the one blank row that normally starts [and ends] blockquotes automatically), like this:

<blockquote>
“...'cause I am the man who will fight for your honor,
 I'll be the hero that you're dreamin' of,
   gonna live forever,
   knowin' together,
 that we did it all for the glory of love...”
</blockquote>

UPDATE:  Per AO3 News's Releases 0.9.327 - 0.9.335: Change Log (27 Jan 2023), item [AO3-3710], “Extra blank paragraphs are no longer added before blockquote tags when editing works.” — and they fixed it: I didn't have to do anything funny to make this blockquote come out right!

NB:  If you're trying to get any or all of the above indents to work on both your computer and your 'phone, but only your computer displays them the way that it should, and you don't want the sidebar that the blockquote creates, then I might have a solution for you....  I made a work skin rule for the Matrix Green Rain concept-demo-tutorial in order to give it a declaration of border-left: 8px solid #ffff0099; so that it would stand out better, though I ended up not using it, and a similar one for making a more clear separation between blockquotes in a string of blockquotes by a bottom declaration to give them a look like the bottom-left corner of a page of paper, and when someone ran into the problem of their computer's browser indenting well but not their 'phone's browser, it finally dawned on me to try modifying the blockquote so that it wouldn't show the sidebar:

#workskin .quote-zero {
  border-left: 0px;
}

which you use thus, exactly as with any other blockquote, just applying that CSS selector as a class to the blockquote element (and keeping in mind that CSS is generally lost in downloads and requires reinsertion):

<blockquote class="quote-zero">

<p>A quoted paragraph.</p>

<p>A second quoted paragraph.</p>

<p>A third quoted paragraph.</p>

</blockquote>

and that did work for them, so it should for you, too.

Of course, you could apply it across the board to all of your blockquotes from within your work skin:

#workskin blockquote {
  border-left: 0px;
}

it's just that this would affect all of the blockquotes in every work that this work skin were applied to, hence so-sweeping an approach should be used judiciously.

 

NB:  If you've no idea how to work with HTML at all, then Don't Panic!

• First thing you'll want right this second is to know that you can break these lyrics into individual rows (without turning them into separate paragraphs) by simply adding <br /> at the end of each row.
• Second thing you'll want is to search through AO3 for some HTML tutorials / primers / guides, whatever you might call them — there are plenty of them, and you might love the first one that you find, or hate that one and love the second.
• If you're already familiar with HTML (or have now become familiar with it, and just came back from those tutorials), and wish to use that work skin thing for padding or writing things in color or highlighting them or circling them or what have you, then this is the time to go take a look at the previous work in this series, the aforementioned one on fonts, Fonts, and colors, and work skins, oh my! (a bit of an obvious title, I know, but at least one needn't wonder at the contents).

Top of Bonus Round section  ↑

 

Shooting blanks and stretching things out

So far, I'm leaning toward the description list approach, but still not actually 100% sold on it.  Bottom line though: those are some options that you can play with for lyrics (not the point here at all), and here's what the different spaces (the whole point of this  ADHD rabbit hole  helpful bonus section  ) and description list HTML look like:

NB: on 14 May 2025, I dug a little deeper for reasons and added a few that weren't on the list before, highlighted in yellow (I didn't then go OTT and update the lists below this).
 
|| no space
| | &hairsp;
  UPDATE 29 Apr 2023: it appears that although copy-and-paste of the space itself | | remains functional, the HTML of &hairsp; |&hairsp;| is no longer working on AO3 (maybe this is just a weird temp glitch?)
| | &thinsp;
  |&thinsp;⁠&thinsp;⁠ ⁠| NB: for simple use between an italic and a close quotation mark, no problem, but there are times (as with highlighting) when the &thinsp; will line break at the word wrap; for this, use the span between the two example &thinsp;s here — it's a copy-able &NoBreak; (because writing that HTML tag won't parse on AO3: it's treated instead as plaintext) that you paste between your highlighting and the &thinsp; and your words (or the other way around, at the end of your highlighting, or whatever you need this for),  ⁠forcing the &thinsp; to jump rows along with the beginning and ending words⁠ , instead of being an orphaned highlighted &thinsp; on the row above or below (adjust your browser ratio her, to see for yourself with that preceding yellow-highlight's leading and trailing &thinsp;s).
  If you need a functional &NoBreak; all by itself, just copy that little section (above) between the first ";" and the second "&" (they're boldfaced in the above copyable section [and the rest of it left un-bold] in order to make it more clear which ones I mean, specifically) and paste it wherever your breaks are occurring without your permission (or copy from the ";" through the "&", so that you're certain that you got the &NoBreak;, paste where needed, and delete the symbols, being very careful to arrow past the &NoBreak;, rather than accidentally deleting it along with the two symbols).  It works well for such instances as “-⁠ing” (adjust your browser width and you'll see that this stays connected properly), where one might reasonably need to keep things unbroken and on the same line of text, as opposed to the same example without the copypasta &nobreak, as with this second case “-ing” (adjust your browser and you'll see that this one will break when the hyphen is at the end of the line, leaving the ing portion a floating orphan).
| | &#8198; SIX-PER-EM SPACE (narrow no-break)
| | &#8197; FOUR-PER-EM SPACE
| | &nbsp; (&#8196; three-per-em space and &#8200; &puncsp; punctuation space also look the same to me)
| | &ensp; (&#8192; en quad looks the same to me)
| | &#8199; FIGURE SPACE
| | &emsp; (&#8193; em quad and &#12288; ideographic space also look the same to me)

Incidentally, the pixel lengths that these spaces give you might not be quite right for your needs.  There's a workaround for this, though you'll need to add a work skin rule. 
  CAUTION:  See next couple of paragraphs re. loss of functionality. 
  I guess that it's a good thing that I hadn't bothered testing {ultra-condensed, extra-condensed, condensed, semi-condensed, [normal], semi-expanded, expanded, extra-expanded, or ultra-expanded} or simply their percentage values, though maybe it's only a question of needing to do it differently now (or you might still find these to be of use other than on AO3).

#workskin .stretch {
  font-stretch: expanded;
}

You would then add a CSS selector stretch around the space that you want to stretch in the same way as for any other CSS selector: <span class="stretch"></span>. As for details on how much of an effect this had for me with each space size that I tested (and a side-note re. lengths of different dashes, below, along with the details of the zoom conditions that I used, since they're not just a standard 100%, but this is about the relative scale from one to another, and specifics will vary with font and font size, etc.), per my reply to Rockinlibrarian's comment thread (or just show the comments below and scroll down to the sixth thread) — it's worth looking into because [under the conditions in which I tested them, anyway] some grew to about halfway between their normal length and the next space's (or dash's) length, some shrank to about halfway between their normal and the smaller size's length (i.e.: instead of becoming half a size larger, they became half a size smaller), and some remained unchanged, but here's their breakdown at a glance, just to tidy things all into a QRL (future-proofing it in case this tutorial ever goes away, since Wayback saves only the work and not the comments):

In my own testing, I found that work skin rule above to have the following effects... most of which seem now (01 Jun 2024, a few years after my original testing) to no longer stretch:
  || 22 (0) no space (cf. zero width spaces and non-breaking in principle)
  || ← that's a pasted ZeroWidthSpace; but it won't copy
  || ← and that actually is a &ZeroWidthSpace; (and CAN be copied), but [unsurprisingly] neither of these will stretch
  | | a 26 pixel &hairsp; stretched with |<span class="stretch"> </span>| became 28 pixels long
    | | 26 pixels of &hairsp; as-is
    | | 28 pixels of hairsp, after stretching (which apparently is no longer true)
  | | a 31 pixel &thinsp; becomes 36 pixels long
    | | 31 pixels of &thinsp;
    | | 36 pixels of thinsp, after stretching (which apparently is no longer true)
  | | I didn't note the change (if any) on stretching the &#8239; (narrow nbsp)
    | | &#8239; (narrow nbsp) untouched
    | | &#8239; (narrow nbsp), after stretching (though it now [01 Jun 2024] does show a change... having shrunken some)
    | | &#8239; (narrow nbsp), &#8239; test of 200% (26 May 2025) still a fail
  | | a 44 pixel normal spacebar space shrank to 41
    | | 41 pixel spacebar space, after stretching (which apparently is no longer true)
    | | 44 pixel spacebar space, untouched
  | | ref. &nbsp; (which by HTML should be the same size as the above untouched regular spacebar space)
  | | 44 &#09; ASCII "tab" <pre> would make it 175, but it makes its own paragraph then
  | | I didn't note the change (if any) on stretching the 57 pixel &ensp;
  | | a 66 pixel #8199 space shrank to 61
    | | 61 pixels of #8199, after stretching (which apparently is no longer true)
    | | 66 pixels of #8199, untouched
  | | I didn't note the change (if any) upon stretching the 91 &emsp;.

As a side-note, I had also tested various dashes (300% zoom-in on the online screen on my computer, screenshot it, pasted into MS Paint, 800% zoom on the original and stretched versions together in Paint, and determined the pixel lengths of each at that point) with similarly mixed results:
  |‐| ~14 Hyphen
    |‐| ~14 pixel hyphen (in terms of the whitespace between the pipes), untouched
    |‐| that same ~17 pixel resulting hyphen, after stretching (which apparently is no longer true)
    (i.e.: |<span class="stretch">‐</span>|)
  |–| ~27 everyday &ndash; HTML entity
    |–| the ~27 pixel ndash, untouched
    |–| the ~38 pixel resulting ndash, after stretching (which apparently is no longer true)
  |-| ~30 .odt's (basically .doc's) ndash without stretch
    |-| ~19 pixel resulting .odt/.doc ndash, after stretching (which apparently is no longer true)
    |-| ~30 pixel .odt/.doc ndash, untouched
  |𑁒| ~33 pixel Brahmi /one/ was unchanged
  |−| ~39 pixel minus sign (which is a separate entity from a hyphen) shrank to 33 pixels long
    |−| ~33 pixel resulting minus sign, after stretching (which apparently is no longer true)
    |−| ~39 pixel minus sign, untouched
  |ー| ~51 pixel chōonpu was unchanged
  |—| ~63 pixel &mdash; grew to ~69 pixels long
    |—| ~63 pixel mdash, untouched
    |—| ~69 pixel resulting mdash, after stretching (which apparently is no longer true)
  ||| ~65 pixel 90° clockwise rotated (if you've left ^{_{Creator's Style with default Site Skin}} on, anyway [the rule for this is display: inline-block; transform: rotate(90deg);, BTW — and man: you should see what it does to <hr class="rotcw90" />! 🤣]) vertical pipe “|” as-is, seemingly 1px shorter than Chinese /one/ (below)
      NB 23 May 2025:  In plunking that pipe into this dash subsection, I need to clarify that I'm on a different tower, and in Win 11 instead of 10, etc., nowadays, but zooming 300x still in Chrome [4-year-later build] on the same monitor w/o site skin, pasting to maybe-the-same-build MS Paint w/ 800x zoom, Paint claims that it's 37 px, while visually it's clearly 1px longer than the “63px” &mdash; yet paradoxically 1px shorter than the “67px” Chinese /one/... so going by the old numbers established in this tutorial 4 years ago under very different electronic conditions: that means that it must be what would have been “65px” under the old pertaining conditions (exact px count is irrelevant: these are all for relative sizing purposes, and will vary with different fonts, etc.).
    |F| rotated capital “F”, for comparison
    | | | 90° clockwise rotated vertical pipe “|” bracketed by spacebars to each side (illustrating the imbalance of space above and below the pipe when vertical [same as with the above example of the “F”, though I didn't add spacebar spaces with that one], or here the imbalance of the respective right and left side spaces; in fact: if you select the term “90°” and shift-left-arrow ◄ for a few characters, you'll even find that the left space is stabbed halfway through by the left-end [what had been the non-rotated bottom] of the pipe, and that by doing the same thing by selecting from the right and highlighting one character per shift-right-arrow, the RHS space is fully transected by the pipe's right [previously top] end), for clear viewing

#workskin .rotcw90 {
    display: inline-block;
    /* If these were an image and a background color, then you'd need the image declaration above the color declaration */
    /* bg color RGB fallback, however, should come BEFORE one's preferred target RGBA */
    /* In the case of more and less advanced CSS techniques, you need the older simpler stuff above the later more advanced stuff */
    /* If you have equal specificity weights, the lower-down declaration tends to beat the upper, ditto for lower-down rules, but it's a lot more nuanced than this REM comment can address */
    -webkit-transform: rotate(90deg);
    -moz-transform: rotate(90deg);
    -ms-transform: rotate(90deg);
    -o-transform: rotate(90deg);
    transform: rotate(90deg);
}

  |一| ~67 pixel Chinese /one/ was unchanged
  |𑁋| ~70 pixel Brahmi punctuation line was unchanged
  |⸺| ~140 pixel two-em dash was unchanged
  |⸻| ~210 pixel three-em dash [plain, here]
  |⸻| was unchanged (stretch applied, this time)...
  BUT you can do things to change the lengths in any event, though you might not love the exact results past a certain point:
  |⸻| ...and the result of applying [to a three-em dash] a declaration of font-size: 150%;
  |⸻| the result of applying [to a three-em dash] a declaration of font-size: 2rem;...
  |⸻| ...and font-size: 300%;...
  |⸻| ...and even font-size: 50px;.

Belatedly, it occurs to me that one might wish for different lengths of low lines, like an underscore, just not using <u> on an &nbsp; to get there with “ ” (or some other length of blank space, as detailed above — though those would be decent visual alternatives to the paltry few shown below), but instead more like using the SHIFT-hyphen in order to obtain “_”.  I haven't deep-dived on these, but you have a few options for shorter ones (longer ones seem to be a little elusive); as rendered in a WIN 11 environment on Chrome within AO3 (and probably other caveat conditions), what I got for them is as follows (your system, fonts, browsers, device hardware and firmware, etc. will likely render different results):

• |ˍ| &#717; or &#x2CD;, the Modifier Letter Low Macron (U+02CD) — 4px long with 5px space to each side, and hovering 3px below your text's baseline bottommost pixels;
• |𛲖| &#113814; or &#x1BC96;, the Duployan Affix Low Line (U+1BC96) — 5px long with 3px space to each side, and hovering inline with your text's baseline bottommost pixels (as well as introducing a taller span to your text [raising the line-height ceiling and lowering the height floor], while in AO3's HTML editing field);
• |_| &#95; or &#x5F; or &UnderBar; (i.e.: SHIFT-hyphen on your typical QWERTY keyboard), the common everyday household Low Line (U+005F) — 6px long with 3px space to each side, and hovering 1px below your text's baseline bottommost pixels;
• |＿| &#65343; or &#xFF3F;, the Fullwidth Low Line (U+FF3F) — 6px long with 7px space to each side, and hovering 2px below your text's baseline bottommost pixels;
• and |ߺ| (which is a joiner of sorts, and behaves a little... oddly...) &#2042; or &#x7FA;, Nko Lajanyalan (U+07FA) — 7px long with 2px space to each side, and hovering inline with your text's baseline bottommost pixels.

Top of Bonus Round section  ↑

 

 

Summaries' and notes' extra row HTML glitch and how to fix that

UPDATE 24 Mar 2023 re.   glitch:  I discovered something odd last night.  When trying to inset something in a Summary (where I don't use paragraph <p> HTML tags), the   kept disappearing.  I hadn't noticed this before because the couple of instances where I had used them there, I had already needed breaks instead of carriage returns, whereas I did need an empty row this time.
  Testing for variables, the same happened with  , and it wasn't from having used some bold <b> HTML tags (which have odd effects in summaries and notes: if you end a line of text with the closing tag, and later update that page, then they will automatically insert an extra blank row above and below that line every time that you update the regular body text, until you discover that you've magically hit the character limit even though you never touched the summary or note in your updates — the preventive measure to this, BTW, is to simply not end the line with a closing tag, so add an emoji or punctuation mark or something and you're G2G).
  Turned out that to force AO3's parser not to scrub the   from the start of the line, I had to not hit-Enter-and-call-it-a-day, but instead must use the break <br /> tag at the end of the previous line of text (and a second one if I wanted an empty row, as you might expect by now).

With no break <br /> tag anywhere at the end of this line nor at the start of the next nor as its own line between the two (just hitting Enter to get to the next line),
that   would be scrubbed and this second line of text in a Summary would be along the left edge.

With only one break <br /> tag (regardless of placing it at the end of this line, or as its own line, or at the start of the next line),<br />
  that   will remain, but the two lines of text will abut without an empty row between them (because the browser sees only one break tag, which reads the same to the browser whether at the end of a row or beneath it).

Only by adding two break <br /> tags (I like one at the end of this line and another one as the next line, for cleaner code, but you can put them both at the end of this line / as the middle line [or two separate middle lines] / at the start of the next line, or one tag at any one of these three points and the other tag at either one of the other two points: the browser won't care where they are)<br /><br />

  will the   remain in place and have a visually-empty row above it (though sometimes this refuses to work without a non-breaking space   between those two line breaks).

  When using everyday paragraphs with <p> HTML tags, the issue is masked (as you can see in the case of this paragraph): the   will remain at the start of paragraphs.  The same is true in the Summary... if you choose to use paragraphs there; if not, as I hadn't, then you encounter the issue.

 

UPDATE 03 Apr 2023 re. bold/italic sudden-new-empty-row glitch:  Reader TheWanderingKat made an excellent observation re. italic <i> HTML tags causing an extra blank row to appear at times.  I'd had a similar sounding issue with Summaries and Notes lines' bold <b> HTML tags causing an extra blank row to come into existence both above and below the line in question for no apparent reason.  This didn't happen within the main text of my fics (where everything is encased by paragraph <p> tags), just in the Summaries and Notes, but here's a visual:

<i>If you were to write this sentence — note the italic tags (which could as easily be bold; I won't bother checking underscore or others, but I've seen span do it too) outside of the punctuation, but still appearing OK for now — and then later edit your chapter or fic,</i>

 
<i>then that sentence would now have a blank row above it and below, as this one does now.</i>
 

To prevent (or fix) this problem, the solution is simply to not boldface nor italicize the very last glyph (presumably a period, exclamation point, or question mark) at the end of your sentence / paragraph (or to add one of the non-breaking spaces, e.g.  , afterward, if one intends to follow it with a line break <br />).  Hell, even adding a normal space and an emoji bypasses this issue.  Go figure.

<i>Instead, just place your HTML close-tag within the sentence, as I've done with this example, and no weird blank rows will insert themselves every time that you edit</i>;

<i>unless you plan to use the non-breaking-space-and-line-break method, of course, as shown here,</i>&nbsp;<br />

<i>or toss in a space and an emoji after your punctuation, as in this example.</i> 🙂

Top of Bonus Round section  ↑

 

---

 

 

And that concludes today's session of Reading Rainbow, ladies and germs! 🙂
  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.

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.)