Different main/menu colors for separate passages

Twine Version: 2.10.0

Fooling around with twine and harlowe, I found a problem:

Basically, I’m very minimalist in my experimenting, and also in my pet projects, but I have successfully introduced a slighty lighter sidebar (with a tiny test text):

, but in looking on varied colour passage (e.g. passage of time, or different areas) sidebar don’t change, leading to an ugly colorset:

The relevant sources are:

the CSS:

tw-story {
/* as I personally like */
Background-color: navy;
color: yellow;
font-size: 20pt;
max-width 75ex;
margin: 0 auto;
}

tw-link {
  color: orange;
  font-weight: normal;
}    
tw-link:hover {
	color: lime;
}
.visited {
  color: purple;
}
.visited:hover {
  	color: magenta;
}


/* from mano & hal9k on intfic */

input[type=checkbox] {
	accent-color: red;
}

tw-dialog-links {
	flex-direction: column;
	gap: 0.5rem;
}

tw-dialog-links > tw-link {
	margin: 0 !important;
}

tw-sidebar {
  position: fixed;
  top: 0;
  left: 0;
  width: 15%; /* padding-right of the tw-story element. */
  max-height: 100%;
  margin-top: 5%; /* padding-top of the tw-story element. */
  padding: 0 0.5em 0.5em 0.5em;
  text-align: left;
  background-color: blue;
} 

the header passage setting the sidetext:

(append: ?SideBar)
[testo di test]

the “normal” passage(s), rather vanilla:

My customary inglenook

Back to the [[START]]

the “special” passage:

