Pony Request: Fix Live Preview Bugs

August 28, 2008 11:03 PM

WYSINWYG: Live Preview ≠ Actual Post.

¹ renders as a superscript 1 in Live Preview, but displays as ¹ in real life.

Are there any other such bugs that should be reported? Please report Live Preview bugs in the hopes that a pony be birthed.

posted by five fresh fish to bugs at 11:03 PM (25 comments total)

Live Preview ≠ Actual Post.

FAQ: My HTML seemed to work in the live preview but don't come through correctly. Is this a bug or intentional?
posted by mathowie at 11:06 PM on August 28, 2008

I don't know what more to say about it -- we're talking about some inline javascript preview versus sophisticated server-side filtering and it's been impossible so far to tweak one to match the other.

If any javascript wizards want to look at the source and figure out a way to strip all the same things we strip on the server-side using a thousand lines of regex, we're open to changing it, but for the time being it mostly works for basic HTML and it's the best we can do.
posted by mathowie at 11:08 PM on August 28, 2008

I have a hard enough time arranging the ~80 standard symbols on my keyboard in a way that makes sense after I hit post. You had to get all fancy on us.
posted by iamkimiam at 12:37 AM on August 29, 2008

Is the server side code up somewhere? Maybe with some tests that it passes? Even just the tests and the expected output would be enough.
posted by jmhodges at 12:45 AM on August 29, 2008

At this point, could it be simpler to just allow stuff instead of filtering? You allow pretty much full unicode.. is that a major reason why your filtering is complicated?
posted by Monday, stony Monday at 1:35 AM on August 29, 2008

Full Unicode is not allowed - named, not numbered entities are allowed. Those have been used to spoof text & make it run - backwards? right to left? vertically? I forget.

For superscript, did you try ¹, or copy & paste it? Just to check: ¹ works in live preview. Oh, wait: Did you hit the Preview button? Did it work there?
posted by Pronoiac at 2:29 AM on August 29, 2008

The pastebin for the next line of this comment. Paste it in & look at the live preview. Posted, it looks like the following:
(If ¹ = ¹ this got botched.)
Oh - the translation of ¹ to ¹ happens when you hit preview. When you post, it goes from ¹ to ¹, because that's how the browser renders ¹.

This is actually a good thing, because previously, previewing was destructive. You'd hit the preview button, but have to go back & post from the previous page or face possible html trainwrecks.

Pardon if this is incoherent: I woke up when it cooled off a bit, & man, preview is just ... not right.
posted by Pronoiac at 2:56 AM on August 29, 2008

I WISH TO REGISTER A COMPLAINT!
posted by stavrosthewonderchicken at 5:06 AM on August 29, 2008 [1 favorite]

'ello Miss.
posted by SpiffyRob at 6:58 AM on August 29, 2008 [1 favorite]

y_{o^{u w}il^l re^gret ^this.}
posted by JaredSeth at 7:43 AM on August 29, 2008

The simplest solution would be to make live preview, instead of the current client-side javascript, an ajax call that called the server-side filter on the text, and then rendered that in the live preview area. Then you'd have the exact same input going through the exact same filter.
posted by orthogonality at 7:55 AM on August 29, 2008 [1 favorite]

Full Unicode is not allowed - named, not numbered entities are allowed.

¹ is a named entity. & works. < and > work. But not, strangely, ¹ ... an entity that would typically see a lot more use than the other entities I mentioned!

I don't understand why named entities would be stripped at all.
posted by five fresh fish at 8:02 AM on August 29, 2008

Let me try that again, only cheating for proper display:

The translation of ¹ to ¹ happens when you hit preview. When you post, it goes should go from ¹ to ¹, because that's how the browser renders ¹.

In this case, something is broken with ¹, because the ampersand's getting escaped.

This is likely partially due to something that fixed a bug where if you hit preview then post, the posted item might not match the preview.
posted by Pronoiac at 9:12 AM on August 29, 2008

( . )( . )( . )
posted by mds35 at 9:22 AM on August 29, 2008

Well, the triple-tit tags are still working.
posted by mds35 at 9:22 AM on August 29, 2008

¹ should be working on comment preview/post now. Thanks for the extra info Pronoiac, the digit in the named entity was throwing off our server side filter.
posted by pb at 9:53 AM on August 29, 2008

orthonganality, I would agree with the Ajax call. And a whitelist is definitely better than a blacklist, and still non-trivial to write.
posted by jmhodges at 9:56 AM on August 29, 2008

4 years of physics and I just misspelled "orthogonality". Nice.
posted by jmhodges at 9:58 AM on August 29, 2008

Wouldn't that mean the server would run the entire filter code with every keystroke? That would cut down my Metafilter addiction, since the site wouldn't be usable anymore, but I suspect it wouldn't be the most popular solution you could invent.

Personally, I tend to think we should ignore Live Preview altogether, and use the Preview button. That used to be destructive, but it isn't anymore. It gives much more accurate results. Ever since pb fixed the quoting logic there, I've had no complaints about the Preview function at all. You get back exactly what you started with, and you get a perfect representation of the final render. I don't really get why you'd want to use anything else.
posted by Malor at 10:52 AM on August 29, 2008

Ah, right Malor, I forgot live preview was per character. I only look at it before I post.
posted by orthogonality at 11:59 AM on August 29, 2008

it has long been known that live preview is neither.
posted by quonsar at 1:12 PM on August 29, 2008

I think it’s preferable in nearly every case (save for strict X[HT]ML processing rules) to use the real character, not an entity. This is admittedly difficult for some characters all the time, for most characters nearly all the time on Windows, and for many characters some of the time on Mac. For tricky cases I Google the character and copy and paste.
posted by joeclark at 2:07 PM on August 29, 2008

¹ is fixed?
posted by five fresh fish at 6:33 PM on August 29, 2008

Awesome, ¹ is fixed! Thanks so much.

To bring a response back from MeFi: "No, just ^{before and} after. No "small" needed, and no big PITA."

Sticking the <small> in there reduces the line-spacing irregularity that would otherwise occur.

The quick brown <sup>1 chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell.

The quick brown <small><sup>1 chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell.

The quick brown &sup1; chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell. The quick brown ¹ chased the howling minions of hell.

Not only does &sup1; look better, it's less work. At least when I remember to use it.
posted by five fresh fish at 6:38 PM on August 29, 2008

...and, yah, I supppose if I could remember my convoluted extended key mappings, I could insert the character directly...

`¡™£¢∞§¶•ªº–≠«‘“æ…÷≥≤`⁄€‹›fifl‡°·‚—±»’”ÆÚ¿˘¯ ...damn it's gotta be here somewhere... œ∑´®†¥¨ˆøπåß∂ƒ©˙∆˚¬Ω≈ç√∫˜µŒ„´‰ˇÁ¨ˆØ∏ÅÍÎÏ˝ÓÔÒ¸˛Ç◊ı˜Â.

Or maybe it isn't on my keyboard. Huh.
posted by five fresh fish at 6:43 PM on August 29, 2008