Text Art's description about auto-linking URLs and >> references is redundant. Not a bad solution with the layout, though (hiding the menu behind "More options..." still bugs me).

Ah, there was an XHTML error in the cutesy capcode, and of Safari won't handle XHTML correctly and die on errors. Gah. Fixed.

> Pruning set to furthest-back instead of oldest.

I don't like this one. You just have to continually age a topic (until it hits the permasage treshold) in order for it so survive a long time. Normal users might have good reason to ignore simply it, though...

> Size limit instead of post number limit, maybe?

Sounds good.

> I was thinking of setting the default behaviour to never permasage or close threads.

I guess I don't have a strong opinion on this one. As long as the values will be customizable, I don't really care, I suppose.
Also: I just noticed that "¦" in tripcodes will work correctly but turn into "�U" through the cookie on /soc/ but not on the sandbox.

I thought fusianasan was supposed to be a mod-only function to weed out bad posters. And what would be the difference between revealing the persons's IP and his ISP's domain?

>>99
I didn't mean to include Forcenick in there, sorry.
Adding to that, however, how about forced sage for specificed IPs? It'd make for a great slogan: Remember kids, tripcodes and aging are privileges, not rights!

>>16

What browser are you using? I think I've tracked down the problem, and it's most likely a browser bug. The ancient Firebird (not fox, even) version I tested at work had the same bug (character set issues in the escape() and unescape() functions). It looks like your browser also doesn't follow the spec for how they are supposed to work.

> forced fusianasan

that seems kind of evil.

> how about having a third party create extensions for those browsers and freeing up the real estate on the actual page?

What's with this obsession on removing the CSS options? It's a single line, and some of us find it useful.

Real estate? Scroll down.

>>336
IMO minimalist web applications like Kareha should only focus on core content/functionality and leave the inconsequential presentation options up to browser extensions so that each user can tweak them to his whim. That's why I was pushing to offload the CSS selector to an extension.

>>337
Here's a better example, I think. Even if we can't remove the excessive side borders, is there a way to at least have rounded corners?

On formatting options: I think >>338 fails to understand that leaving the formatting options up to each individual user is a good thing by all means. Besides, they are absolutely necessary to the interface and core functionality, just like the Name and URL fields are. Preview functionality, on the other hand, should be implemented in an extension.

I think the issue that people have with the formatting options is that we don't have a Japanese counterpart to blindly model it after. Since we're going at this on our own, nobody is quite sure how it should be done. I'd like to see how it turns out on mode_image (if you feel the need to include it at all). :)

>>48-50
First of all, I don't believe it would make bumps more valuable in any way. People bump threads all the time with worthless replies since most don't even know what "sage" is or means or what it is good for. They will simply continue to do this, no matter whether the sage function is changed in this way.

Even at this stage, years after its introduction to a major western userbase, people are still clueless about the main basic functions of image- and discussionboards in the Futaba/0ch style. There are some signs of improvement, but they are rare.
I doubt people would be willing or eager to learn a new, different behaviour at this point in time.

The only real change is what >>50 points out (though I want to mention that even that point is mostly misunderstood: if people want to protest against a certain thread, they should post as many sage posts as it needs to get permasaged (although it's arguably counterproductive, considering the default prune behaviour of imgboards). If threads are still bumpable and trolls find that they have been flamed with a sage, they will just bump it once more). And I don't think that's enough to justify a pretty major function change.

> You mean requiring SQL software, or just making backwards-incompatible changes that would screw up old threads?

I mean, needing to alter the table that is already in the database. I don't want to try to do that any more than I have to, as it's pretty hard to get right in a database-independent manner.

> Are you only referring to flooding and spamming, or also trolls and flamewars?

Yes, only flooding and spamming. Trolling and flamewars are not a problem one should use banning to try and solve.

> Finally, out of curiosity: how much of the functionality in the .js file do you think could be properly implemented into a new or existing perl script?

Well, if you serve up dynamic pages, you can do the form-filling on the server, but that's about it. The rest is dynamic stuff.

> people like admins might prefer to use them

but they have capcodes now...

Thought of something else: can there be the ability to separately place a title on a board and what the head <title> element says?

Like "Music" for the header but "foolchan - music" for the title in the browser window.

>>336
IMO minimalist web applications like Kareha should only focus on core content/functionality and leave the inconsequential presentation options up to browser extensions so that each user can tweak them to his whim. That's why I was pushing to offload the CSS selector to an extension.

>>337
Here's a better example, I think. Even if we can't remove the excessive side borders, is there a way to at least have rounded corners?

On formatting options: I think >>338 fails to understand that leaving the formatting options up to each individual user is a good thing by all means. Besides, they are absolutely necessary to the interface and core functionality, just like the Name and URL fields are. Preview functionality, on the other hand, should be implemented in an extension.

I think the issue that people have with the formatting options is that we don't have a Japanese counterpart to blindly model it after. Since we're going at this on our own, nobody is quite sure how it should be done. I'd like to see how it turns out on mode_image (if you feel the need to include it at all). :)

PS. What's "Raw HTML"?

Argh, beaten and >>n isn't even implemented. orz

>>210

monospace font? like this?

Also, for multiple board installations, use symlinks to allow you to keep just one installation of the main code files.

Wow, >>243 sure looks like shit in Safari. What the hell? Looks right in Firefox, though.

>>71
forgot to add that turning the CSS selector and Admin functions into drop-down menus and moving them to the right side of board and thread title headers would remove that top bar entirely on the front page.

Anyway, test with |

>>178
There will always be pranksters around. This is probably a good example on what matters to trust tripcoders more than anonymous contributors.

Trivia: Here is a list of 2ch kopipe to fool people into using fusianasan:
http://ansitu.xrea.jp/guidance/?fusianasan

>>201

Yeah, no, maybe. Using secure trips for capcodes also adds extra protections against accidentially misspellingyour capcode and leaving it open to attack.

>>38
Sorry, I guess I should've worded that more clearly. I was referring to the ability for users to delete their own posts. It's counter-productive to discussions when a user deletes his own post and a quick replier later quotes or references it. It also encourages users to be lazy with posting, because they can always go back and hide their mistakes.

>>69
The sage seems a bit off...

http://wakaba.c3.cx/sup/kareha.pl/1114201493/l50

Or use some sort of filter to replace them characters with underscores on upload.
This offcourse for files that keep their original filename.

Additionally, I'd like WakabaMark to be fixed somehow.
I don't know how, though. You know my resentments.

Finally, thanks for your fine work throughout all this time.
It is appreciated!

A trigger for turning wakabamark off and one for forcing a monospace font

>>112
We already have the ID function, so why do we need such an egregious compromise of anonymity (and security) like voluntarily exposing your own IP?