#TwineTuesday: Changing the CSS rules of a single passage link

[Okay, when I’m writing this, it’s not technically a Tuesday. And I did write I was taking a break from Twine Tuesday posts for awhile. Still, this is a solution to something I’ve seen a couple of different people struggling with just today.]

HTML prefers you do all of your loading upfront. Whatever stylesheets you are using, and those assets like images and scripts, should often be in the header of the HTML. This is the part read over, loaded, and ready in memory for the actual body of the page itself. All the rules and code to change the default layout to what you are asking the browser to create for you.

Since Twine inherits this idea, it too prefers that any style rules, defined within a “stylesheet” passage, be set before the first, “Start”, passage is shown. There are, of course, ways to get around this using JavaScript, just like in HTML itself, but it’s often easier to design with certain style choices in mind while editing the Twine content and then publish everything together.

However, when it comes to trying to target certain passage names, of trying to make maybe one or even two links different than normal within them, this becomes slightly complicated. If we want to change the style of just one link, and not all links in a project, how do we do that? Can we even do that?

The answer is yes, but it takes some extra effort. And you need to keep in mind a certain condition.

First, understand that when Twine creates a link within a passage during runtime, it might look like the following in HTML:

internalLink" id="passageName">A link to passageName

The link is using the “internalLink” class, meaning it is pointing at another passage in the project and should follow the internal link style rules, and its “id” is “passageName”. This is the passage this particular link is pointing at itself. When the text “A link to passageName” is clicked during runtime, Twine will load the passage named “passageName” next.

Because all links have this reference to what they pointing at as their “id”, we can target that with a CSS rule. Within a “stylesheet” passage, we can tell the browser to change all links with that certain “id” to a different set of CSS rules.

For example, if we wanted the link to the passage “frog” to always be green in color, we can define a rule for that.

#frog {
 color: green;
}

Notice that the hash goes in front of rules that apply to targets with a specific “id”. For classes, those sets of styles for multiple elements on a page, we would use a period first. And if we wanted to change the styles for preexisting elements, something like a body (for all content) or how a paragraph (p) looks, we can target those using their HTML tag name only.

It’s how we can change all the internal links to a certain color too. If we wanted all internal links, those that reference other passages within a project, we can override the class rule for that by defining our own. (The newest CSS rule always overwrites the old one.)

.internalLink {
  color: pink;
}

So, to target a specific link, we use a hash prefix and that passage’s name. For something that applies to multiple elements on a page, use a period prefix. To apply to all elements of a certain tag, use that element’s tag name — something like “body”, “p”, or “a”.

However, there is one more little condition to all this. To target something using CSS, we must follow its naming conventions. CSS doesn’t allow spaces in names, and it doesn’t like most punctuation either. The exact conventions, as set out by the W3C, can be found here. Generally, though, it’s enough to remember to always start a rule with a letter and to avoid spaces or other punctuation completely.

Remember too, that the passage name need not always show up as the text to click. Using a “|”, you can define some text that is in place of the passage’s name. Like in the following example:

[[The text to appear |Passage]]

(Note: There isn’t a space after the “|” and before the passage’s name when written like this.)