What have you used tables for on the site, Liese? Or is it ita's user-stats tables you like? I like those too.

I haven't. I like other people's tables. I like the ability to table when information isn't easily represented in lists or other happy-html formats.

I used to table, but it was only for the long dead leather pants taxonomy. Which is now faq'd, and therefore irrelevant to this discussion.

Edited to say that, of course, this is all just opinion, and therefore certainly subject to the hive mind. If we consense on killing the tables I'm fine with it. I'm just voicing an opinion in favor of having the tables.

I cannot table.

But I like ita's tables.

t /not able to follow intricate discussion above

I agree with Liese up to a point. But that point is

Advise user that their code is ugly and to fix it please

which implies "prevent them from posting".

I'm a bit unhappy about presenting users with that kind of negative experience.

I'd be more happy with a "fix it, post it, tell them 'by the way,it needed fixing' please check" message. And perhaps a hint about how to get HTML advice, who from, where to post a question, that kind of thing?

And any solution that I have in my head, I'd have to say, involves chucking extra closing tags in at the end of the post, not inserting them at the right point.

To do that, you'd have to read the whole post into a data structure, like a hash of arrays or array of hashes or something like that, it seems to me. That's what those parsing modules do.

OK thought on bandwidth?

There's still a kind of bug whereby if I have closed and reopened my browser since the last time I was here, my bookmark for the Message Centre doesn't work.

It goes to message_center.php, but redirects me to index.php, so there's two extra page hits, and index.php is quite big compared to Message Centre.

As a user, I would never ever look at the front page -- I don't need to.

I agree with Liese up to a point. But that point is

Advise user that their code is ugly and to fix it please

which implies "prevent them from posting".

I'm a bit unhappy about presenting users with that kind of negative experience.

LIese's point was mine. You don't have to point out what the problem was, just that there was one. Dectecting the presence of an HTML error (as opposed to it's exact nature) is fairly simple.. And as to giving the user a bad experience - I dunno, having my stuff posted with an error is, to me, worse.

More to the point, people don't have to use html in a post. Not that they shouldn't - but if they do, I don't think they will have a problem with being unable to post until they do it right. I mean it is not like people are going to a full fledge set of html - with header, body, footer title, menus bars , tables, and three fonts all at once. Most HTML posts will have a little tiny bit of HTML. Knowing that there is a problem should be enough to enable people to fix it.

And I don't see you why you need to diagnose, let alone fix the problem. Identify that there is a problem. Don't let them post until it is fixed. This does not turn you into an interface facist. It is really quite a fair division of labor. And, I honestly believe fairly easy to do. You are looking for mismatched tags (uneven numbers of {b) and {pre} and so forth, plus table commands outside of a table. The only tough thing to catch is improperly formed hyperlink tags.

Actually, you can give them somewhat of a helpful message, if you really want. If you are catching mismatched tags you will know whcih tag(s) are mismatched (italics or whatever). You will know if table tags are outside of a table. (becase that is a sperate test.) And you will know if there is a misformed, properly closed hyperlink) because you will test for this as well.

From the user side, I would much rather get a message that says I messed up my coding and to try again, than have my messed up coding mess up a whole thread.

I only disagree with, let me see, yes, everything you said, Gar!

Dectecting the presence of an HTML error (as opposed to it's exact nature) is fairly simple.

I'm not sure that's true.

Don't let them post until it is fixed. This does not turn you into an interface facist.

I believe it does.

I would much rather get a message that says I messed up my coding and to try again, than have my messed up coding mess up a whole thread.

My suggestion was not that we allow the error to go through, but that we fix it automatically, just not necessarily in the way that the user will like.

For instance, someone wants to post one line in a huge font.

They put

<font size="7">

into the posting box.

Then they type, let's say

</fnot>

at the other end of their line.

Then they go ahead and post another couple of pars.

My proposed script wouldn't need to figure out where the error was or how to correctly fix it. It would just say "Message Posted. It had an unclosed FONT tag by the way, (link to HTML help) which we closed for you, but you'd better check out what it looks like!"

And the post will indeed be all in a huge font, and they'll feel suitably embarassed, but the whole of the rest of the page won't be. There'll be a little island of brokenness.

I only disagree with, let me see, yes, everything you said, Gar!

So long as you understand that I'm right, and you're wrong, that's fine John. {smile}

>Detecting the presence of an HTML error (as opposed to it's exact nature) is fairly simple.

I'm not sure that's true.

Well you've been taking part in the debate over which algorithm to use - of several you agree would work. The exception is one I've admitetted - malformed <a href > tags.

>Don't let them post until it is fixed. This does not turn you into an interface facist.

I believe it does.

tistaintistaintistain... I'd be curious to take a head count on that.

My suggestion was not that we allow the error to go through, but that we fix it automatically, just not necessarily in the way that the user will like.

So, the error is still going through - just in a way that does not break the board. Not posting also does not break the board - and gives the user a chance not to have "the error fixed in a way they won't neccesarily like". I'll bet fifty persian that most users would prefer not having the message posted to having it fixed in a way "they won't neccesarilty like". And not posting is easier for the developer too. I understand the general principle you are operating from, that letting users complete their tasks is first priority. I think this case is an exception, and an exception from the user point of view, not just that of the developer.

If I had a post with messed-up HTML, I'd rather that I get a chance to fix it before everyone else sees it. If it gets posted, then I edit, then several people will have read the messed-up post and moved on the the stuff below it in the thread before I get a chance to fix it so that it says what I want it to.