Getting back to inconsequential nitpicking: I find the "___ image replies omitted" phrase to be a bit redundant, and for one it confuses me as to whether or not those image replies are separate from text-only replies. How about simply calling it "images"?
How come this is now the by far biggest thread on this board?
Maybe it's because I'm posting useless replies like this one!
test1
>>91 Ohshi-, time paradox!
Thanks for reminding me that I need to fix the CSS for the captcha!
>>110
Happened to me, too, sometimes it goes black, sometimes it goes white. Screen reappears if you just scroll up a bit but it's still strange.
Also, wouldn't making capcodes even more prevalent be considered A Bad Thing®? If anything, the role of capcodes should be minimized or altogether eradicated, in favor of ninja moderation.
Another question: would FUDGE_BLOCKQUOTES be considered deprecated by now, or are there still CSS styles out there that require it?
> I don't understand the argument for OH NO ANOTHER BUTTON MY WHOLE LIFE IS RUINNED crowd
It's all a design & layout question. I'd like to have the interface reduced to what is absolutely neccessary, esp. since I do not think many people really want to even bother or bother very often with the whole markup question.
> The replacement will be an option to select the default markup for a board, which makes much more sense overall.
I agree, this seems to make the most sense. I understand the "More options..." will not be showing up on boards with fixed settings, so I'll shut my mouth from now on. Apologies to all who I've been bothering.
...and admin posts that override all board/thread restrictions (ie, bumping a permasaged thread and possibly even posting in closed threads).
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?
Congratulations to 82.94.251.206!
So the subject line will look like this:
[username]<><>[unix timestamp from now]<>[content of comment box]<> <>[IP]
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.
>>275
Heh, I thought you had disabled it manually.
>The File field is almost never there.
Right, and when it isn't, the Formatting menu can still reside on the same line.
The error page in mode_message should more closely resemble that of 0ch (complete with "ERROR!" title).
What does Thorn have to do with Kareha? Thorn's counterpart is Wakaba.
Anyway, the version of Shiichan on world4ch is bust. It's not a case of feature versus feature here, Shiichan simply doesn't work. It's not worth comparing until it doesn't break regularly.
If Shii were still working on it might be different, but Shiichan is effectively a dead project which incidentally has a closed and broken version working on world4ch.
I can't reproduce this on Firefox 1.0.4 nor Safari on the Mac, but that ancient Firebird had a similar problem (but even worse).
Anyone else? Try post with a | in your name.
> Is it intentional that thread links without a trailing slash
Uh, I was wondering the same thing. I'm not sure. I guess I should fix that.
test2. looks good!
>3) was about a string to trigger ID:Heaven, not a constant for the Heaven part (which is already configurable)
That's what I was referring to also in >>154 (S_NOID being the theoretical trigger string for ID:Heaven).
Concerning localization: there are certain compromises with input triggers that must be made in order to maintain interoperability with Japanese users coming from 2ch/Futaba. They're not going to care about a system where "sage" and "fusianasan" (in Roman too I'm guessing, can someone confirm this?) don't work in their respective fields. In effect, 2ch set a standard of usability that we need to follow if we want to build a bridge between both communities.
On the flipside, I think there should also be a secondary set of trigger strings that would be more coherent to Western users and universal to all Western boards. Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess. With Shiichan's death, Kareha stands unrivaled, and setting these strings in stone would ingrain them in the culture like "sage" and "fusianasan" have been in Japan. Thinking very optimistically, if a Western BBS site should grow into something large enough for 2channers to strongly take notice of, they would pick up on these triggers and possibly make their own concessions to implement them in 0ch.
What they should be is yet to be determined. Unfortunately, they'll probably have to be pretty dull in comparison to the witty botanical references and word puns in 2ch and Futaba.
>I don't think so, not in these cases. What's the alternative? Having a different field for fusianasan, a new checkbox for sage, etc.? That's just cluttering up the interface.
Then why not simply boil it all down to the comment field, with trigger strings for inputting the name, e-mail, sage, ID:Heaven, and fusianasan? You can get a lot more minimal with the current interface.
>Huh?
He meant saging a thread just because a part of the actual e-mail address contains the word "sage."
test1
I fixed the Javascript a bit, and uploaded it for these boards. Try shift-reloading to get the new code, and see if cookies work better now that I'm not using cargo-cult code.
How about listing what dmpk2k or you have done already?
Oh yeah, regarding the CSS selector: HTML dropdowns aren't styleable, and will look like shit. I'll look into using some other trickery for that, though.
>>196
Actually, a solution to >> links with static pages is to simply make them reference a certain point on a certain page number for that thread (ie, http://wakaba.c3.cx/sup/1129153864/index2.html#197).
Well, there are some issues to consider here:
In the end, people actually enjoy the 0ch quirkiness. I know I do. I know about designing good interfaces, but there's something fun about an interface that is a little bit quirky, as long as it doesn't get in your way, and these things don't.
> To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?
I find the "1. Thread title (1000)" format much more readable in the post list. And for the main titles, I don't see any value is putting the position in there. That serves no discernable purpose.
> 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).
They already do, but only if there are enough posts in the thread for this to make sense. Or, try a short range like 23-27 to see it in action.
> 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.
I've been wondering about the justifications for which navigation links should go where. 2ch has it pretty much worked out, I'm sure, but I don't quite see why there should be a "First 100" at the top but not at the bottom.
> Change "Del" links to widget buttons.
Would be very ugly. Those buttons are big.
> In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu?
I was meaning to do that from the start, but there was some problem with gettting it right. I forget what exactly.
> 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).
Squeeks would prefer to have a separate script for admining. I'm not sure which is the best approach here.
> and would something like this work (given that all boards share the same root directory)?
> >>>>sup/1129153864/1-100
> >>>1129153864/1-100
Maybe, but I don't see the value in adding code for this, given that you can just paste the URL in there.
> 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).
The front page gets lots of hits. This would drive up CPU usage something fierce.
> Oh, and please bring back MAX_LINES.
I still don't think it serves any useful purpose.