In the grand scheme of things it probably doesn't matter much as long as the units are clear, and it's easy to convert between representations.
Converting anything to HSV is a pain, so I think there should at least be RGB primitives that a color library can use instead of JS. 
Of course not. I agree.
Thank you! I just needed to get the word out, Snap! should be more unique and people should stop feature requesting things that Scratch has just because Scratch has it, they should have other reasons to have it other than that.
Yes, I know Snap! is supposed to be like Scratch, but Scratch is slowly taking over Snap! little by little, and then I stop and think; "why can't Snap! have its own features, more things that are unique to its own website, and not just Scratch's features?".
Snap! has plenty of unique features. I think the unique features well outweigh the Scratch ones at this point.
Scratch has always been an inspiration for Snap!, so it's not really taking over. When Snap! does differ, it's usually because the Scratch feature has some strange behavior that Snap! hasn't implemented, or because the Scratch feature is easy to recreate with Snap! blocks.
So I agree on the principle that Snap! should be unique, and that it doesn't need most of the Scratch features that are requested. Not the point that it isn't already unique. 
I think you don't know the history well enough to say that. I'm not trying to put you down; you can of course say anything you want, but we started out (with BYOB, the earlier version) actually modifying the Scratch source code, so we were exactly like Scratch apart from a few new ideas. (New to Scratch, not new to computer science.) I think the important thing we showed is that just one new idea, if it's well-chosen, can generate a world of possibilities. Namely, our idea was procedures as first class data. That's what the grey rings are about. With that idea, we could generate new control structures such as FOR and FOR EACH and MAP.
Not that anyone would do this in practice, but it turns out that if you have grey rings and CALL, and nothing else, you can invent numbers and lists and all the arithmetic operators!
The Scratch Team knew all this as well as we did; they just didn't (and still don't) think first class procedures are important for their audience. Eventually we stopped trying to convince them and just went our own way. Since then we added sprite inheritance, hyperblocks, and a bunch of other things not in Scratch.
It's not a big surprise that someone who just recently discovered Snap! after having learned Scratch thinks first about Scratch features when asking for things. I think I vaguely remember a certain person asking for missing Scratch features in the costume editors. :~) Eventually, people learn what makes Snap! special.
One thing I recommend to new users is to look at the Examples projects you can get to from the Open dialog, with the big Examples button on the left. Don't just run them; read the code. That's a quick way to learn about some of our unique capabilities.
I asked for a missing feature from Scratch for the Costume editors (the zoom ability) here, you already saw it!
Ok. I'll check that out. I meant like how, for example, the key pressed hat block is not supposed to detect mouse events, btw.
Definitely want those angle issues fixed. My scratch project actively deals with them. (Yeesh :P)