Live Comment Preview
Shelley Powers: I’m beginning the process of finetuning XHTML and comments. Per suggestions via Jacques Distler and Sam Ruby, I’ve begun the creation of ‘safer’ comments, but the job is going to be a challenge.
It occurs to me that I’ve strayed into the giving of advice on areas that I haven’t directly experimented with myself. So to correct that, I’ve added a Live Preview checkbox on the bottom of the page that you see when you preview comments. It undoubtedly has bugs (both of the “do something bad” and “do something different than the server does” varieties), and I’ve yet to try it on any browser but Firefox, but those that wish to do so can try it out.
Or not. The default for that checkbox at the moment is off.
I second the Ajax preview suggestion. I hadn’t seen Jacques’ comment in the comment feed and clicked through from my aggregator to say exactly that.
Posted by Aristotle Pagaltzis at
One thing I decided to leave off the changed comments was Live Preview. I’m doing in-page preview, edit, and then submit. But it is interesting to see this put together with JavaScript.
Posted by Shelley at
It seems rather odd to have both a live preview and a forced-preview.
The current form is clearly not optimal or final.
That would also eliminate the “do something different than the server does” issue.
My approach to this is to create tests to ensure that the results are compatible.
Posted by Sam Ruby atHow does it work, exactly? Checking the “Live Preview” did nothing for me (Opera 9.12). It was also awkward to find the “Live Preview” checkbox on the preview page. Having it available on the first page would make more sense. Also, if there’s not too much lag involved, using Ajax for the preview is a good idea.
You could use Ajax for embedding the “Formatting Rules” inline the thread page too, by hiding the contents by default and then serving them from the server on a mouse click. Where JavaScript is turned off, the mouse click would bring you to a page explaining the formatting rules, with the exact same content you would get by clicking the link with JavaScript enabled (only then it appears inline).
Also keep in mind that the live preview should only kick in if Ajax is working as intended, so that posting with a non-Ajax UA doesn’t spoil the (old, but working) preview function.
Posted by Asbjørn Ulsberg atVery nice, Sam. You never cease to amaze.
The only bug I’ve been able to find thus far is that it seems the nested blockquote only works when deeper nested quotes come before less-nested quotes?
For instance, try typing in the following:
>> This nested blockquote will work just fine > See? What did I tell you. > This nested blockquote will break everything... >> ...That was unexpected
As soon as you type that last >> everything will break.
Posted by Kevin H atChecking the “Live Preview” did nothing for me (Opera 9.12).
After I’m satisfied it is working on Mozilla, I’ll move onto Opera.
It was also awkward to find the “Live Preview” checkbox on the preview page.
That may very well be temporary. But for now I will note that what you check is remembered from session to session.
it seems the nested blockquote only works when deeper nested quotes come before less-nested quotes?
Actually, the blank line between multiple quotes was also key, and this problem was common with the Python implementation. I’ve fixed both, but you might need to do a F5 refresh to reload the script.
Your weblog explodes at the first hint of top-posting?
Huh?
Posted by Sam Ruby atI’ll move onto Opera
Actually, it turned out that the bug was trivial, and is now fixed.
Posted by Sam Ruby atYour weblog explodes at the first hint of top-posting? You rule.
I had a good laugh there.
My only real quibble with the implementation is that you have the live preview under the text entry area instead of above it. Not sure why this bothers me, but I hate it whenever people decide to do it this way. Likely for very similar reasons as why I don’t care much for top-posting.
Posted by Bob Aman atI hate it when people put their Ajax or live preview above the textarea. It causes the textarea to shift and bob as you write – particularly with long comments where you might cut and paste a larger section. I suppose putting the preview horizontally next to the textarea would be a reasonable compromise, at least for people with large enough screens.
Posted by Aristotle Pagaltzis at
My only real quibble with the implementation is that you have the live preview under the text entry area instead of above it.
Due to caching, you both may not have noticed the changes I made yesterday. Go to any page that has an “Add your comment” header (i.e., any specific post, not my index page) with either Firefox or Opera and before you type any character on that page, press F5 refresh, then begin to type a comment. The first character you type in the textarea labeled “Comment:” will trigger an AJAX request which, when complete, will add a a checkbox for Live Preview (remembering your previous setting), and either a Submit button or a one or more warnings. The warnings will appear in red and above the form (which may be jarring), and the live preview will appear in yellow below the form (in fact, you may need to scroll to see it).
I’m still tweaking and playing (example: the original Preview page hasn’t changed much). Polling for new comments while you are typing is also quite doable, but I haven’t figured out the UI implications.
When all this stabilizes, I’ll rename the .css and .js file, which will force everybody to fetch the latest version of each.
Likely for very similar reasons as why I don’t care much for top-posting.
I actually hadn’t heard that term before. Now that I know what it means, I get Phil’s joke, and I agree, I don’t care much for top-posting either. :-)
Posted by Sam Ruby atTop live preview would certainly have an interesting social impact, what with the way it would scroll the form out of sight if your comment gets a bit too long.
Trunk Firefox seems a bit unamused by your profligate cross-document child-swapping ways, throwing a wrong document error on button.parentNode.appendChild(captcha); for lack of a document.adoptNode(captcha); first.
Top live preview would certainly have an interesting social impact, what with the way it would scroll the form out of sight if your comment gets a bit too long.
That effect is counterbalanced by the urge to keep the cursor visible; in fact if you are actively typing, the latter urge dominates and the net effect is the opposite: it is the preview that is scrolled away.
Trunk Firefox seems a bit unamused by your profligate cross-document child-swapping ways, throwing a wrong document error on button.parentNode.appendChild(captcha); for lack of a document.adoptNode(captcha); first.
Good catch. Fixed. Thanks!
This comment was entered using MineField installed using firefox-3.0a3pre.en-US dated 21-Mar-2007. Mmmmm... feGaussianBlur.
Posted by Sam Ruby at
It seems rather odd to have both a live preview and a forced-preview. Maybe something that would fit better with your setup (and with Shelley’s proclivities) would be to use Ajax for the forced-preview.
That would also eliminate the “do something different than the server does” issue.
Jacques
Posted by Jacques Distler at(never one to be shy about offering advice, regardless of whether I’ve experimented with it myself)