live preview

March 2, 2012 8:49 PM

There is definitely something wrong with live preview

So I wrote this bit of HTML in a comment:

"Wasn't everyone <b>shocked, shocked!!!</a> about Limbaugh when he mocked Micheal J Fox and claimed he was faking it? "

In a comment just now and, of course, the </a> tag didn't actually stop the rest of my comment from being bold. However, it looked fine in live preview. I don't know if something recently changed, but up until the past few days Live preview has been working fine for me.

posted by delmoi to Bugs at 8:49 PM (19 comments total)

the problem here is trying to close a bold tag with an anchor tag. maybe you did that the first time as well?
posted by elizardbits at 8:57 PM on March 2, 2012 [1 favorite]

Nothing has changed on this end. Malformed HTML is always going to be a wildcard, there's not much we can do about that. As we mention in the FAQ: "The live preview seen below the comment forms shows a real-time approximation of your comment, but does not go through the extensive text filtering done on the server side."

You need to use Preview to see how the comment is going to look, Live Preview will be an approximation. And when malformed HTML is involved, that's especially true.
posted by pb (staff) at 9:03 PM on March 2, 2012

Nothing has changed on this end. Malformed HTML is always going to be a wildcard, there's not much we can do about that. As we mention in the FAQ: "The live preview seen below the comment forms shows a real-time approximation of your comment, but does not go through the extensive text filtering done on the server side."

Hmm... Yeah I guess I must have just never noticed that before. Maybe you could give a warning if tags aren't balanced HTML.

(The string "test <b>test</a> test " is enough to see the bug.)
posted by delmoi at 9:11 PM on March 2, 2012

The problem is doing that test in real time—we can't parse the HTML as fast as Live Preview shows it to you. In fact, we aren't doing any sort of real HTML parsing. We're doing some simple pattern matching that is a bit like parsing HTML, but it's not enough for us to throw up warning bells if something is wrong.

To see the comment how it's going to appear on the site we have the Preview option which puts the text through the filters that we use before it's posted. I'm sorry your comment was borked and Live Preview didn't catch it, I know that's frustrating.
posted by pb (staff) at 9:14 PM on March 2, 2012

What about a live nude review? They always seem popular for some reason I can't put my finger on (or so the bouncer and then the officers emphasised at the time).
posted by Abiezer at 11:51 PM on March 2, 2012 [8 favorites]

I think elizardbits and hippybear are misunderstanding. As I understand it, the poster means that the whole rest of the post wasn't displaying as bold in the preview, and since he never actually closed the bold tag, one would expect it to.
posted by lollusc at 12:51 AM on March 3, 2012 [1 favorite]

The "pattern matching" explanation pb gives makes sense (and is super interesting). I would think this problem would be solved if you previewed for comments that have a lot of mark-up, just in case.
posted by Phire at 11:12 AM on March 3, 2012

Most of us don't post often enough that this could be considered a bug.
posted by cjorgensen at 12:23 PM on March 3, 2012

As I understand it, the poster means that the whole rest of the post wasn't displaying as bold in the preview, and since he never actually closed the bold tag, one would expect it to.

Right, and the live preview shows it as having been closed, even with the incorrect tag on the end, as you can see when you c&p the following and live preview it yourself:

(The string "test <b>test</a> test " is enough to see the bug.)
posted by elizardbits at 12:45 PM on March 3, 2012

It's not really a bug if you're doing bad HTML and a parser can't interpret what you intend vs. what you actually code.

Well, I always assumed that the live preview was just doing something like setting innerHTML to the text in the comment box or something like that (with just newlines added I guess), so that if you included extra markup that isn't allowed in comments it would get stripped out when you actually posted. Instead it's somehow actually adding tags which aren't actually added when you post.

Actually, didn't it used to be the case in the early days that if you didn't close a post it would actually stay open for the entire rest of the thread until someone else closed it?
posted by delmoi at 1:18 PM on March 3, 2012

delmoi - just mark up using conventional keyboard shortcuts (cmd b, cmd i, etc. - the live preview balances your tags for you.

You can also link by typing cmd u.
posted by carter at 5:00 PM on March 3, 2012

It doesn't close your parentheses for you though ...
posted by carter at 5:01 PM on March 3, 2012

Actually, didn't it used to be the case in the early days that if you didn't close a post it would actually stay open for the entire rest of the thread until someone else closed it?

Yes I remember that.
posted by carter at 5:02 PM on March 3, 2012

delmoi - just mark up using conventional keyboard shortcuts (cmd b, cmd i, etc. - the live preview balances your tags for you.

For me at least I type markup just like I type any other punctuation. I don't really even think about it. This just happened twice recently and I thought maybe something might have changed, but that's apparently not the case.

Just out of curiosity, why don't you guys just use the raw HTML?

I checked to see if putting bad HTML into an element by setting .innerHTML would cause problems, and it's fine. This demo took just a few minutes to put together (took me more time to mess around with the stylesheets :P) .

And not only that, you can actually click on the preview and edit the text directly -- and any changes you make will be put back into the raw HTML as well. That would be a useful feature in live preview.
posted by delmoi at 8:48 PM on March 3, 2012

Just out of curiosity, why don't you guys just use the raw HTML?

We try to mimic the filters we use on the server side as much as possible. It's not a perfect match as you've found out, but for a large number of cases it works out fine. Most of the time it's better for Live Preview to match what's going to show up on the page.

You happened to hit a rare case where a mismatched tag looks like it's closed up to live preview. I'm sorry about that. It's not a perfect representation of the server side filter, but it's better to be close than completely off. Raw HTML would be completely off more often.
posted by pb (staff) at 9:26 PM on March 3, 2012

Well, you could also run the same regexes on the server side, before running the output through regular filters. That way, the final output would be much more likely to be identical.
posted by delmoi at 10:25 PM on March 3, 2012

It's not a simple regex we run in Live Preview, it's a bit more complicated than that. In a perfect world the two would be identical. It's something we can work on.
posted by pb (staff) at 10:36 PM on March 3, 2012

Yeah, you're right, we have the Live Preview HTML already on the client side. We could send the filtered version to the server instead of what's in the textarea. Definitely something to think about.
posted by pb (staff) at 10:44 PM on March 3, 2012

It's not really a bug if you're doing bad HTML and a parser can't interpret what you intend vs. what you actually code.

Well, to be honest it really is a bug. The live preview should ideally exactly match whatever happens on the server side, even—or perhaps especially—when dealing with malformed HTML. It's easy to make live preview work for correct HTML; it's much more difficult to make it work for invalid HTML.

I say this because I'm the guy who wrote the live preview code. I'm a JS programmer and so a year or two ago I offered to help beef up the live preview feature. I spent a few days reverse engineering the behavior of the sever-side ColdFusion scripts and tried to reproduce their behavior in JavaScript.

I fed a lot of very unusual HTML through the real preview feature and did my damndest to write JS code that would do the same thing. You can see all the test cases I came up with here:

http://john.kugelman.name/files/metafilter-filter.html

Point being, it may be minor, but let's not dismiss delmoi's bug report out of hand. Good code should be able to handle bad user input.
posted by Khalad at 8:43 AM on March 6, 2012