heisann

sdsd

Wow, thank you so much for your detailed, carefully constructed comment!

That is, DIVs and TABLEs are illegal inside P.

Of course! D’oh! I should have known that’s what was going on there.

BTW, you regexp catches “<script” but it fails to catch “<Script”, “< script”, “onevent=’…’” and “href=’javascript:…’”.

True. It was clearly not a robust solution. And I agree that using WordPress’s (or any other blog platform/CMS’s) parser would be better. I guess that’s one of the reasons I call this “Really Simple.” :)

You should mention, that for almost any event there is a corresponding oneevent(). Why is this so important? So that people know this is not a special case. I hate libraries with unnecessary special cases.

You are correct here, too. I will update the entry to include that information. It might also be worth noting that the syntax for the “one…” events might be changing when 1.1 is released.

Hmmm… I don’t get it. The first line gets rid of any \n. So the second line doesn’t see them.

Ah, you’re right again. If I switch the order, though, I can prevent the appearance of multiple (3 or more) line breaks. that’s what I had intended, and it worked at one point, so I must have switched them around at some point inadvertently. Good catch!

(And you may have to replace any “\n” with “\r?\n”. And there are Macs too…)

I can do that. It works fine on my Macs with just the “\n”, but there might be some edge cases that don’t work.

Why is a “\” preceeding the “<” ? Another issue of your highlighter?

Nope, must have been a typo.

Thanks again, Mooffie, for leaving such an excellent reply! I really appreciate the suggestions.

Thank you for creating this useful website.

I initially created the preview box immediately after the textarea, still within the paragraph, but Internet Explorer 6 did not like that one bit. The preview text wouldn’t appear [...]

Because block-level elements are not allowed inside P.
That is, DIVs and TABLEs are illegal inside P.

[...] but I can’t see how there would be any more of a security issue here than, say, if someone had the Grease Monkey Firefox extension installed.

I believe you’re correct. I’m using Opera, which allows me to easily edit-and-reload any page I see.

BTW, you regexp catches “<script” but it fails to catch “<Script”, “< script”, “onevent=’…’” and “href=’javascript:…’”.

Mary said:

[...] it would be easy to use jQuery to pass the comment preview to a script, which could run KSES (the markup cleaning script WordPress uses) on the comment preview, and then include it in the page source.

Marry, this is an excellent idea. But not only beacause of some possible security hole.

This idea, of round-tripping to the server to get the displayed HTML, has an important advantage:

HTML is not the only format for user input. I’m using Drupal, where lots of other “input formats” are possible. Users can use Wiki, AsciiMath, BBCode, Tex, Textile, SmartyPants, CSV, Opus, whatever, and the browser itself doesn’t know these languages.

In fact, HTML is not even WordPress’ input format! WordPress’ input format is: filtered HTML. That is, not all tags are allowed. I could type a TABLE tag here and see it in the preview box, but WordPress would throw it out anyway…

And I believe WordPress also converts URLs into links and smilies into icons. You don’t see this in the preview. In other words, your preview is very “low fidelity”.

So Marry’s idea is good for CMSs like WordPress too.

Fortunately, jQuery has a “onefocus” event handler, which, as the name makes painfully clear, is executed only once

You should mention, that for almost any event there is a corresponding oneevent(). Why is this so important? So that people know this is not a special case. I hate libraries with unnecessary special cases.

We’re going to make everything inside the comment textarea appear inside the “live-preview” DIV as it is being typed.
[...]
for this type of job. I used keyup

My Opera, for some reason, doesn’t trigger this event for “special” keys like BACKSPACE, ENTER and… SPACE. Word has it that BACKSPACE does’t trigger keyup on IE either (sorry I can’t verify this claim).

This problem doesn’t seem to occur for the keydown and keypress events. Are these two events triggered before or after the textarea’s content is modified? If before, Mary’s timeout idea would solve the problem.

$comment = $comment.replace(/\n/g, “<br />”);
$comment = $comment.replace(/\n\n+/g, ‘<br /><br />’);

Hmmm… I don’t get it. The first line gets rid of any \n. So the second line doesn’t see them.

(And you may have to replace any “\n” with “\r?\n”. And there are Macs too…)

replace(/(\&lt;\/?)script/g,

Why is a “\” preceeding the “&lt;” ? Another issue of your highligher?
BTW, if you use “\x3C” instead of “&lt;” users won’t have to change anything after they paste your code.

Rick

id like to try to implement this technique to display a live comment preview, complete with the commenter’s information that would be inserted INTO the post itself (ie: name, time/date stamp, etc).

i love jQuery more and more.
:)