Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Recovering space taken up by sidebar in SugarCube

Am using Twine 2.0.11 and SugarCube 2.11.0. I can remove the sidebar by adding this to my stylesheet
#ui-bar { display: none; }

but this does not move the left margin of the text. I looked at previous threads on this forum which suggested that
body { margin-left: 5px;}

should work, but this only moves the text relative to where the right border of the text box used to be. Changing the width of the sidebar does not help either. Putting negative numbers in the margin-left seems a bad idea. How can I reclaim the space previously taken up by the sidebar?


  • edited November 2016
    .passage {margin-left: #px;}
    Maybe? But it sounds like you're more familiar with CSS than me.

    Of course you replace # with a value.
  • I tried that too, but it doesn't work either.
  • edited November 2016
    SugarCube v2's UI bar styles are what shift the main passage display area over—to provide space for itself.

    If you wish to completely remove the UI bar, then I'd suggest simply removing it and its styles. For example: (Twine 2: goes in Story JavaScript; Twine 1: goes in script-tagged passage)
  • That worked! Thank you
  • @TME, can I set something so that the sidebar displays "over" text? So it's like an overlay, on a different z-index (or whatever it's called), above the text.

    I guess what I want is for it not to resize the Passage text when the sidebar opens.
  • The UI bar is already on a different, higher, z-index from the main passage display plane. It also already does what I believe you want when the viewport is small. So, the only hurdle here would be to make it do that all the time.

    Try the following styles and let me know if they do what you want:
    @media screen and (max-width: 1136px) {
    	#story {
    		margin-left: 3.5em;
    #story, #ui-bar.stowed ~ #story {
    	margin-left: 3.5em;
  • Yep, they both each does what I want, thanks.

    What's the difference between them, by the way? Is the former dependent on the viewport size while the latter isn't or something?
  • edited February 2017
    You need them both and in the order I gave them, elsewise odd things are going to happen at various viewport sizes. They're each needed to override specific default rules.

    Is the former dependent on the viewport size while the latter isn't or something?
    That is correct, yes.
Sign In or Register to comment.