• Welcome to Thousand Roads! You're welcome to view discussions or read our stories without registering, but you'll need an account to join in our events, interact with other members, or post one of your own fics. Why not become a member of our community? We'd love to have you!

    Join now!

FYC: More typographical effects in BBcode; render fixes

Venia Silente

For your ills, I prescribe a cat.
Hello everyone, here with a few requests.

Currently the page on BBcode codes (https://forums.thousandroads.net/index.php?help/bb-codes/) lists the codes that are supported. However, a few codes are not working correctly (in particular for the print preview or Save As... renders) and a few other codes of interest are not implemented.

Here is a quick rundown. Please consider this not a bug report on the *engine*; none of the codes implemented and listed here is actually working incorrectly, as far as I can tell it's the children renderers who are wrong.

Typographical: Superscript and Subscript

I tested it and they are not implemented. Those are [ sup] [/sup] (superscript text) and [ sub] [/sub] (subscript text). They are recognized and decent typographical effects for writing formulas and references, for marking notes and points of interest, etc. Ftr, most other bbcode parsers I've been around do implement them, and Markdown takes them as a fallback as well.

I had expected them to be available in lieu of missing <ruby> (yes I remember my other FYC, and I keep an eye on it), <cite> or <dl> support when I posted Dangerous Upgrade. Considering they are quite common compared to the other three alternatives. Alas, without any of these, it seems I've run out of semantic options.

Typographical / Documentation: Justified Text

That's the [ JUSTIFY] equivalent to [ CENTER] etc..., and parses to eg.:

Yes I know justified is cursed on the web. It only mostly really works on newspaper or dash-reel style print (which, btw, print mode does is a valid render in this site as far as I know). Its just happens to be awkward that it's actually available in the selector, but that is not actually reflected in the bbcode help docs.

To be fair, I've also not tested if it's supported in the non-screen render modes (see Render: Alignment options below).

Engine / Documentation: Relative Links

Currently if I want to link to a different thread or post in the forum one does use the [ URL] element, but most people are used to or would mostly know to give it a full ("canonical") URL:

Code:
[url="https://forums.thousandroads.net/index.php?threads/dangerous-upgrade-gti.1220/"]some fic[/url]

Problem with this is: it's not futureproof. if URL generation for Thousand Roads ever changes, all links are lost.

This can happen from a domain change (eg.: "tousandandoneroads.net"), or if the engine options for thread links are changed (eg.: what happened to Serebii when they changed the thread title pattern from "{ID}{TITLE}" to "{TITLE}{ID}" or the other way around, or wht happened to AwkwardZombie and PennyArcade when they split date year and month from links to comics).

It'd be helpful to count with one of two options, if not some other you can think of:

a) document in the BBcode page how to create better (almost futureproof) links to content in the same forum:

Code:
[url="/index.php?threads/dangerous-upgrade-gti.1220/"]some fic[/url]
(making the link relative to root should at least work so long as the engine options remain the same)

b) add an engine-level element that resolves a thread id or name to its actual name

Code:
[threadid=1220]some fic[/thread]
(potentially guaranteed to never parse to an *invalid* link, since the engine will resolve it by visiting its own configuration)

Render: Alignment options

Checked this in Firefox ESR and in Firefox Nightly, both in Reader Mode. Most formatting functions correctly, but [ left], [ center] and [ right] specifically don't. Curiously enough, they *do* seem to work in text render (eg.: via w3m, but haven't been able to find a RSS feed in the site to see if its the text parser who truly grabs it) and in browser's Print Preview, so I suppose it's some sort of @media selection issue.

It's quite curious because I can see that the corresponding HTML is generated:

Code:
<dl class="bbCodeDemoBlock-item">
            <dt>Output:</dt>
            <dd><div class="bbWrapper"><div style="text-align: left">Left-aligned&#8203;</div><div style="text-align: center">Center-aligned&#8203;</div><div style="text-align: right">Right-aligned&#8203;</div></div></dd>
        </dl>
But I'm suspecting there's a parsing error there somewhere, or a @media selection not accounted for, or that the style applied to the parent <dl> or their overarching <div> parent is intervening, since this alignment in reader mode *also* doesn't work in story chapters in Reader Mode.

(And no, it's not a bug in Firefox at least as far as I can tell. Reader Mode in Wikipedia, SDF, Ars Technica and my country's Customer Public Defender Services are all showing alignment correctly.)

Typographical: Definition Lists

Speaking of <dl> and its children above: I see it's used in documentation pages, but it's not made available to the BBcode engine. It'd be interesting to count with it for stuff like Authors Notes, informational boxes with rulesets and the like, etc, all the more considering this forum engine already went all through with the hassle that is enabling [ table] support.

Full support seems to only need three elements: [ dl], [ dt] and [ dd]. Of them, only at most [ dl] may ever see use case for an attribute, I think; the other two really go solo.

Documentation: Indent

Element [ INDENT=n] supports an argument "n" which is a number, but nowhere it is explicited what that indent value actually means. Is it two "spaces", two "tabs", two "ems", etc? While trial and error is nice and it's unlikely anyone will ever need high values (anything with two digits or more), it'd be nice to have it explained somewhere. This is unlike eg.: [ SIZE=n] in that at least size element attribute is generally understood / quasi-standard across BBcode parsers (though presumably documenting what values are allowed for SIZE= and documenting / linking to the "Minimum Font Size" option in browsers that can override it could also be useful).

I think that's it for now. If I can think of more things, I'll def post them in. Thanks in advance and happy coding to ye who dare!
 
Top Bottom