Please specify version and format if asking for help, or apply optional tags above:
Twine Version: 2.3.5 (Desktop) Edit: now 2.3.8
Story Format: Harlowe 3.1.0
I’m having a problem with layout in my Twine story. I’m getting a huge “header space” at the top of every passage, of approx 8 line-heights. I’ve tried everything I can think of to reduce it, but to no avail.
This is roughly what it looks like. I’ve used the style sheet to change the color of the main window so that I can see the other elements against it.
It makes no difference if I have any “invisible” lines of passage text (doing math or whatever.) It makes no difference if, when I do have invisible lines, I use the whitespace collapse markers {}.
I’ve set padding-top in the tw-passage element to zero.
Looking at the page using the Inspector, the passage element is controlled by “Flex” but although I can add padding to that, I can’t get rid of this ugly space at the top.
I’ve tried adding a lot of content to one passage, but although that makes the box longer, it doesn’t reduce the space at the top (so it’s not some proportional thing.)
I think this unwanted header space must be inherited from something, but for the life of me, I can’t work out what.
I got rid of this by overriding the tw-story CSS. It might have been padding, but could have been margin too. (I’m overriding them both and I don’t recall exactly which it was to eliminate this.)
But that’s not doing the trick! If you’ve time, would you be willing to post your stylesheet (or just a list of the elements you’ve overriden)? Then I can fool around with the thing myself. My problem is that I often don’t know exactly what the @$%&£% things are called!
Edit: setting margin-top of the tw-story element to zero just puts the tw-passage element hard up against the edge of the window – still with the giant, ugly space at the top. Sigh.
Alas, none of those overrides affected the header-space problem. OTOH googling around, I found that a new version of Twine has come out, so I’ve upgraded to that. (That didn’t fix it either.)
But thanks for your help.
Have you tried using the element inspector with your browser? I believe it’s usually control+shift+I or the F12 key.
Key features of it are you can use the element picker (I believe the icon looks like either an arrow or an eye dropper tool usually) to highlight a specific element and then it’ll list all of the CSS settings that are affecting it. You can easily enable or disable those elements or even alter their settings and it’ll update the HTML in real time.
It saves a lot of guess work like you’re doing right now by letting you quickly narrow down which CSS setting is being the trouble maker.
Playing around in the browser’s Inspector, it looks like that’s the padding on the tw-story element (padding: 5% 20%) and putting tw-story: { padding: 0% 20%; } in my story stylesheet fixes it for me. So give that a try.
I had tried pinpointing the problem using the Inspector as @tayruh had suggested, but nearly went blind trying to read the teeny-tiny gray text (reminded me of my credit card bills). Happily I’ve now discovered the whatsit for picking an element off the page (and thereby the style filter thingy.)
More ASCII art!
------------ (edge of window)---------------------------------------
| |
| tw-story padding affects this area |
| |
| ------(sidebar)----- ---------(tw-passage)---------------- |
| | | | | |
| | return arrow | | | |
| | Blah, blah | | | |
| | Blah, blah | | | |
| X| | | (This is the problem area) | X |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | Text of passage begins here | |
| | | | | |
| ------------------- ------------------------------------- |
| |
| tw-story padding affects this area |
--------------------------------------------------------------------
tw-story padding affects the areas marked X as well.
I’ve systematically tried all of the padding- values for tw-passage, and none of them make more than the slightest fractional difference to this blasted blank space.
Does tw-passage inherit from anything? Is there something I might have messed up in the actual passages themselves? (I’ve just tried deleting the “Setup” passage in case those initial values were invisibly using up the space. Nope.) I’m not using any header or footer passages.
Edit: opened up a different WIP and the problem space is there, too. Looks like it’s a hard-coded part of Harlowe, or something.
All properties that are affected by CSS should be listed in the element panel and they’ll be divided up by inherentance. The ones that are overridden will be crossed out, IIRC.
Sometimes that gets confusing though, so there’s a tab called “calculated” or something like that after the elements tab (this is by memory of Chrome’s inspector). It’ll list all of the properties and their actual values (IOW, it’ll list something’s current width as “115.36px” instead of the CSS value of “60%”). Under each value it’ll list which CSS setting is altering that value and clicking it will bring you right to the setting. It’s very helpful.
Surely I can’t be the only person that Twine hates?
Nope! Twine is actually what helped hone these element hunting skills that I’m describing for you. And now they’ve helped me with my other HTML projects.
Huh. What happens if you create a new, empty story? If I make a new Harlowe 3.1.0 story and set the vertical tw-story padding to 0% the passage text is right smack at the very top. I checked in Chrome, Edge, and Firefox on Windows 10.
Or if you want to share one of your WIPs (privately if it’s a potential comp thing, of course) I could take a look at it…?
With your suggestion for creating a new, empty story, I’ve been able to track down what’s going on. As usual, it’s the fault of the monkey at the keyboard. I’d adjusted the settings for tw-sidebar.
Using the Inspector tool (thanks @tayruh!) I was able to work out that it’s the
position: relative;
that was adding in the extra space. Only values of “absolute” or “fixed” do not add this extra space.
I’m not sure exactly what the various values actually do; I’ve tried to understand the “box model” before, but all I achieved was an uncomfortable feeling between my ears. I’ll have to have another go a it!
Thanks to everyone who’ve helped me get a handle on this: it’s typical that I fixate on some irritation that has nothing to do with gameplay and then just… can’t… let… it… go.
(Edit: Both Josh and Tayruh have added explanations of how the layout works, and what was going on. Scroll down to read them.)
By setting the position to absolute or fixed, you are actually removing it from the normal layout of the page. The elements following it align themselves as though that element doesn’t exist. So you’re not really fixing your padding/margin problem, you’re just shuffling around page elements.
static is the normal setting that places the element in the layout without any position changes.
relative adjusts the element’s position based on the previous element’s top-right corner. top: 0, left: 0 makes it look identical to static. The elements following this one act as though the element is still in its original position with static even after the element moves.
absolute adjusts its position based on the parent element that is not static (defaulting to the page/viewport if none found). top: 0, left: 0 places it at the top left corner inside the parent. The elements following this one act like this element does not exist and will be positioned according to the element preceding this one.
fixed positions itself based on the page or viewport. top: 0, left: 0 places it at the top left of the page. The elements following this one act like this element does not exist and will be positioned according to the element preceding this one.
<tw-passage>
<tw-sidebar>...</tw-sidebar>
your passage content
</tw-passage>
As @tayruh said, position:static is the default behavior: so the sidebar would get laid out before (above) the passage content.
position:relative is the same except you can offset it from its normal position by using the left or right properties (or top/bottom as well?). So it will still be above the passage contents.
position:absolute uses the left/right/top/bottom properties to position the element relative to its “containing box” (usually its parent, the bigger box that it’s inside, but the actual algorithm is complicated and sometimes weird).
In this case, Harlowe’s default styling is using left:-5em to say "start the sidebar 5 em-units to the left of tw-passage and width:3em to make it 3 em-units wide. So it fits in the blank space left by the rest of the layout.
position:fixed is sort of like absolute, but instead of positioning relative to its parent box, it is positioned relative to the window (more or less). And there are also a couple of other more complicated position options.
Yes, I suppose so. I really wish I could see the the full CSS for Harlowe somewhere – although being confused about what whitespace was due to padding and what derived from the layout didn’t help!
I might ask the recipe book people (or whoever’s looking after the Harlowe manual) if they’d mind including the CSS as an appendix, but they seem in the midst of a major overhaul at the moment, so it’s probably not a good time to bother them.
Ah. You could try looking at the source .scss files files… That gets processed (presumably by the Sass tool) into actual CSS, so it will be a little different, but mostly the .scss is just simpler (variables for the colors and such).
Oh, I see. So the sidebar, having usually only the “back” arrow in it, makes for a decent-sized “header space” at the top of the passage. But the moment you add any more content to the sidebar (as I have), the visual space at the top of the passage gets larger, and to me, ugly.
Good job I didn’t decide to bung the player’s inventory there, eh?
I’m on my phone and was just going by memory. Hehe.