in reply to Re: Could we lose (or turn off)the sidebar during preview?
in thread Could we lose (or turn off)the sidebar during preview?

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;
}

[download]

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.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^3: Could we lose (or turn off)the sidebar during preview?
by kcott (Archbishop) on Oct 20, 2010 at 00:47 UTC

    Thanks for that. I modified it slightly:

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

    [download]

    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

[reply]
[d/l]
Re^3: Could we lose (or turn off)the sidebar during preview?
by Gavin (Archbishop) on Oct 20, 2010 at 07:53 UTC

    "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.

[reply]
Re^3: Could we lose (or turn off)the sidebar during preview? (dups)
by tye (Sage) on Oct 21, 2010 at 00:27 UTC
    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        

[reply]

      This is the scenario where I think I've seen this happen.

      1. You prepare your reply, click "create"; the servers running a bit slow so you switch to another tab for a few seconds or minutes.
      2. When you return, you notice a /msg (that was probably there from before), and either click to browser the reply node, or send /msg response.

        You fail to notice that the create hasn't completed.

      3. You back up to get back to whatever you were doing before you switched away, see the create button and click again. Dup.

      Is that a realistic scenario? I'm not sure. You rarely think to take detailed notes before the duplicate happens.

      But if it is, the absence of nodelets might prevent it. Not a big argument in favour of it, but may a little icing if it comes about.

      Which it has for me--via css--I am gleefully typing this reply in a (zoomed 140%) full-screen wide textarea. If I could avoid generating the load of the nodelets, I would willingly.

      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.
[reply]

        Rather complicated for it to account for "a lot" of dups.

        And such simplistic re-submit is caught by simplistic protections. It isn't hard to thwart the simplistic detection due to races. But your scenario introduces extra time which makes it less likely to be able to produce an actual dup.

        Update: I even re-submitted this reply just to verify that the simplistic detection was working. I indeed got sent to Duplicate Post Warning.

        You can further complicate your scenario by adding extra "edit" (and possibly "preview") step(s) after going "Back" and before hitting "Create" again and then it results in near-duplicate nodes. But it also makes it even less likely to account for "a lot" of them.

        - tye        

[reply]

        Reminds me of my need to be able to remove duplicate posts in which there is only a small difference.

        I've seen multiple times that accepting a post after review took soooooo long that I got a timeout. After doing <back> and [create] again - maybe after adding a line to explain something that sprung up to add during the submission wait, both posts have been accepted even thought the first clearly gave the feedback of a timeout.

        In this case I would love to be able to remove the first post.


        Enjoy, Have FUN! H.Merijn
[reply]
[d/l]

In Section Perl Monks Discussion