Conditionally displayed options without breaking layout

Question

Hi, 

 let's say I have passage text with conditionaly dispayed options .. and based on conditions/click actions I want the appropriate options to be displayed without keeping the empty lines (or bullets in case of list of options)

Currently I came around this using the {} (escape to trim whitespace) and html <p> markup (in html all the paragraphs are displayed after each other). But I have to manually format/distinct the lines using <br> / <p>, which is cumbersome ..

Servant has approached, carrying something very |smell>[stinky].

Finally he asked: //"Would you like some eggs?"//

{
  <p>[[Yes, please.. ->eggs]]
 (if: $hungry is true) [
    <p> I'm starving, [[bring them!->eggs]]
 ]
   |vegetarian)[
         <p> I'd rather get [[a carrot->carrot]]..
   ]

  <p>Thank you, I'd rather get [[some coffe.. ->coffe]]
 
(click: ?smell)[
  (show: ?vegetarian)
]

}

is there some other way I've missed? thanks :)

 J.

ps:  similar example would be great as a new recipe in the gitbook, I suppose every new 'writer' have to deal with the formattings vs macros ..

Answer 1

The simple answer to your question is No

Yyou use Collapsing Whitespace markup to suppress the line-breaks within you Passage content being automatically converted to HTML br elements, and then manually inject br elements where they are actually needed.

note: There are a number of issues with your example:

1. You shouldn't use the is operator to check if a Boolean value equals true or false, the correct syntax to do that is.

(if: $hungry)[The hungry variable currently equals true]

(if: not $hungry)[The hungry variable currently equals false]

2. There are no end paragraph element tags </p> in your example, this means the web-browser needs to guess where they should be placed. In Chrome this resulted in one of your paragraphs being embedded within another, which is generally not ideal. The following is an example of the HTML structure being generated for your Passage, assuming the $hungry variable equals true.

<tw-collapsed>
	<p data-raw="">
		<tw-expression type="macro" name="link-goto">
			<tw-link tabindex="0" passage-name="eggs" data-raw="">Yes, please.. </tw-link>
		</tw-expression>
		
		<tw-expression type="macro" name="if"></tw-expression>
		<tw-hook>
			<p data-raw="">
				I'm starving,
				<tw-expression type="macro" name="link-goto">
					<tw-link tabindex="0" passage-name="eggs" data-raw="">bring them!</tw-link>
				</tw-expression>
			</p>
		</tw-hook>
		<tw-hook name="vegetarian"></tw-hook>
	</p>
	<p data-raw="">
		Thank you, I'd rather get
		<tw-expression type="macro" name="link-goto">
			<tw-link tabindex="0" passage-name="coffe" data-raw="">some coffe.. </tw-link>
		</tw-expression>
		<tw-expression type="macro" name="click"></tw-expression>
		<tw-hook></tw-hook>
	</p>
</tw-collapsed>

3. Due to how the (click:) remated macros are implemented you should only use them when it's not possible to use a (link:) related macro to achieve the same result. I suggest changing the first line of your example to

Servant has approached, carrying something very (link-repeat: "stinky")[(show: ?vegetarian)]

 

Comments

ok then, thanks for info and pinpointing 'notes' :)

ad - is this usage a problem? I understand it's uneccessarily verbose, but this way it works even without setting the initial value of the variable (not set (eg value 0) is not true), otherwise the online editor would complain. There are multiple people working on the same story and I don't have the passage, which will set the variable, between my passages, but I have to decide upon it .. (I've prepared fake start passage which will set them, but to start from any passage ..) .. the code I've mentioned was just example, not the real story ..

ad 3 - I've chosen (click: ) for better readability (or in programing slang - to decouple concerns), to either show the prose, or describe the functionality .. are there any drawbacks of using it instead of (link:)? for example too hungy on resources? unexpected behavior in some corner cases? deprecated macro which will be discontinued in the newer versions?  

  the only disadvantage I knew about was that I cannot do click-replace, but I've rechecked the documentation now and click-replace actualy exists ..

---

> Variable initialisation.

Ideally you should initialise all your story variables before you reference them in conditional expressions or output thier value, and the best place to so that is within your project's startup tagged special passage. Doing so allows you to control the variable's initial value, as there is no guaranty that the story format Developer won't change what value is assigned to an 'undefined' story variable. It also gives you a central location to look when trying to recall the existance or spelling of a particular story variable.

> The (click:) related macros.

These marcos work by adding an action to the Passage Transition process's post-render queue, and the actions contained within this queue are executed after the HTML that was generated for the current Passage has actually been added to the web-page's DOM.

Each (click:) associated action needs to scan the whole of the web-page's current DOM so it can find all instances of the macro's 'target', and such scanning is an expensive process. The (click:) associated actions stay in the queue until the next Passage Transition occurs.

Any interactions, by either the Reader or from things like the (live:) macro, that result in dynamic changes to the current web-page's HTML structure (like your (show: ?vegetarian) code) can trigger the re-execution of the current actions of the post-render queue.

---

I see .. thanks for explanation

I'll change them to link-replace for the 'production ready' version, until then I'll keep more readable version (reaction to click is much more complex in our story)