A new convert

I will try to counter some of your suggestions, and explain what's already planned for 1.3

I don't see the problem with cookie dependancy in itself, but yeah, a message telling whoever turned it off to activate it would be neat.

The markup, along with all CSS will be rewritten for 1.3, very much with accessibility in focus. The above things will be addressed, accesskeys removed.

What's wrong with XHTML?

Apparently, the new markup/CSS will be much more flexible, making it easier to integrate.

Will probably never happen, since once a protection is in there by default, it will be bypassed by every bot in a matter of days It will be easy to install your own protection though with the new extension system.

Sorry, don't get this one

Well, there's not really a reason not to do it. But it's not a priority because, let's face it, you don't create forums that often.

I thought having only one style installed removed the field?

AFAIK, would be very difficult to implement in an effective way, and PunBB is all about doing things fast

I hope that'll bring some clarity on where PunBB is heading.

EDIT: If you want to try out the latest of 1.3, you may hook up with the SVN (if you know how to use it). URL to 1.3 dev source: http://punbb.org/svn/punbb/branches/punbb-1.3-dev (Note that it's not ready for regular use at all, and we're not yet open for bug reports etc. of it)

People switch stuff off for a reason, telling users to stop doing that or arguing that "there's nothing wrong with cookies" is not a good solution.  Usually when I encounter a site that insists on cookies (or javascript) I find a better site, did I mention that I'm the obstinate type?

But the drawback of the alternative will probably be that a session ID will have to be stuck on the URL. This would degrade the currently very clean PunBB URLs, but if used only for clients that do not accept cookies I'd consider it a big plus.

I've participated on forums that employ at least 3 different sorts of board software, all of them work without me having to accept cookies. At least a routine should be used to check if cookies are accepted (by immediately reading it back), and the user informed that PunBB doesn't work without cookies if that fails.

Nice to know that development is continuing and that these issues were already known. Meanwhile it was not much work to remove the accesskeys from the current version.

Everything, or nothing, depending on your angle. This isn't a discussion for this board, my opinion on XHTML is documented here: http://www.spartanicus.utvinternet.ie/no-xhtml.htm

PunBB seems more vulnerable to spam bots than some other forum software (using CAPTHCA's for example). I'm not suggesting that there is a 100% effective method, but the amount can be drastically reduced.

PunBB not being the feature bloated software that most people go for, it seems to be appreciated by a niche market. I'm guessing that the resulting lower installed base doesn't make PunBB systems an attractive target to write the type of bot routines for that would be required to defeat the more sophisticated bot protection methods.

Not an option for me as a non programmer, unless there is an existing extension.

Sorry, don't get this one

PunBB places some type of user statistics info on one of the main user pages that I didn't find useful. It would be nice to be able to disable that through the administration panel, rather than having to cut it from the code as I did.

There you go again, arguing with a user about their choice. Not a good solution. My site development philosophy is to not rely on any optional technology, that includes CSS, images, javascript, cookies, Java, Flash etc. etc. The PunBB developers have made a considerable effort to produce accessible forum software with fine results. The reliance on cookies and the "switch them on then" or "what's the problem" response is therefore rather suprising. This isn't about catering to my particular quirks, blocking all cookies is not uncommon. While it may only be a single digit percentage of people doing this, as I've stated before I consider not relying on optional technologies a fundamental mark of quality authoring, figures don't come into it (even though a few percent most certainly matters a lot in my trade).

If the reasons in favor of a technology are bogus then adopting the technology is unwise, if only not to further the bogosity.

Certainly structural and semantic correctness is what it is really about, but HTML has the exact same features to express those. Btw, there is no XHTML1.2.

I'm pretty sure PunBB can be easily modified to use HTTP authentication, but you'd lose some stuff that is in the cookie =/

What kind of spam bot protection can be implemented efficiently while preserving accessibility?

If PunBB claims to be "Valid html" that tells you very little "Valid xhtml strict" however tells you a lot more.

I doubt even if you just include PunBB users anywhere near a single percentage of people completely block cookies. Its not a problem I have come across anyway.

Great to learn that the silent failing issue is being considered for a fix. I'd like to stress that I'd be quite happy if PunBB were to ask a user to allow cookies for a site if they are rejected initially. I'd also again like to mention that I do appreciate the currently clean PunBB URLs.

Perhaps my worry about being spammed will turn out to be unfounded. The current spam protection method of emailing a password to a user does create a bit of a barrier in itself, it requires users who try to avoid spam to trust the forum's administrator not to use the provided email address inappropriately.

For what it's worth I certainly appreciate the indentation, after a bit of experimentation the PunBB code is now an almost indistinguisable part of my site code.

Once again thanks for having done such a fine job.