Wedge

btw, I voted to put the buttons on Mars because I could. Where''s the red space dust? :P

Well the color was due to the fact I forgot to apply the same css to .unlike_button, which is done now... Sorry :)
The reason why the buttons don't share the same link color is only due to the fact that I was trying to set an opacity on the icons, and the button text is inside the same stuff so basically they also inherit the opacity, so I had to decrease their brightness to keep them readable. Which OTOH makes them very dark once you hover them... There isn't a "good" solution to fix these, I just like the opacity play too much to get rid of it... :-/

It's looking good!! ;)

The 'silently like' option will require a schema and query change.

A lot of this stuff is going to be based on how it looks when we actually try it, you know. As long as the like button can just be clicked without having to hover or wait or anything, it'll probably work out OK to have unliking be less prominent.

Bump for attachment broken issue.

Schema change yes -- adding a new field where you store whether the user wants to remain anonymous, but that's all..?
(We could also simply add a single field with a serialized array of options, like in the members table...)

I think it might be an interesting thing to do, though. I never discussed it before, but see it this way: let's say you want to Like a NSFW picture and your boss is on the same forum as you are... You won't "like" it because you'll be afraid he finds out you liked it. So, hiding your name from the Like list seems okay to me...

Apart from that -- well, we could also have an option to Like something without showing it in your user news stream (or wall, or whatever), and that's a one-time function so it doesn't need a database entry.Yup.
I'm still not 100% sure about whether or not I'll keep the note classes with likes number etc... But at least it's a solution that would be perfect on mobile. (Perhaps I should just show the 'You like this' text next to it, and then hide it entirely on a media query test.)Very oddly -- it seems like your file is done like this: it's missing the first 30893 bytes of the original file, then you get the rest of the file, then at the end, it adds another 30893 bytes which seem to be repeated from offset 52078 of the original file (i.e. it adds them again)... Make what you want of it, but I'm at a loss myself.

I think this is a fairly unlikely situation to actually want in the core, personally. I could see it being a plugin though.It would have to be a change to the query/processing to hide it from others that aren't you, whilst including you in it but the schema change is simply the extra column.

I'm not sure, there is such a thing as having too much stuff.Try it :)I uploaded it, saw it was corrupt, removed it, reuploaded it and still corrupt (the same way). Very weird. But I didn't find any of the normal PNG block indicators, I couldn't find the IHDR sector end when downloading the file again...

Maybe base Like privacy on thoughts privacy?

The thing is, it's going to make it much slower and heavier to store, for something that is essentially a minor feature. If someone wants it for a plugin, fine, but I think doing anything more than what we have is a bit much... (though I'm not disputing that we need a few things, like being able to turn it off, being able to get a list of likes)

I in no way said it was a good idea :-P

I would suggest a "Silent Like" in a way that this action doesn't make a page reload. For example, an user can hit the Like button (or link) but it won't refresh the entire page till a "manual" refresh, in simple terms, don't refresh automatically when hit the like button.

Could be a good idea, similar to the thought behavior.

Implementing it without requiring a reload is something I meant to do just didn't get time to write the JS for it.

Note that all suggestions of 'silent like' are completely different to what you're suggesting.

(Still working a lot on Wedge, it's just that I'm so overwhelmed by the amount of changes to commit, that I'm postponing my next commit every time...)Alright...I'm not sold on either solution, actually... :-/Did you look into this bug in the meantime...?

Back on topic -- I rewrote the minimenu CSS/JS code to fix a detail that bothered me at low-res (iPhone etc) -- if a minimenu overlaps another minimenu's parent entry (like the Actions button overlapping the following post's author name), the parent entry has priority z-index so it shows up on top of the menu. This is because of a complex implementation to ensure the parent entry wouldn't be 'hidden' by the menu showing up behind it.
I tried to fix it by doing a reverse walkthrough of all umme/acme tags, like this:


(Isn't this some cool JavaScript? :P)
I would then create the minimenus dynamically to use the parent item's z-index minus 1. Worked perfectly, but I noticed it didn't look great on my iPod -- most notably the menus tended to disappear and then reappear as they were animated. Possibly due to the great amount of processing power this requires... (Yay for mobile devices.)

So I threw away that solution, and instead decided to .clone() the parent into the minimenu and position it on top of the parent. Fixing all z-index issues immediately, meaning I didn't have to specify them any longer (which makes it easier to style stuff, too.)
And again -- it works nicely. Well, it didn't at first, but then I got rid of the padding animation implied by .show() (by replacing it with a longer .animate() call[1], but thanks to gzipping it's actually much shorter than the original code). Except for my iPod, again.....!!!
Now, the animations work correctly, but I can't seem to get the font sizes right. I can fix it by setting paddings and sizes manually in the index.iphone.css file, but it also means that some other devices are bound to show issues with this...

So, two possible fixes:
- Finding a 'correct' way to clone the parent entry perfectly. (This would *probably* imply setting the minimenu to be a child of the parent, rather than a child of the body. I'll try this next but it's like that it's going to create other issues.)
- Getting rid of the current minimenu style. Instead, implement them to look just like the 'normal' menus, i.e. an arrow below the item, and nothing surrounding it. Basically, doing what John did in the first place when he suggested re-using our menu style but I wanted to look into more animation styles.

I need opinions.

1.	I should also point out that because of the lack of padding animation, it doesn't 'feel' as nice an animation as it used it, but at least it's clean. This can probably be fixed by animating the list items at the same time as the parent ul... But I'm lazy for now.