Some people liked the iframe preview

you have to publish the post first. thats the trick, and essentially goes to the heart of why its not really a preview option, anymore.

whooami, that’s not true – there is no requirement to publish a post before previewing it at all. It works just fine in draft mode.

The one problem I’m having is that the Preview button seems to “float” all over the place in Firefox/Mac. One minute it’s where it should be, the next it’s sitting on top of the categories list, etc. Anyone else seeing this?

Count me among those who were really irritated to find the inline Preview removed. I too do not like bouncing back and forth between tabs and find the current scheme annoying.

Really some consultation beforehand would have been appreciated.

The first rule for a developer should be to remember that real non-developer people use the products, and that the change that seems perfect might just make the product less usable.

I, too, would have liked an option to keep the inline Preview intact.

I’ll just add my vote for having the option to have the inline preview … I can see that sometimes a new tab would be useful, but there are other times the inline one is more handy.

Nice, Rongo. Thanks for that; I added it myself. I doubt having the “preview” button is faster, since to preview you have to open new tab/window and open it. It’s only faster if you are saving multiple times and you don’t need to preview the post.

No, it’s a lot faster because the inline preview required an annoying delay while it rendered the actual page. Every single time, even if you didn’t scroll down to look at the preview. The view link lets you get a preview when you actually want to see it instead of just getting it by default on the edit form.

Maybe I’m dense, but what functionality is this adding? If I wanted to preview the post in a separate window (tab), I could scroll down to the inline preview, right click on the post title, select the menu option “Open in new tab”… and then the post would magically appear, in its own tab. That’s: a scroll, and two mouse clicks (or a scroll, and a wave of the mouse, since I’m using Opera).

But, I would still have the option of looking at the preview inline, if I wanted to… Before I had both pieces of functionality built-in, automatically, by the browser (this is surely built into any browser which also allows you to open multiple windows/tabs). Now I have only one option. Which has been made fractionally easier by adding its own special button.

Admittedly, this new system opens a preview with an extra &preview=true appended to the end of the URL… Which does… what? Is it dependent on the theme I’m using?

No, it’s a lot faster because the inline preview required an annoying delay while it rendered the actual page.

It renders the iframe separately, doesn’t it? Or is that only on Opera… Maybe I just have super fast connections. Does the iframe hold up rendering of the entire post page?

Admittedly, this new system opens a preview with an extra &preview=true appended to the end of the URL… Which does… what? Is it dependent on the theme I’m using?

Some themes and plugins will recognize the preview variable and not render some bits of relatively useless code, like adsense code, for instance. The iframe itself should have rendered with that variable already, that’s not entirely new.

Does the iframe hold up rendering of the entire post page?

Not always, but it can do that, yes. Especially if your site itself has bits that hit third party sites which are slow to respond. There’s a lot of factors at play here.

It can also interfere with the execution of the javascript and other behind the scenes things on the write post pages, because until it renders, javascript might not execute, or at least, might not execute properly.