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.

It might close it too early, however, if they intended to write "<b><i>Bold and Italic</b> rules!"</i> They'd get "<b><i>Bold and Italic</i></b> rules!" Not a problem for italics, but a table might get messed up that way.

Edit: much editing.

If people don't want their tags closed too early, they should close them right. I'm very unconcerned with trying to get an individual post presented as the user wanted it. I'm very concerned with not messing up subsequent posts, or the page as a whole.

I like the array of tag references, with a modification that when you find a closing tag, search the list backwards for an open. If you find it, remove it. If you don't, ignore it, possibly bitching to the poster about their bad HTML.

At the end, put in a close tag for every open tag still in the array.

From John's analysis of the page that broke editing, it looks like the author used mismatching quotes, single at the start and double at the end. I think my suggestion of counting quotes in a tag would solve that, since it would put in a closing single quote before the >. The post would still look wrong, but it would be editable.

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

So once it closed the c, the opening one would be deleted from the table, even though it didn't get to where the poster wanted to close the c yet? So then the order would be t /c t /a t /b t /a t /c , I think.

Tables do seem to be what cause the worst damage, while things like italics and sizes just create annoyances. Would disabling tables and making them a quickedit thing make it better, or just more confusing?

I think a quickedit table (table, td, tr, th plus attributes of width and colour and alignment and stuff) would be more confusing. I'd lean towards disabling them completely, except no! I don't want to! I like and use them pretty often.

So I'm pretty torn.