(unless it's a mandatory part of the post message function)

Whatever the solution t clueless , please don't let it be this.

OK a possible solution: check for bad HTML. Don't try to correct. If the HTML is bad simply refuse to post, and give the user an error message. You catch, put the burden on the user to fix it.

This could be unclosed tags, unclose quotes of various types, and too many quotes of the same type in an < A Href > tag.

For me, the fact that "post message" takes you back to the thread serves as the preview function. I narcissistically reread all my posts, and don't have broken HTML for longer than it takes me to edit.

Problems with A: it won't work correctly with crossed tags,

Problems with B: no maintaining of order, because it's a hash.

Could there be some sort of compromise between these? (Note: I'm really not so good at figuring out whether things can actually be implemented or not, or at figuring out how much of a pain it would be.) Like, instead of checking if the last tag in the array matches the closing tag it finds, check each tag in the array, starting from the last one. When it finds the right one, remove it, and shift everything below it up. Then add whatever's left in order. (Ugh. I don't explain too good.) Like, if the post contained
t strike Crossed-out text t i crossed-out italic text t b crossed-out italc bold text t /i crossed-out bold text t /b crossed-out text

It would make the array as [strike, i, b], then remove the i so it's [strike, b], then remove the b so it's [strike], then get to the end of the post and add the t /strike .

Could there be some sort of compromise between these?

Very sensible, how about if we do both?

Then if method B says everything's OK, but method A says it isn't, method B wins, because we know that at least every tag has a closing tag and the post, no matter how mangled, is self-containedly mangled and won't cause problems downthread.

The edit link *did* work, Jon. It's that the edit form was broken by the bad HTML.

I think way back I suggested a modified A. When you're popping tags off the stack, if you meet one that's unclosed (a t /b when you're expecting a t /a for instance, add the t /a )

Which would have us err on the side of too many closing tags, instead of too few. Safe, except if we throw in an extra t /table we're in trouble, aren't we?

I think way back I suggested a modified A.

Oh yes, sorry, I should have said it was based on your suggestions.

When you're popping tags off the stack, if you meet one that's unclosed (a </b> when you're expecting a </a> for instance, add the </a> )

I think I get it. It is Monday morning though.

The (pseudo-) code would be

if (closing-tag is found which matches last opening-tag){
pop off the last opening tag}

but also

if (closing-tag is found which doesn't match last opening-tag){
insert matching closing tag}

Thinking aloud: how would that work with the crossed-over tags? Where exactly would we add the closing tag? It would have to be right before our unexpected-closing tag, wouldn't it?

But then, if there are crossed tags, it would mess up everything else. Like, if something started with t a t b t c then ended with t /a t /b t /c , it would end up ending with t /c t /a t /c t /b t /c t /b t /a because it would keep inserting those t /c 's because c is the last opening tag, then it would close the a and b again because they're still left there. You'd end up with a whole mess of closing tags.

My assertion with that is that too many closing tags are less bad than too many opening tags. Except when it's a table.

And how do we cope with too many closing tags anyway?

Hil -- with your scenario, it would only close the t c once -- since it's only open once.