Thinking about my function, why would it need to return an error.

There are only two kinds of strings in the world. Those with unclosed HTML tags and those without. The string "" is a member of the second group.

So the array returned by it should just be ([true|false], content), right? The empty post thing would be handled elsewhere already.

I still think we should disallow table tags altogether (sorry, ita).

I think we should ignore the problem until we see it happening once a week. When it starts happening that frequently, we should make the board either fix or reject such posts.

Thinking about my function, why would it need to return an error.

Right now, maybe not, but perhaps it will need to in the future. How about we change the boolean to an integer, where zero is success without change, 1 means success and the message was changes, and anything negative is an error?

I admit I've been skimming the gory code details, because I've been so excited that I could.

What's the overhead involved in opening unmatched closes as well as closing unmatched opens? It's symmetrical, it's the full problem, and it means that the table thing's not a problem.

Very easy for me to say, what with someone else writing the code.

Did t strike just get knocked out? I had a "strike" tag in my last message in Sunnydale Press and when I went back to check on it, the strike doesn't work -- though when I went into Edit mode, the formatted tags were still there.

What's the overhead involved in opening unmatched closes as well as closing unmatched opens?

We're already set up to do it, the problem is, where would you put the open?

Also, Jon claimed in Jon B "Buffistas Building a Better Board" Nov 28, 2002 4:17:40 am EST that even having matched <td></td> pairs outside of <table></table> would cause problems, so there's a little more algorithmic work to do to figure out how to handle such a case.

One idea I had was to throw a <table> right before a bare <td>, and close it after the </td>.

I'd open right before the close. Make an empty tag.

Connie, <strike> works for me -- if it's still in when you go edit, then it's being sent to the page. Anything disallowed is stripped server side ... I'll go look in Press and see what I see.

How about we change the boolean to an integer, where zero is success without change, 1 means success and the message was changed, and anything negative is an error?

Will do. That's the philosophy that gave me such error messages as "Missing resource error -39" I'm guessing. Not that it ever helps.

Just a note about strike, since I think Netscape 3 there's been a shortcut for it, just <s>, but that's not on the list.

If you can come up with a formula for fixing bad TDs, then bring it on, but I think it's harder than it seems.

One thing we haven't done is change this:

You may use HTML or quick-edit formatting.

to, say:

You may use HTML or quick-edit formatting. But be careful! Bad code -- links and tables particularly -- can cause big problems.

Another thought, what's the status of the long-link fixer function?

The next project in mind is the bad HREF thing.

Can someone come up with a formula for that which we can translate into a regex? Like what's the formula for:

<a href="blah.html'>test</a> [any bloody code whatsoever including none at all]

so that we can catch it?

That's the philosophy that gave me such error messages as "Missing resource error -39" I'm guessing.

Nope, it's the philosophy that reporting such numbers to the user might help that leads to you seeing them. I recommend we never do that.

Fair enough, but, speaking of that, what's the means by which we tell the user that their post had to be fixed?

When I post now, I just go back to the thread, and not necessarily at the page which contains my post.

What's a polite, technically elegant way to tell people "your post had bad HTML in it and we've fixed it for you?" without disrupting their posting/reading experience or embarassing them in public?

Perhaps we could add another link like "edit" and "delete", perhaps "errors", that could lead to a page where we describe what the errors where and how they were corrected.