Heh. Should have specified the states I was referencing... I certainly didn't mean california. colorado and washington (off the top of my head) have been labeled by Obama as "will not prosecute", and although the confidence we can put in this statement is questionable, it has yet to be contradicted (to my knowledge, if I am wrong please let me know). This certainly isn't amazing, but it is a step in the right direction, along with most of the current weed legislation.
As far as the guidelines bit, sorry but... nothing you mentioned is in there. I felt the need to correct your comment and was annoyed. I didn't consider it off-topic, just useless and confusing to the uninformed. Have a nice day!
He's using rails, so he can use SASS (which personally I like better than LESS, but they accomplish the same things). Manifest files are better though, because with LESS's @import, you might import more files than you actually want. I believe you also have the recursive import issue, just like C. Manifest files give you more granularity by existing outside of the actual stylesheet.
It looks pretty well thought-out, which is a big +1 when I'm framework shopping. However: use pushState/replaceState! Or at least fix your buggy back button. Your hash-based navigation totally breaks the back button to a point where I can't believe you shipped this.
First of all, can't tell you how awesome it feels to get a response from someone working on the library.
Your fix won't work for me unfortunately, changing id's to classes in your CSS inherently changes the "weight" of the selectors, which can cause the wrong CSS rules to be applied (especially if you have old rules hanging around from iterating on your interface a couple times).
Another thing that you guys might have missed about why writing IDs are shitty: They pollute window's namespace. If I have an element with id "narc", then window.narc returns that element. Which can lead to confusing JS situations.
Anyways, glad to hear you guys are moving ahead and improving your library! I will try it out again in a few months, love the work so far.
I was really excited about react, until I heard the loss of #id selectors. To me this comes off as extremely dirty, since this limits your actual CSS (id's are useful for layout-based static elements (#big-logo), or containers for similar layers (#modals)). QA departments that test web apps also love #id selectors, since they don't have to waste their lives unwinding proper nested selector syntax, which is brittle anyways. Otherwise react seems like a perfect complement to Backbone. I ended up using Backbone.Marionette, which is a lot of boilerplate but solves the nesting problem in a flexible and thought-out way.
I assume React wants to optimize its subqueries for instant DOM lookup (I believe they calculate the ID based on ancestry, and ID-based lookups are O(1)). Why not use a better technique like maintain your own lookup hash, and store data on the actual JS objects representing each DOM element. I prefer not to cringe anytime I look at my markup :(
Eh, updating page at end/cancel easy enough. I use this approach to animate a page scroll:
1. Animate #transform using jquery's animate (which doesn't work out of the box unfortunately, you have to use a custom #step fn)
2. Install "capture" event handlers on document.body that will cancel the animation, reset scrollTop to the state of the transform, then reset the #translate to 0 on #scroll or #touch (so we don't "fight" the user scrolling)
3. .. animation runs, calls my "complete" callback which uninstalls the event handlers, sets #translate back to 0, and updates scrollTop. Unfortunately there is a noticeable "glitch" here if the user tries to immediately further interact with the page.
#2 is optional (OP's implementation didn't handle canceling anyways). I'm sure there's a jquery plugin to do this and degrade to scrollTop on non-webkit browsers.
Updating scrollTop is a pretty slow way to scroll on some browsers. Have you tried animating `transform`? That gets you hardware acceleration on webkit at least
Ugh. I am usually a DF fan, but this article is riddled with worthlessness:
"The design of iOS 7 is based on rules."
iOS 6's design certainly was not inferior due to lack of rules
"a Z-axis of layers organized in a logical way"
That's the basis of every UI.
[/rant]
Anyways, here is a summary of the article, for those not interested in digging meaning out of it:
1. Blurred transparent layers are cool and useful (Ubuntu has known this for years now).
2. Apple is finally making software whose elegance and design captures the essence of their hardware design (yay!). You get that same "just works" feeling (like sliding shut a heavy, mechanical dead bolt with no resistance).
[/summary]
Here's my review of Apple's iOS6 UI, if anyone is interested (note: I have used and loved Apple products my entire life):
1. Finally catching up to the flat UI trend. +1
2. LINKS instead of navigation buttons? I'm not a fan, but okay, as long as the "tappable" area is the same.
3. LINK instead of [SEND] button in Messages? Why?
4. Safari's icon is so ugly
5. Mail's icon is so ugly. Wtf!
6. The "Control Center" screenshot looks hideous on that backdrop, darken the background of your modals!
7. wtf@the default homescreen background! I don't even remember what that trend is called.. bokeh? bokah? Hang on one sec, gotta take this, the early 2000s are calling.
8. LOVE the look of the new bottom bars
9. LOVE the switch to helvetica neue with a skinny font weight
10. hate the < > buttons in safari, why are they so huge and freaky
11. Mail looks awesome, as does Weather and Messages
12. Weather needs a bit more contrast
13. LOVE safari's new address bar
But overall good job apple, it's a huge step to take and looks like the first iteration will go well.
As far as the guidelines bit, sorry but... nothing you mentioned is in there. I felt the need to correct your comment and was annoyed. I didn't consider it off-topic, just useless and confusing to the uninformed. Have a nice day!