Well, a lot of machines run on x86 these days, so that covers a lot of it. And you could pre-compile for a couple of other architectures, and have it pretty much covered. Linux and unixes in general make it ridiculously hard to distribute binaries, as opposed to Windows or Mac OS, but it's still possible with a bit of trickery. Avoiding dynamic libraries helps a lot.

A 1001th post would be a bother.

Random post: The test thread could use some linking in the notes at the bottom (what's the common nomenclature for that one?).

>>59-60

Details, please. Everything works for me.

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

I have always found that it's more difficult than one would think to implement features that will measure "popularity" in a satisfying way that isn't open to abuse in one way or another.

>>344 orz

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

>>244

Er, that's a feature, not a bug. That's how most GUIs act.

How about adding a link to 2ch in footer.html called "2ch mode"?

The "Entire thread" link on the thread page is missing a "/" at the end.

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!

http://wakaba.c3.cx/test/sanitize.pl

> Also: I just noticed that "¦" in tripcodes will work correctly but turn into "�U" through the cookie on /soc/ but not on the sandbox.

This might have been worded a bit akwardly. What I meant was: Tricodes work fine with ¦ on both the sandbox and /soc/&/sup/, although the latter boards will strangely turn the ¦ into a U? after the reply button was hit.

How about adding a link to 2ch in footer.html called "2ch mode"?

>Most admins probably don't get point of the secret string anyway, and asking them to put in several is just too annoying. In retrospect, I'd like to add a second layer of hashing to these, but that'd mean breaking secure trips AGAIN.

You could take the route that MrVB (I think?) did and generate the strings on first run? openssl, /dev/random, perl's random as last resort. In almost every case you are going to get a better random string than most people will supply, and if they want to change it they can. Or only have them generated if they are not supplied.

Honestly, when people care so much about anonymity they can put up with the changes required to ensure it.

> some other trickery

I smell JavaScript coming in about >>90-120

>>9
That's an option, you pick which one you want.

ugh "More options..."

too much clickable elements! and it doesn't even do anything (Firefox 1.0.7 here)!

out! out!

> people like admins might prefer to use them

but they have capcodes now...

>>148

>5) Seperation of sage et al from the email field to something else...

This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.

>2) Have the string to sage and fusianasan defined as a constant in config
>3) A specific string for ID:Heaven instead of anything in the email field

As I mentioned above, this would better work if they could be modified within each template in the list of string variable definitions.

>4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?

I like this one, as far as saving name and e-mail inputs go. I occasionally browse 4-ch at school, and it'd be nice for just an option to clear cookies when you're done and don't want anyone else to use your name, e-mail, and deletion password.

What the hell is RENZOKU?

P.S. >>151 is RMS

>>201

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

> Also: I just noticed that "¦" in tripcodes will work correctly but turn into "�U" through the cookie on /soc/ but not on the sandbox.

This might have been worded a bit akwardly. What I meant was: Tricodes work fine with ¦ on both the sandbox and /soc/&/sup/, although the latter boards will strangely turn the ¦ into a U? after the reply button was hit.

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.

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

Suggestion / Request

Making "More options..." an option in the configs.

Seems sensible, when you already have the ability to turn off WakabaMark as a board admin. Also, it will make me stop whining (a bit).

| stays |

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!