Weird posting error whilst using Safari 3.1.2 on OS X 10.5.5.

August 1, 2010 8:59 AM

Weird posting error whilst using Safari 3.1.2 on OS X 10.5.5.

In this thread, my comment looked completely normal in the posting window, but when posted, it became a strange jumble both times, as if I'd hacked my comment with a copy-paste error. The first time I figured it was my mistake, but the second time, it did the same thing even when I had re-written the completely borked part and double-checked to make sure it looked right. What's going on here?

posted by Sticherbeast to Bugs at 8:59 AM (19 comments total)

Sorry about the confusion. Any time you use < or > characters in your comment, the system is going to assume you're trying to write HTML. And if you're relying on Live Preview to see what HTML is going to look like, you'll end up disappointed. If you're doing anything out of the ordinary with those characters, you really need to use the "Preview" button. (If you click "HTML help" next to the comment form, we mention all of this and provides some hints for formatting.)
posted by pb (staff) at 9:04 AM on August 1, 2010

Ah-hah! That explains it. Thanks.

If the administrators could please delete my nutty double comments that would awesome please and thank you and I love you.
posted by Sticherbeast at 9:06 AM on August 1, 2010

The foolproof approach to using < and > characters in a comment (whether for >>>EMPHASIS<<< as in your case or more commonly to express a sense of <3 for something or to say that your budget is < $200) is to skip the actual angle bracket keys on your keyboard and to use named entities instead:

&lt; makes a < character
&gt; makes a > character

lt = "less than", gt = "greater than". (My dumb brain still produces the useless &rt; entity now and then because it thinks "left than, right than". Don't be like me.)

Note that among Live Preview's charms is its willingness to overlook a missing terminal semicolon on named entities. Your actual browser is not so forgiving. So if you type:

&lt

Live Preview will give you a nice looking bracket, but on post you'll see plain old &lt there. Be sure to mind your semicolons.

Note that because of how html gets parsed on the site, there are narrow cases where you can get away with a literal < character without the site eating a portion of your comment. However, taking that into account requires being fairly attentive to esoterica to very little general benefit, so just being sure to use your &lt; at all times is the saner move.
posted by cortex (staff) at 9:13 AM on August 1, 2010 [1 favorite]

sure, removed your second comment. But if you want to give it another go using HTML preview go for it and I'll remove your first comment. The trick if you want to use < or > in your comment as the characters themselves you need to write them as HTML entities. So < is written &lt; and > is written &gt;. It's not intuitive in any way, just something to memorize for any system that uses HTML.
posted by pb (staff) at 9:16 AM on August 1, 2010

or what cortex said.
posted by pb (staff) at 9:17 AM on August 1, 2010

And now that I destroyed that comment twice in the process of fixing it (you think dealing with named entities is a pain for commenting, you should try dealing with them in iterative editing passes), maybe I should add it to the mod explanations page on the wiki, since I think I write it about once a year already.
posted by cortex (staff) at 9:19 AM on August 1, 2010

Thank you for your efforts. To be honest, I'll just not use those symbols for emphasis in the future, and that is more than fine for me.
posted by Sticherbeast at 9:22 AM on August 1, 2010

Added non-borked version of the comment. Please delete my first comment, and once again, thanks for everything.
posted by Sticherbeast at 9:26 AM on August 1, 2010

And if you're relying on Live Preview to see what HTML is going to look like, you'll end up disappointed.

Can we fix this? Having live preview not match what your post will look like is almost worse than not having live preview (in this specific instance). User education isn't a very good band-aid for this bug.

I'll volunteer my help on the JavaScript front, if that would help. I'm a 20k rep user on StackOverflow. JavaScript is one of my specialties. I imagine the JS preview code just needs to be fixed up to match the server-side filtering code better.
posted by Khalad at 10:14 AM on August 1, 2010

Thanks for the offer Khalad. There's no way to fix this that I'm aware of. The Live Preview is simply doing a straight innerHTML of whatever someone types into the form. Running our server-side filters on every keypress would cripple our server. Everything is in ColdFusion, and it's not very efficient.

If there's a good JavaScript HTML filter out there, maybe we could hook something up that is similar. But using our actual server side code is out of the question. Writing an HTML filter from scratch is out of my expertise.
posted by pb (staff) at 10:35 AM on August 1, 2010

So not only is there a way to fix this, but Khalad made good on his offer to help by reverse engineering our server-side HTML filters into a pure JavaScript prototype here: MetaFilter Live Preview Filter. This is some amazing work.

There is one slight difference from the current Live Preview. The filter doesn't make something HTML until there is a complete tag. So if you're writing HTML by hand, you'll see your brackets escaped at first until there's a full tag. I think this is much better than our current Live Preview because it'll be much easier to spot coding mistakes. Anyway, take a look, try it out, and post here if you spot any problems. We have some testing to do on this end, but if everything looks good we're about to get a more accurate Live Preview.

Many, many thanks Khalad. This is great.
posted by pb (staff) at 7:54 AM on August 3, 2010

Great job, Khalad!
posted by Sticherbeast at 8:07 AM on August 3, 2010

 x <>

That code there doesn't work right in the new preview. Stuff inside <pre> is still swallowing less than characters. It also didn't close right and the preview flew to the right outside the preview box.

It doesn't quite look right in the current preview either (extra vertical whitespace).

I know <pre> is a bear but it's really handy for code discussions.

posted by chairface at 9:30 PM on August 3, 2010

...sigh...
posted by chairface at 9:30 PM on August 3, 2010

Looks like your sample code was mangled. Would you mind sharing your test case? Might be worth sharing over at Pastebin since the forms here aren't working for it.

We're not planning to support anything new with this Live Preview, so any problems sharing HTML code using HTML are still going to exist. That is frustrating when you're trying to answer a question about HTML over at Ask, but that's a small percentage of questions so we haven't felt like it's worth the maintenance involved with creating a system specifically for sharing code.
posted by pb (staff) at 10:22 PM on August 3, 2010

It looked something like this http://pastebin.com/3cuUiUz8. <pre> is tricky and I'm probably not remembering how to use it right. In any case, that code renders different in old preview, new preview, and in actual posting.
posted by chairface at 10:26 PM on August 3, 2010

ah ok, thanks. It's always going to be a problem to use greater than and less than characters in a place where those characters are used for formatting. So it's not <pre> that's the problem in this case, it's the fact that we need to treat all text as HTML. And we can't count on that HTML to be valid.

The good news is that your example is clearly mangled in the new filtered Live Preview, so you'll know it won't work before you post.
posted by pb (staff) at 11:14 PM on August 3, 2010

Okie doke, I fixed your example, chairface. Thanks for that. Although by "fixed" I mean I made the live preview match how MeFi handles that markup. It still looks completely mangled, but at least it's mangled in the same way. :-)
posted by Khalad at 7:35 AM on August 4, 2010

That's all I can ask for. Thanks.
posted by chairface at 7:40 AM on August 4, 2010