Nickey Kolev

Heya Tom,

Great tip! It was a life savor that I stumbled on your post. And to add up, I want to point out a scenario I ran into, and moving actions from controller to route did the trick:

I've got a route/controller, which is using dynamicly rendered templates, based on the transition coming from. I have an action, which when finished, had to transitionToRoute to another route. On first load of the route's views, the action finishes fine and transitioned properly. But when I again open this view and hit the action (on this.transitionToRoute('route')), I got a 'Cannot use transitionToRoute on undefined'. Weird thing is that 'this' context was passed ok, but seems to be lost in the way.

After moving the action to the route, the transitionTo is now going as expected.

Cheers and thanks,
Nickey

All is perfect, BUT(T) - <IE8 is a pure evil.. so you always need additional code, based on the device width OR browser. So which could preferable - <!-- IE --> hacks with inline/additional file css, or media queries, so you get the modern browsers?

That is if I have indeed understood your tip though ;)

The dials are a work of art! :)

Thx for sharing!

Thanx for sharing this! A while ago I was working on a team, using sencha for their app. Sencha does rely on flexboxes for all panels and boxes, and it's one sweet ui model.

I'm following css flexbox for a while, but I think for the next 1-2 years it could be used primary for web ui, as long as ie10 gains full penetration (and I don't know what will be the case with ie9 and flex..).

@gagege Thanks for the endorsement! Hope you didn't hit someone on the head with the scope trows ;) joking

Looking at semantics, I think the problem is still in the w3c's (and here's w3schools as well) description of "use as a last available option".

That's a little misleading, because in an article in w3c's site, there's a clear explanation of the differences between <b></code> and <strong></code> in terms of semantic emphasize of the content and still - <b></code> is considered a "bad" tag. In the past years devs seems to follow the thumb rule that <b></code> is replaced by <strong></code>, which seems to be incorrect. I was falling into that group as well, but now I think I'm gonna use <b></code> as NOT "the last available option".

p.s. I'm getting the impression, that in the last drafts of w3c, some of the rules (like b and strong, but also the self-closing tags) are defined to somehow clear the mistakes of devs. Since the introduction of xhtml's self-closing tags as mandatory and <strong></code>'s usage, I'm seeing a lot of html code by various devs, who just don't follow these rules. And here comes the easy way from w3c - cover these mistakes by altering definitions...

@sergiotapia your impression is right. What I mean is that <b> could be used only for text formatting (when needed), without pulling a heavier semantic meaning for the engines. When you want to put a heavier meaning on a set of keywords - strong'em!

The same applies for <em> and <i> as well

Man, that's one sweet bit of explanation to what could OOP in js!

One think I always remember is that thinking of private vars, methods or objects, one should always have one word in mind: "scope". Each time you define something in js, no matter if in an object, function, or the document itself, always have the word "scope" on a sticky note in the right edge of the screen! Saves hours of debugging sometimes.

@vvo I think this approach could go not only in the optimization sense, but more in a coding ethics and good practices mode.

That said, I do agree, the narrowing the selections in the "search selector" is a great approach.