it's not closing a table tags.
It is now.
You tell me what tags, I'll add them -- does it actually make sense to tell it to close TABLE, TR and TDs?
'Hell Bound'
Do you have problems, concerns or recommendations about the technical side of the Phoenix? Air them here. Compliments also welcome.
it's not closing a table tags.
It is now.
You tell me what tags, I'll add them -- does it actually make sense to tell it to close TABLE, TR and TDs?
You tell me what tags, I'll add them
Since I'm 3000 miles from home, I can't check the code and give you the list, but didn't I post a list upthread somewhere?
Ahh! I found it:
<a> <b> <i> <u> <ul> <ol> <li> <p> <br> <strike> <table> <tr> <td> <th> <font> <pre> <code>
does it actually make sense to tell it to close TABLE, TR and TDs?
Yes, but tables are tricky. As I pointed out a while back, the mere existence of a t td t /td pair within a post, without a t table t /table pair around them, causes havoc with the tables on this page. So even if you close an open t td tag, we'll still have problems.
I still think we should disallow table tags altogether (sorry, ita).
didn't I post a list upthread somewhere?
The list I'm using is exactly that, with the table tags taken out.
The only way to reliably check table code would be with a proper parser, that checked syntax, not a brute-force method like mine.
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?