> The File field is almost never there.
...especially not when I've added a bug that makes it disappear. Where the hell did it go?
>>182
That's not what I meant. What I meant was: If people want to change keywords to something, let them figure out at appropriate places what this something should be. Whether it should be "down", "stay_down" or "stay_put" is not really a discussion belongs here, not at this point anyway.
The Futaba template is missing the "No File" checkbox next to the File field in the Post New Thread area.
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?
I hate that blue link next to the reply box! It looks ugly!
Also, there's no "Less options..."
Can't this be somewhere else but the post form?
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).
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.
>>74
The comma range separator is useful for anchoring a certain post range to the first post (ie, "1,-100"), but that's all I can really think of. Still, I appreciate such a degree of flexibility.
> For example,
Different boards having different settings does not at all touch the question whether the learning curve of sage="does not bump thread" is low or not. It's up to the admins to tell their users what a particular modification on their board implies for "sage" - hopefully in a more responsible way than on 4chan.
> Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess.
Why? Let people figure out things themselves, if they are so keen on changing their keywords. They can get together in their own webmaster threads and figure this out. I don't see why this should be solved here.
Of course I think this is a dumb idea in the first place. Nobody needs to know what fusianasan and sage are. Write a FAQ with two sentences about it and/or let your oldtime users tell newbies. Two frickin' words, and you people talk about it as if it were something like making up a new system of romanization!
> 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.
That's a bit too much. You want to talk about sage and fusianasan in the comment field, not trigger it with it.
I suspect you are joking here, though. Design is about what you can take away and still remain optimal conveniency/efficiency on the user part, not about taking as much away as you are technically capable of.
> some other trickery
I smell JavaScript coming in about >>90-120
Nothing specific, just protecting against any possible future ones.
testing #`¦
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!
Random post: The test thread could use some linking in the notes at the bottom (what's the common nomenclature for that one?).
> The File field is almost never there.
...especially not when I've added a bug that makes it disappear. Where the hell did it go?
> 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.
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?
> Frankly, the combinations of many things into unrelated fields is a design flaw.
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.
> What if you want to use a name/trip and fusianasan?
Then just make one post with your name/trip and one with fusianasan and let your ID show up in both.
fusiansan is just intended for rare or special cases anyway, as is the whole subject of identification on anonymous message boards.
> What if your email address contains the string 'sage'?
Huh?
> What if you want to sage a thread, but have an ID still?
Then the board has to be configurated to just do that (it already can).
> why should I have to remember something so foreign?
It's rarely needed anyway. Also, these things are pretty easy to remember. "sage" and "fusianasan" is all there is, really.
Whoops, sorry. I read "close" instead of "permasage".
Permasage on filesize seems pretty silly, yes.
>>108
I don't think that restricting specific users' posting priviliges is useful in any way except restricting them from posting.
>>108,113
"fusianasan" is for when a user wants to prove that he is posting from a certain place (like a school, a company's network or a military base).
>>112
A keyboard shortcut for "reply" in Kareha or "submit" in Wakaba would be nice to have.
Well, you have your chance to try and abuse it over on the test page. Although the list of allowed tags there doesn't exactly match what would be allowed here.
Also, the point is to make the type of markup selectable, so you can pick WakabaMark or HTML or none at all.
No, that's just plain wrong. It is very much the job of the programmer to decide on such issues, and make sure they work consistently across boards.
rel=nofollow for internal links as discussed in http://wakaba.c3.cx/sup/kareha.pl/1127092367/
Currently, pruning by age is measured from the time of the newest post in the thread, so it wouldn't really work. I'm not sure if this is the best behaviour or not, but it seems it makes more sense to kill threads nobody cares about than to kill slow-moving threads just because they get old.