philipwalton

You pretty clearly didn't read the article.

Semantics weren't discussed at all. The focus was on making the best of working with a language that has a limited feature set, and learning to reexamine long held best practices.

There are a few reasons I prefer the namespaced modifier approach to what you've described:

1) This approach is more error prone and less predictable. For a one-man job it's probably OK, but on a team it's harder to guarantee someone else isn't going to apply some styles to `.sidebar`, which will cause unwanted styles to be applied to your separator component. The namespaced approach is very intentional, so it's unlikely someone will add styles to that rule without knowing exactly what they're affecting.

2) chaining like this ups the specificity of the CSS rule, which means your other modifier/presenter classes might not work on the element anymore. In CSS specificity is everything, and keeping it nice and low is usually preferable.

You left out Nicolas Gallagher and Jonathan Snook :)

@thejerz, article author here.

1) I didn't write this while on the job at Appfolio. I wrote it at home, in my spare time, because I like sharing the things I've learned on the job with the rest of the Web community. Based on the upvotes and overwhelmingly positive responses I've received, I think it's worth my time.

2) My work on the CSS for Appfolio Property Manager has greatly helped the development team (mostly back-enders) and sped up the process. We can release features much faster because of it. I'm sorry they're not the features you want (that's not my call), but if/when we deliver those features they'll get to you quicker because of my work.

Totally, I discussed this a bit in the article but probably should have stressed it more.

Nicole Sullivan (OOCSS creator) refers to this principle as "separating content from container".

I was going to point you to this Github issue, but then I realized I'd be linking you to yourself :)

https://github.com/stubbornella/csslint/issues/380

Mainly parts from two of the rake tasks: 1) to create new posts 2) to deploy to Github pages

I started out using Octopress but in the end chose to go just plain Jekyll and borrow from Octopress only the things I needed. I'm pretty happy with my decision.

Ultimately, you just need to look at the feature-set of Octopress and decide if you actually want those things (custom theme, Disqus and GA integration, etc). If you do, great, if not, it's probably going to get in the way more than help.

Yes, but that doesn't actually solve the problem. How is that code going to interact with your existing objects unless those objects are in the global scope?

If both the requester of the AJAX call and the receiver are in the same closure, there's no need for those objects to be globally accessible.

One additional point the author didn't mention:

Executing JavaScript code sent from the server requires your JS objects to be in the global scope. Returning JSON (on the other hand) allows you to keep your objects and logic inside a closure.

Yes, but there's a difference between your options being worth nothing and the value of your options being unknown. There's also a difference between the value of your options being unknown and the value of your options being known but you not being able to exercise them for whatever reason.

You may not care about that distinction, but I'd be interested to know what camp those "$0 :(" people are in.

There should be an additional choice for people who have options but aren't able to cash them out yet.

That would offer a view into the percentage of people who stay at a startup long enough to exercise their options.

Yeah, I'd be curious to see traffic data from people who got to various spots on the front page and see what trends emerge.

Though, now I'm remembering that the post was also on /r/webdev and /r/web_design, so that skews things a bit.

700 at the same time. 40K in the 24 hour period after it made the front page. Yeah, I was not expecting that.

Luckily, I had recently converted the site from WordPress to Jekyll and was hosting it on Github pages, so I didn't worry too much about the load.

When one of my articles made it to the #2 spot on Hacker News, I was watching my Google Analytics Real-Time stats pretty closely. It got as high as ~700 people on at one point. (Here's the submission: https://news.ycombinator.com/item?id=5062761)

Yes, but obviously I'm wanting a streaming service to offer it.

I don't think so. The same issues would be there for music, but those apps all offer it.

As long as you can only watch it from within their app (so they can keep stats), it shouldn't matter whether it's online or offline.

<rant>

Netflix really needs to implement an offline mode for its mobile apps.

The vast majority of the times I'm watching something on my phone, I don't have a WiFi connection or the connection is too slow to stream an HD video (like on a plane, at the gym, in a car, etc.)

I'd love to be able to download something at my home and watch it in offline mode later. Both Rdio and Spotify do this for music. Why doesn't any video services do it? Are you listening Netflix?

</rant>

I wasn't suggesting anything's wrong with it. Certainly the creator of Bootstrap has liberty to copy himself. I guess I'm just a little surprised he didn't want to showcase his variety.

Does anyone else notice the striking similarity between the new Enterprise design and Bootstrap? I guess that's what you get when you hire Mark Otto.

https://enterprise.github.com/ http://twitter.github.io/bootstrap/

Yeah, I was just gonna say this definitely should have been written with Sass.

No, your example isn't the same.

In your example you're referring to the max-width of the viewport. In Ian's example, he's referring to the max-width of the `.testimonial` element itself.

JavaScript has three main features that commonly trip up people from other languages. If you understand these three things, you'll be way ahead of the curve:

1) What `this` means in a function context https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

2) The prototype chain and prototypal inheritance https://developer.mozilla.org/en-US/docs/JavaScript/Introduc...

3) Function closures and variable scoping https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Cl...

John Resig made a similar point in an article discussing using JavaScript as an intro language for the Khan Academy. http://ejohn.org/blog/introducing-khan-cs/

He argues (and I agree) that prototypal inheritance isn't complicated unless you're coming from a very classical inheritance background.

An example of the TODOs app with AMD is great! Now if only Backbone and Underscore would support AMD natively so you wouldn't need to Shim them.

The double hyphen is actually part of a pretty common naming convention (BEM-style) for distinguishing between separate components, component modifiers, and component sub-objects.

Examples: https://gist.github.com/1309546 http://nicolasgallagher.com/about-html-semantics-front-end-a... http://csswizardry.com/2013/01/mindbemding-getting-your-head... http://engineering.appfolio.com/2012/11/16/css-architecture

I was going to say the exact same thing, but you beat me too it!

I started with this approach when I built our tooltip library for my company, but eventually there were just too many gotchas. We switched to using JavaScript and inserting the generated element as a child of `body`.

The point was that there are factors other than z-index involved in determining the stacking order. I'm certainly not suggesting anyone use opacity to move things around in the stacking order. I was just trying to make people aware of it. It's confusing if you don't know what's going on.

The suggestion "Never nest rules purely for code organization" isn't to save a few bytes, it's avoid the specificity trap. Too many people who write Sass use nesting to make their code look more appealing in their editor, but what they end up with is unnecessarily specific selectors.

The file size issue isn't really that much of a concern unless you're on a really large site, but specificity issues affect everyone.

What part of OOCSS do you think SASS already solves? Perhaps there's some disagreement about this that can help me answer your question.