>>129

That form just looks wrong with no title or clear separator, though. I might put in a title that is not the exact same as the button, though. Any suggestions?

The board title is inserted by template.pl, and rules.html is included after it.

/-100 shows the first post two times.

>>63
Nevermind, the issues seem to have resolved themselves within the hour of the new version being uploaded.

More stuff:

To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?

And as suggested before, the navigation links on the bottom of individual thread pages should include "Previous 100" (ie, all posts before the first post in the URL) and "Next 100" (ie, all posts after the last post in the URL). Of course, this could get screwy if you're using reverse order and out-of-order posts in the URL, so I dunno how well it could be implemented.

The "First 100" link should also be removed from the bottom of individual thread pages, and there should be a link to to thread-list included below the reply box of each previewed thread on the front page.

Bonus:

Change "Del" links to widget buttons.

In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu? The same could be done with the Admin functions (appearing only after one correctly inputs the password), placing it on the right side of the board and thread title headers (this would also allow admins the convenience of deleting and permasaging threads from the front-page).

and would something like this work (given that all boards share the same root directory)?

>>>>sup/1129153864/1-100
>>>1129153864/1-100

P.S. When you mentioned serving dynamic pages in >>46, were you referring to individual thread pages? As I mentioned before, it'd be nice to make the front page as dynamic and flexible as thread pages when it comes to viewing options (via PATH_INFO).

>>305

Shift-reload already! Also, most people are familiar with "More options..." links and know when and when not to click them. I might see about styling it, though.

>>137
I'd advocate going for a separate interface a-la Wakaba, but it might be a bit too much to do for this release.

Also, maybe Easter Eggs like the Eternal September timestamp and others (if they exist) should be documented in config.pl.

Lastly, a question: who here finds enough use in the auto-expanding comment box to justify the annoyances when you click in or out of it?

GDLib for thumbnails: http://wakaba.c3.cx/sup/kareha.pl/1113869490/5

>>344 orz

>>151 It's all public domain, I believe.

Copyright only applies to the literal code, not to features, ideas, or algorithm. Patents do, to some extent, but that's not the issue here. Since I'm not going to write the exact same code, there's little they can do.

Test with ¦

>>255
By replacing it with AN EVEN DUMBER PUN!

Plus if you were to allow those tags in HTML, you should do the same for WakabaMark (which actually takes its cue from Markdown, so I don't see why it has a different name).

test

How about appending an estimated (at the time of thread creation) time of pruning to the first post's header, if pruning-by-age is enabled?

> 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.

Nothing specific, just protecting against any possible future ones.

> Red, bold thread filesizes displayed near the bottom of subpages?

I support this, especially if thread-closing by filesize should be implemented.

There are some inconsistencies in both the Blue Moon and Futaba styles, with regard to the size and formatting of text labels in the Create new thread and Reply form areas.
The spacing of the Create new thread title is off in Futaba, Headline, and Toothpaste.
None of the styles that utilize rounded corner borders have them in the Create new thread area.

rel=nofollow for internal links as discussed in http://wakaba.c3.cx/sup/kareha.pl/1127092367/

> He meant saging a thread just because a part of the actual e-mail address contains the word "sage."
> You know, like [email protected].

Well, then you are out of luck, aren't you? So you want to enter your E-Mail but cannot because then the post wouldn't bump then? Solution: Write it in the comment field, problem fixed.
There is no reason to change well-known keywords for this or even turn this into a frustratingly unconvenient tickbox/checkbox.

Oh, and "AA mode" should be changed to "Text art mode" so we won't be incessantly quibbling about the difference between ASCII and SJIS art.

>>63
Nevermind, the issues seem to have resolved themselves within the hour of the new version being uploaded.

More stuff:

To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?

And as suggested before, the navigation links on the bottom of individual thread pages should include "Previous 100" (ie, all posts before the first post in the URL) and "Next 100" (ie, all posts after the last post in the URL). Of course, this could get screwy if you're using reverse order and out-of-order posts in the URL, so I dunno how well it could be implemented.

The "First 100" link should also be removed from the bottom of individual thread pages, and there should be a link to to thread-list included below the reply box of each previewed thread on the front page.

Bonus:

Change "Del" links to widget buttons.

In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu? The same could be done with the Admin functions (appearing only after one correctly inputs the password), placing it on the right side of the board and thread title headers (this would also allow admins the convenience of deleting and permasaging threads from the front-page).

and would something like this work (given that all boards share the same root directory)?

>>>>sup/1129153864/1-100
>>>1129153864/1-100

P.S. When you mentioned serving dynamic pages in >>46, were you referring to individual thread pages? As I mentioned before, it'd be nice to make the front page as dynamic and flexible as thread pages when it comes to viewing options (via PATH_INFO).

I think it'd be a better idea to have some kind of load-balancing/distributed server cluster approach, like what dmpk2k was working on for Wakaba.

>>236

mode_image copies the Futaba/Futallaby HTML style and uses the same CSS, so yeah, it should be, and no, it won't be.

>>238

This would need writing to yet another file, and it also makes it less obvious how to get the same secret on several boards.

> people like admins might prefer to use them

but they have capcodes now...

WAHa, WAHa, it's a bug!

Pressed back after creating an error message in karaha (trying to reply to this thread, forgetting to type something in here), refresh does nothing!

From here on, this thread is about Kareha again:
↓

Well, I don't want to have to read posts without highlighting. It's annoying. Just for that, I don't want leave it off.

On another topic, a vote: I could make the secure tripcodes and other parts of the script that use the SECRET more secure by some small changes, but this would make secure trips change when you install the new version.

Good idea, y/n?