> Would it maybe make sense to make a separate thread creation page?
Considering that the ratio of users who start new threads to those who don't is pretty small on most message boards, I think it does.
A seperate page could also be used to put a more visible disclaimer/set of rules, as a seperate page with a different layout is likely to generate more attention from the user. Stuff that can be put there also wouldn't clutter up the frontpage.
I don't think this is an urgent matter, though.
> The error page in mode_message should more closely resemble that of 0ch (complete with "ERROR!" title).
Signed. And the style selector on the error page is pretty useless.
Forgot this one:
The general functions of imageboards do not seem to be clear to most people that eventually come around, the influx of total newbies is still big. Many neither know what sage is, how to properly reply to threads, what tripcodes are, etc.
Because of that, I believe it would be good to include a default link at the bottom of the unordered list at the bottom of the new thread form that links to http://wakaba.c3.cx/docs/docs.html#UsersGuide
>Why should it?
Because it's one of the two requirements for creating a new thread, and it's a lot more important to have a well-defined topic than to fill in your name.
>It's more convenient if you want to start a new thread, but for those who don't it's one more form to have to scroll by.
Good point.
>Any idea why?
I dunno. I guess it's just another one of Futaba's countless layout quirks.
> I'd like to have the interface reduced to what is absolutely neccessary
That's why there is a "More options..." link, instead of putting the controls there on every single thread everywhere.
Here's a fun little game for you all!
I'm looking into adding support for using HTML markup in addition to WakabaMark, but since most boards use XHTML, I can't just let through any old HTML, and most people can't write well-formed XHTML. Also, I don't want any cross-site scripting going on. So I've tried to write a piece of code that takes any horribly written piece of HTML, sanitizes it by removing all tags and attributes that are not an approved list, checks the attribute values, and turns it into well-formed XML.
Now I'd like to see if anyone can break this. The objective is to get some Javascript onto the page, or making the page break in Firefox (or any other browser that parses XML strictly), or otherwise causing trouble. Have at it!
Wakaba:
0ch-PHP had this nifty feature where if it was a certain "high bandwidth" time of day, then you couldn't view the whole thread.
Hm... that is kind of useless on a worldwide forum, huh?
But there should still be an option to keep people from viewing more than 100-200 posts, as an emergency way of saving bandwidth.
> partition to kill secure tripcodes
signed
> add functionality for multiple uploads in one post.
I think this was decided against before.
> 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.
> Did you ditch customizable capcodes?
No, I removed the dumbass capcode I put in as a demonstration, because I don't like capcodes.
> Using "◆" as the default tripkey character.
I dunno, I always thought that was a kind of big and annoying symbol. Especially when it's so close visually to the question-mark-in-diamond marker some fonts use for characters they don't support.
> How about placing the Formatting menu to the left or right of the "File: " field? I'd also like to see WakabaMark changed to its real name (Markdown).
The File field is almost never there. Also, WakabaMark is similar to, but not the same as Markdown. There are significant differences that make them incompatible (since Markdown is designed to be used when you know you're using it, but WakabaMark tries as best as it can to not do unexpected things if you don't know about it). I might add optional support for real Markdown at some point.
> In Pseud0ch, post numbers should be the same size/format as the rest of the header text
I tried, and it looked much worse than the current solution. Besides, post numbers in Kareha and 0ch aren't the same, since they're clickable here.
> PS. What's "Raw HTML"?
Pretty useless. I'll probably remove it. It's HTML input without turning newlines into <br/>.
> Oh, and "AA mode" should be changed to "Text art mode"
Maybe just "Text art"... hmm.
So, as Xee is almost done, and I'm mostly waiting for external contributions, I decided it was time to start working on the Legendary Next Update for Kareha and Wakaba.
Only problem is, it's been a long time, and I've forgotten most of what needs to be done. Most of it is mentioned SOMEWHERE on the board, though. So this is your chance to pipe up with your pet feature request, or if you're feeling really helpful, to dig out some old posts that mention things that need fixing.
Hop to it!
The point is to make a portable file, so you do not /have/ to compile it on the host. Statically linked lets you use libraries that the host does not have.
Sure, doing it in perl is an option though.
One of the things I did when I modified and restructured the order of functions in post_stuff() was add specific error messages for each non-comment field. Would this be considered superfluous?
Thanks for the links at the top. Previously, I had to search for those threads over and over again if I wanted to find them.
> What about a(n) (optional) preview page?
I've been considering that, but it's a goddamn pain to implement. It'd be pretty useful, though. Also, it could include the spell checker someone requested way back at the beginning of time.
>>157
So the functions need to be hardcoded to a post element one way or another? If I wanted to, let's say, create a template for gazo-box or Shiichan (both use checkboxes for sage), I'd need to slightly modify kareha.pl to check that new checkbox input instead of the Link string input?
An interesting limitation. Thanks for explaining.
About permasaging/deleting after a certain thread filesize is reached: would this be the same as a limit on the total number of characters in a thread? Or would we also include WakabaMark formatting, hyperlinks (including navigation), name/date/title headers, reply boxes, and non-Unicode characters in the formula?
>>158
Chances are that most if not all major/fundamental changes made to Kareha's core scripts will clash with the philosophy of most people here (including WAHa), and they won't care for them anyway. There really aren't all that many big-bang end-user features left to be implemented in Kareha before it loses its minimalist charm.
P.S. Reminder for >>85
What does "fusianasan" mean?
I was browsing through some old threads and now they're all gone. :(
> Better to have a tick-box and explain to people why it is useful. Or an option for it.
Yes, an option. Because I think a tickbox is horrible.
This is a widely used system. There is a very low learning curve here. sage = does not bump thread when replying, that's all there is to know. People can then figure out why it is useful on their own.
And personally, I think sageing should be encouraged more (since the perceptions on it have been pretty much ruined by 4chan). So it helps that it stays in the E-Mail/Link field instead of being purged from the tickbox each time like Shiichan does (interestingly, 4chan's Futallaby does also purge "sage" if written in all minor letters).