(enchant:?sidebar,(bg:#c53932))
(enchant:?page,(bg:#451912))
don't worry, politics don't matter in those special passages ;)

As is evident from the screenshotts, the enchant:?sidebar don’t work as expected; I tried diverse variation, without success. and after my “48 hrs. of attempts” rule, I remain at loss on why don’t work, so I ask our community, what is gone wrong there ?

TIA and
Best regards from Italy,
dott. Piergiorgio.

1 Like

Yeah… I’ve been testing and the code should be working without a problem… there may be a bug in Harlowe? (which should be reported here).

In the meantime you could do either:

<style>tw-sidebar {background:#c53932}</style>

In the passage you want with that colour OR, assign a tag for that passage and use it in the stylesheet:

[tags="the-tag-you-assigned-to-the-passage"] tw-sidebar {
    /*your css code*/
}
1 Like

I don’t know (=establish the trustworthness) of foss.heptapod, so let’s put aside the bug reporting, but if I infer correctly from a pair of old reports, seems that is an actual feature:

Later i’ll test your suggestions, but as I noted, I’m simply “experimenting” (read: messing and fooling around…) with Harlowe; but if you’re right and is an actual bug and not a feature, perhaps I was right in raising the question.

Best regards from Italy,
dott. Piergiorgio.

It’s not a bug per-say…

Harlowe is specifically designed to be a closed system, and it doesn’t expect an Author to manually use external things like CSS or JavaScript to extend the functionality of their project or of the Harlowe runtime engine.

Case in point…

The default HTML structure of the “Story”, “Passage” and “Sidebar” areas of the page are…

<tw-story tags="" style="">
	<tw-passage tags="">
		<tw-sidebar collapsing="false">
			<tw-icon tabindex="0" alt="Undo" title="Undo" style="visibility: hidden;">↶</tw-icon>
			<tw-icon tabindex="0" alt="Redo" title="Redo">↷</tw-icon>
			<!-- Author added Contents of the Sidebare -->
			testo di test
		</tw-sidebar>
		<tw-include type="header" name="Update Sidebar">
			<!-- Contents of your header tagged Passage, removed for simplisity. -->
		</tw-include>
		<!-- Contents of the Passage being visited, shortened for simplisity. -->
		My customary inglenook
	</tw-passage>
</tw-story>

When you use the (enchant:) macro to apply styling to the ?Sidebar Named Hook, the above <tw-sidebar> element structure is wrapped in a <tw-enchantment> element which is used to apply the enchantment.
eg. the following part…

<tw-sidebar collapsing="false">
	<tw-icon tabindex="0" alt="Undo" title="Undo" style="visibility: hidden;">↶</tw-icon>
	<tw-icon tabindex="0" alt="Redo" title="Redo">↷</tw-icon>
	<!-- Author added Contents of the Sidebare -->
	testo di test
</tw-sidebar>

…becomes…

<tw-enchantment style="background-color: rgb(197, 57, 50); display: block;">
	<tw-sidebar collapsing="false">
		<tw-icon tabindex="0" alt="Undo" title="Undo" style="visibility: hidden;">↶</tw-icon>
		<tw-icon tabindex="0" alt="Redo" title="Redo">↷</tw-icon>
		<!-- Author added Contents of the Sidebare -->
		testo di test
	</tw-sidebar>
</tw-enchantment>

So the enchantment is working, however your tw-sidebar CSS Rule is overriding the inline styling being applied by the enchantment.

There are a couple of ways you could achieve the colour changing outcome you want:

1: The “Harlowe” way

This would likely look something like the following Twee Notation base example. It would make use of Harlowe styling macros, to do the colour changing part, and use CSS to resize the “Sidebar” area.
note: I have left out the other CSS Rules in your example for simplicity sake.

:: StoryStylesheet
tw-sidebar {
	/* your layout property assignments */
	position: fixed;
	top: 0;
	left: 0;
	width: 15%; /* padding-right of the tw-story element. */
	max-height: 100%;
	margin-top: 5%; /* padding-top of the tw-story element. */
	padding: 0 0.5em 0.5em 0.5em;
	text-align: left;
	/* following needed because Harlowe uses custom elements */
	background-color: inherit;
}

:: Update Sidebar [header]
(change: ?SideBar, (bg: blue))
(append: ?SideBar)[testo di test]

:: Normal
Sidebar will be the default blue

:: Special
(change: ?Sidebar, (bg:#c53932))
Sidebar default colour is overridden.

2: The “CSS” way, using a CSS Variable

The following uses a CSS variable to store the colour to use for the background colour of the “Sidebar” area, and the Harlowe (css:) macro to temporarily alter that CSS variable’s value.

note: again for simplicity I have left out most of your own CSS Rules.

:: StoryStylesheet
:root {
  --bg-color: blue;
}

tw-sidebar {
	/* your layout property assignments */
	position: fixed;
	top: 0;
	left: 0;
	width: 15%; /* padding-right of the tw-story element. */
	max-height: 100%;
	margin-top: 5%; /* padding-top of the tw-story element. */
	padding: 0 0.5em 0.5em 0.5em;
	text-align: left;
	/* makes use of the CSS variable defined earlier */
	background-color: var(--bg-color);
}

:: Update Sidebar [header]
(append: ?SideBar)[testo di test]

:: Normal
Sidebar will be the default blue

:: Special
(change: ?Sidebar, (css: "--bg-color: #c53932;"))
Sidebar default colour is overridden.

Note: The (enchant:) macro monitors the page’s HTML structure, and the macro automatically re-applies its effect each time that structure changes. For this reason it is generally recommended to use the (change:) macro instead, unless you’re dynamically altering the structure / content of the page between Passage Transitions in reaction to the end-user’s interactions with the page.

2 Likes

the “Harlowe way” is perfect, and works as expected. Thanks !

EDIT: aside a flicker when activating link-reveals and like, but being a messing/fooling, isn’t a major issue…

Best regards from Italy,
dott. Piergiorgio.

After more than a month, I haven’t solved the issue of the flicker, so I’ll give a quick’n dirty test source:

:: StoryTitle
flicker demo


:: StoryData
{
  "ifid": "688209C1-9BAE-49FF-A3C7-DADB10638D74",
  "format": "Harlowe",
  "format-version": "3.3.9",
  "start": "start",
  "zoom": 1
}


:: left {"position":"200,250","size":"100,100"}
This passage has the default colouring (yellow on blue) and has no flicker.

back to [[start]]


:: passages {"position":"300,400","size":"100,100"}
(change:?SideBar,(bg:#c53932))
(enchant:?page,(bg:#451912))
seen that the flicker continues in this new passage ?<br> 
back to the saner, yellow-on-blue [[environment ->start]]<br>
[[let's look again at the flicking mess->right]] 


:: right {"position":"400,250","size":"100,100"}
(change:?SideBar,(bg:#c53932))
(enchant:?page,(bg:#451912))
<center>
###FLICKER !!</center><br>As you can see, there's a flicker, which became annoying when printing (link:"new text")[See ? of course in due process of multiple text (link-reveal:"additions") [= 
Needless to say, this issue is guaranteed to be a major annoyance, if not even (link-append:"dangerous")[=
for people suffering from flicker-induced seizures. Hence the seriousness of the issue; oh, of course this happens also when moving to [[passages]] with identical color scheme...]


:: start {"position":"300,100","size":"100,100"}
flicker demo:

at [[left]], is another, normal (yellow on blue) passage, at [[right]] a passage differently coloured, where lies the issue, in form of an an annoying flicker.

Your opinions ?


:: StoryStylesheet [stylesheet]
tw-story {
Background-color: navy;
color: yellow;
}

tw-link {
  color: orange;
  font-weight: normal;
}    
tw-link:hover {
	color: lime;
}
.visited {
  color: cyan;
}
.visited:hover {
  	color: magenta;
}


/* from mano & hal9k on intfic */

input[type=checkbox] {
	accent-color: red;
}

tw-dialog-links {
	flex-direction: column;
	gap: 0.5rem;
}

tw-dialog-links > tw-link {
	margin: 0 !important;
}

/* dal libro di cucina-per testare */

tw-sidebar {
  position: fixed;
  top: 0;
  left: 0;
  width: 15%; /* padding-right of the tw-story element. */
  max-height: 100%;
  margin-top: 5%; /* padding-top of the tw-story element. */
  padding: 0 0.5em 0.5em 0.5em;
  text-align: left;
  background-color: inherit;
  /*background-color: blue;*/
} 

Any ideas on the cause of this annoying flicker ?

Best regards from Italy,
dott. Piergiorgio.

As I mentioned before, the (enchant:) macro reapplies its effect every time the HTML structure of the page changes. And your example is using the (link:) family of macros to make such changes to the page.

This means the background colour you’re apply to the page via an (enchant:) macro call gets reapplied each time one of those links are selected. And this removing and re-adding of the background colour is likely one potential cause of your “flicker”.

Harlowe used a 2 step process to achieve the default visual effect associated with a Passage Transition. The contents generated by the processing of the Passage being visited is first added to the page wrapped in a special custom element. A short time later that special custom element (and its children) are removed from the page and the pre-mentioned generated content is a added again. without the special custom element wrapper.

This adding then removing and then re-adding of content to the page can cause:

  • a delay in the applying of CSS Rule based styling that targets specific areas the page.
  • effects being applied to the page via (enchant:) macro calls to be re-applied.

Replacing of any (enchant:) macro calls that target the page with (change:) macro call equivalents should reduce the “flicker” being caused by such enchants.

1 Like

hmmm… perhaps the solution to the flicker lies in the use of passage tags, as in the cookbook example ?

Best regards from Italy,
dott. Piergiorgio.

The solution to the “flicker” caused by the selecting of the right Passage’s links is to change the (enchant:) macro calls in the right and passages passage…

(enchant:?page,(bg:#451912))

…to be (change:) macro calls instead…

(change: ?page, (bg:#451912))

The solution to the “flicker” that happens during the Passage Transition to a Passage that is using either (enchant:) or (change:) to change the page’s background colour, is to use CSS Rules that target specific Passage Tags that have been assigned to that Passage.

eg. If you assign a winery Passage Tag to the right and passage passages, then a CSS Rule like the following could be used in your project’s Story Stylesheet area to style those two passages…

tw-story[tags~="winery"] {
	background-color: #451912;
}

…and using this method reduces the “flicker” that can happen during a Passage Transition.

note: Because I don’t know the purpose of the specific background colour you’re assigning to the right & passages passages, I don’t know what more meaningful name to give the winery Passage Tag, so I named that tag based on the colour being assigned. But generally it’s better to name things like CSS Classes, Passage Tags, Hook Names, etc based on their purpose and not based on their effects.

1 Like

has definitively solved the issue !! Thanks !

/* dalla risposta di "greyelf" alla mia questione sul 
flicker nei passaggi */

:: UserStylesheet[stylesheet]

[tags="dusk"] {
    background-color: #451912;
}

as a little bonus prize, from the css snippet above you known what is the purpose :wink: and yes, I fess up: the ancient intellivision game Frog Bog gives a lasting impression in my youth, so in my experimentation/fooling around arena I wanted to recreate the background colour marking the passage of time, from the dawn pink to the black of the night…

Best regards from Italy,
dott. Piergiorgio.

One issue with using the less specific [tags="dusk"] selector instead of the more specific tw-story[tags~="winery"] one in my example that also includes the element-type, is that the 1st will apply its styling to both:

  • the parent <tw-story> element.
  • the child <tw-passage> element.

…because both of these elements have a tags attribute to which the Passage Tags of the visited Passage are assign.

And while applying the same background colour to both of these elements won’t cause an issue, doing so is inefficient as the parent’s background colour will automatically be applied to the child anyway.