When creating or editing a post, even with user css, the width of the entryfield is restricted by the presence of the sidebar. I find this frustrating. Would it be possible (without major redesign) to add a user config item to turn off the sidebar for preview pages?

Follow on discussion of whether anyone (else) would use it, or who would implement it etc. can probably wait until its confirmed as to whether it is actually possible.

Update: title corrected per talexb's comment below.

  • Comment on Could we lose (or turn off)the sidebar during preview?

Replies are listed 'Best First'.
Re: Could we loose (or turn off)the sidebar during preview?
by talexb (Chancellor) on Oct 19, 2010 at 20:47 UTC

    This is actually a cool idea -- the sidebar probably chews up significant resources to fetch, but it's content is going to be ignored while the monk goes through the usual edit/(preview)+/post cycle. Great idea!

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

    ps And I suspect it should be 'lose', not 'loose'.

Re: Could we lose (or turn off)the sidebar during preview?
by ambrus (Abbot) on Oct 20, 2010 at 07:57 UTC

    If you don't care about server load, just add this to your personal CSS settings:

    body#id-11911 .nodelets { display: none }

      I'd much prefer to avoid the server load, but as an interim step that works perfectly.

      I also added:

      body#id-3333 .nodelets { display: none }

      To achieve the same affect on the "Comment on" node.

      In the absence of the server saving option, that saitisfies me quite well. Thank you.

      AAA: It took me a couple of seconds of wondering what 'no delets' meant (and why the 'e' was missing) before the penny dropped :o)


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Could we lose (or turn off)the sidebar during preview?
by ahmad (Hermit) on Oct 19, 2010 at 23:00 UTC

    I think this should be the default behaviour ... because as noted by talexb ... no body *will* use the sidebar while writing or editing a node.

    So I would suggest removing the sidebar for both the 'Commenting' form & the 'Preview' form

      > no body will use the sidebar while writing or editing a node.

      So I'm "Nobody"? ;)

      I'm using the "Free Nodelet" a lot when writing!

      Cheers Rolf

Re: Could we lose (or turn off)the sidebar during preview?
by kcott (Archbishop) on Oct 19, 2010 at 23:32 UTC

    I would definitely be in favour of a wider textarea to edit my posts.

    Having said that, is it actually the sidebar that's limiting the width? I've just checked the source (while making this post) and found:

    <textarea name="note_doctext"  rows="10" cols="60">

    It may be that this is configurable through one of the Settings screens: I've looked but haven't found anything that seems to do that.

    Regardless, not having to wait while XP is calculated, CB is updated, current user list is compiled, etc. would be most welcome.

    -- Ken

      I would definitely be in favour of a wider textarea to edit my posts. Having said that, is it actually the sidebar that's limiting the width?

      I've long had this css (courtesy of some other kind monk who's name I've long since forgotten), in my Display settings/On-site CSS markup thingy:

      textarea { width: 100%; height: 25em; }

      That has the effect of doubling the width over the standard view, at which point it butts up against the sidebar. A very useful increase, but still less than it could be.

      I still find it limiting when, as my old eyes get tired, I zoom the page to 150% or 200% to compensate. Trouble is of course, the sidebar also gets bigger. So as the font increases in size, the effective usable area barely changes or even starts to shrink.

      Were I able to turn off the sidebar, not only would that increase the screen real-state available for use in the textarea. It would also avoid the annoyance of seeing a new /msg appear, instinctively click it, and watch what I've typed so far disappear in to the lottery that is the browser cache.

      Most times you can back up to it, but sometimes--always when you've typed the most because you've been using lots of other tabs to do research--when you back up the page has been flushed from cache and Whoops! Sorry. All gone. Which is intensely annoying.

      I also think that clicking or responding to /msgs is responsible for a lot of duplicates posts, so it might help there also.

      But best of all, anything that reduces the impact on the PM servers has to be good right?


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Thanks for that. I modified it slightly:

        textarea { width: 64em; height: 32em; }

        That looks fine for me to start with - I'll probably play with it as time goes on.

        I had picked a Theme but didn't know I could add CSS to that - the field in Display Settings looked like replacement CSS.

        I don't use the sidebar while composing a post and losing the overhead it incurs would be a good thing.

        -- Ken

        "I also think that clicking or responding to /msgs is responsible for a lot of duplicate posts, so it might help there also.

        For that alone I too think it is a excellent idea, to make it the default setting on the Comment / Preview page.

        I'm sure we have all fallen foul of the duplicate post problem.

        I also think that clicking or responding to /msgs is responsible for a lot of duplicates posts

        I don't see how. Perhaps you could expand on your theory?

        - tye        

Re: Could we lose (or turn off)the sidebar during preview?
by Arunbear (Prior) on Oct 20, 2010 at 10:19 UTC