in reply to meta-information in reply-authoring node

See Re^3: Jump to head (replying to).

Update: Replying to a node by adding an update to your node isn't the best choice if you actually want your reply read.

If your browser doesn't give you the choice to open a window or not then I'd think you want to fix your browser or its configuration.

If they wanted to do that without considering the consequences, there would already be enough links to choose from in the nodelets etc.

There is a big difference between a link specificly designed for use during preview and having misc. links on a page while you are concentrating on writing a node. If you take a diversion via one of those links unrelated to your composition work, then you are likely to think and open the link in a new window, though you make a good point; we should probably add <base target="_new"> during previews to eliminate this problem. Thanks for the idea.

Not wanting to contribe to the frustration of losing something you've been working hard on composing, I won't be adding the link w/o target="_new". My conscience won't allow me.

But I don't really care to endure the wrath of those who have an undying hatred of target="_new" in all forms (and yet refuse to help themselves, *shrug*), so I doubt I'll add it with target="_new".

BTW, y'all need to go write a petition or something to have the existing uses of target="_new" removed from PerlMonks. I haven't heard any complaints about any of them (other than the ones I complained about and had changed already), but I'm sure y'all can remedy that.

- tye        

  • Comment on Re: meta-information in reply-authoring node (replying to again)

Replies are listed 'Best First'.
Re^2: meta-information in reply-authoring node (replying to again)
by muba (Priest) on Jun 10, 2004 at 17:52 UTC
    Not everyone uses Microsoft Internet Explorer. In Opera, for instance, this trick will not work.
[reply]
      That's what this bookmarlet is for: javascript:dT30FfN3b=new Date();void(window.open(location.href,'w'+dT30FfN3b.getTime()))

      C-n + History works well too.

      --
      I'm not belgian but I play one on TV.

[reply]
[d/l]
Re^2: meta-information in reply-authoring node (replying to again)
by mhi (Friar) on Jun 11, 2004 at 04:23 UTC
    tye, now I don't want to fuss with either your conscience nor any wrath you might invite upon yourself :-) , so I won't pursue the original suggestion further. You have however given me another idea that may suit all:

    How about adding these links to the Node Status nodelet or the Node Navigator nodelet or to a still-to-be-created Hierarchy nodelet?

    BTW: thanks for the update/reply tip.

[reply]

      Actually, I think it should be pretty much where and how you proposed (except make it a bit distinctive to help prevent adding to the illusion that the node has already been posted).

      But I've been burned by my cache losing a node I just barely left too many times and still recall how maddening that is. And I've heard several others complain.

      Once the ability to recall your most recent preview gets added, this will reduce the loss in such cases to the changes you made since the last time you push the 'preview' button. But even that isn't something I want to be responsible for increasing the frequency of. Doing so would feel just like I was laying a trap to catch the occasional unlucky sole.

      And it sounds like the target="_new" is much more despised than the link is desired. Since my conscience isn't cleared by the vote, I've got two choices left. The consensus regarding those two choices seems pretty clear at this point.

      I currently predict someone else will add the link w/o target="_new", maybe even test it and not get bitten. [ This was one of those cases where the browser seemed to sense things and would allow me to quickly jump away from previews for weeks or months without problems, lullling me into confidence that I knew not to go "too far" and then, when a lot of work went into a preview and I was particularly pressed for time, suddenly it'd throw away a preview, but only after I'd gone not quite as far as last time so I'd continue to think I could get away with this if I was just a little more careful. Finally one day it was forced to throw away my hard work (around the 5th or 6th time by then, after years) after a single-hop diversion of only a few seconds right after the preview had been fetched. Then I knew there was no "safe distance" and the caching decisions were too chaotic for me to predict (I could still often load cached preview results from several days ago). ]

      But it is still early. I'll wait and see how the signs point...

      - tye        

[reply]

In Section Perl Monks Discussion