Jacques Distler: It seems rather odd to have both a live preview and a forced-preview.
My required preview is a part of my spam prevention strategy, and is intertwined with my issuances of nonces and captchas; neither of which are typically seen by humans.
So... why not take it to the next step? If JavaScript is enabled, and the browser is suitably standards compliant, why not automatically prefetch the nonce, captcha, and any warnings that may apply; and insert them (as well as a Submit button) into the page?
All I need is to have a data structure that contains all this information, in a format that is easy to parse. It turns out that I already do: the preview page itself. As it is XHTML, it is XML, and therefore amenable to XPath. And in many cases the information is already in the right form, it merely needs to be imported. In fact, it turned out to be ridiculously easy to implement. I trigger based on the first character typed into the textarea.
I’ve tested it on Mozilla and Opera. If you want to try it, you might need to refresh once to pick up the latest scripts.
Next up (with no particular schedule): live preview right on the comment page; and periodically polling of the comment page and the importation of any new comments that may have been posted while you are composing your comment, though this may only work properly on browsers that understand ETags when used in combination with XMLHttpRequest. Mark Nottingham has a series of tests that you can point your browser at.
Update: initial implementation of live preview and polling for new comments has now been deployed.
Might consider moving the live preview under the text entry box. With it on top (on the preview page) there’s a bit of line shifting around as text gets added/removed (specifically newlines, but I got a weird line shift when I tried using asterisks to bold something like this).
Alternately, narrow this column and put the preview to one side?
Safari doesn’t support the event to which you add a listener (DOMContentLoaded). The YAHOO! solution (at least, from their excellent YUI) is to poll until the content declares itself ready.
My guess is that it’s less worthwhile for you to figure out Safari support at this point than to put the time and effort into making it work correctly. You may be pleased to know that your SVG category identifiers look great in the nightly WebKit build I’m using though :)
My guess is that it’s less worthwhile for you to figure out Safari support at this point than to put the time and effort into making it work correctly.
I don’t have access to a machine that is capable of running Safari. I would be interested in knowing if this is a temporary restriction (i.e., they simply haven’t implemented it yet) or a permanent restriction (they have no intention of ever supporting that event).
You may be pleased to know that your SVG category identifiers look great in the nightly WebKit build I’m using though :)
Sweet! That’s in line with what I would like to see... those that upgrade to better and more recent browsers get a better experience.
I don’t have access to a machine that is capable of running Safari.
You can probably build WebKit QT if you’re willing to install QT4-dev. It won’t replace QT3 on Ubuntu. This will get you something good enough to check web content with, but it’s not yet a usable browser.
Anything that allows faster commenting while blocking spam has to be good.
I like Jon Udell’s contention that everybody should write in their own space (I on my blog, for example) and links it back. That way, my writing is in my controlled space, not yours.
Well, according to the WebKit project’s Bugzilla site, the support for DOMContentLoaded has yet to be determined (according to this bug I found: [link]) I suppose some voting would be beneficial.