When clarified like that, I lean towards on display. Then I can correct it myself, right?

I'm one of those people who never uses a preview option, even when offered. I make my mistakes for the whole internet to see, 'cause I'm too damned impatient to wait for a whole 'nother click-through screen. My dial-up is sometimes painfully slow. Of course, I don't want my mistakes to broke nothin', so it's all good.

I think I'd rather have the post fixed at the database rather than having to fix it every time it's displayed. That seems wasteful of resources.

I, OTOH, am pretty adamant about not wanting what I typed changed, if not by me or a stompy. It's a thing that transcends my resource concerns.

Here's the flow I'm imagining:

• Poster types a post and submits it.
• Post gets saved to a temporary variable and gets run through TidyPlus.
• If TidyPlus does nothing, post gets posted. End of story.

• If TidyPlus finds errors, it writes a suggested fixed post to another temporary variable.
• A page that looks somewhat like editpost.php is loaded. Near the top of this page is displayed how the Tidy'ed post will look. Below that is one or maybe two multiline text boxes.
• If it's one box, it could contain either the text of the original post or the text of the Tidy'ed post. The poster either makes changes to the post or (only if it contains the Tidy'ed text) accepts the changes as is and hits submit.
• Another option is to have two text boxes and two submit buttons -- one box and button with the original text and one with the Tidy'ed text. The poster could change or accept the text in either of the two text boxes, and then hit submit below the text box containing the text they want to post.

• If the resubmitted post still has html problems, the process begins anew.

If the resubmitted post still has html problems, the process begins anew.

The theory being that crap is never allowed through?

Exactly. Why would we want something posted that will mess up other posts or the entire showthread.php page?

Why would we want something posted that will mess up other posts or the entire showthread.php page?

We absolutely wouldn't.

I wonder, however, about two things:

1. We get caught in a user-controlled loop of no submission (admittedly, a really easy one to escape).
2. Before we can run tidy on it, we have to do the expansion from quickedit. I wonder if there's a risk of a combo of bad HTML entered by the users, and expanded quickedits that would give a tidy error, but not be easy to eyeball as a problem for the user -- see, we're not presenting the HTML that would be posted to the user to be fixed.

Okay, now I'm obsessing about #2.

1 isn't a problem because the user can always submit the Tidy'ed version as presented. I'll have to think on 2.

Once we get this figured out, I think we should start Tidying content. We could start with not allowing a post to be submitted if it contains two or more LOL's.

Okay, now I'm obsessing about #2.

Wow, it's like you are in a controlled loop and won't submit.

t ducks

Before we can run tidy on it, we have to do the expansion from quickedit.

Hmm. Do we? Unless something goes blewwy, can't we know that the quickedit expansion is going to be kosher?

If the resubmitted post still has html problems, the process begins anew.

The theory being that crap is never allowed through?

While this is nice, the thing I worry about is causing the user experience to be potentially frustrating. Sometimes we've had posters need to ask what they did that caused the problem, and if they were stuck inside a no-post loop, they might not be able to ask.

Exactly. Why would we want something posted that will mess up other posts or the entire showthread.php page?

Well, for me there's a difference between board-breaking errors and something along the lines of unclosed italics tags. One is significantly problematic and should probably be contained if possible, the other is merely inconvenient for as long as it takes us to get to it (currently, of course, and I realize we're trying to improve on this so we don't have to get to it, since they're almost always rote errors). For the former, I think it's fine to potentially frustrate the user a tad, so long as it preserves board integrity. But for the latter, I don't think it's enough of a problem to stick the user in a potentially recursive loop.