Where the design community meets.
If you are writing something that is 'heavily modular', you would just use a lot of globals, which are just classes, and end up with a similar approach, if I'm not mistaken. You just also get more specific scoping when it's needed.
This is exactly the point—everything should be made 'global' as you put it because, potentially everything should be re-usable as easily as possible. If you tie stuff to 'pages' it isn't re-usable without refactoring. If you tie things to the structure of some markup it isn't re-usable in a different (markup) context.
In your post you mention "semantics"—adding classes to HTML makes it more semantic, not less. Screenreaders and search engines don't care about classed/ids in your code but developers do. This is the whole point of classes, they are hooks to be used for styling so the more you use them, the more flexible your code is.
If you haven't already, I would recommend reading these posts regarding semantics and OOCSS:
everything should be made 'global' as you put it because, potentially everything should be re-usable as easily as possible.
Ah right so I think that is where we diverge. I don't like to use time or complexity prematurely optimizing things. This is a relatively popular opinion in programming in general called YAGNI (read more here: http://en.wikipedia.org/wiki/You_aren't_gonna_need_it) -- another related one is KISS (http://en.wikipedia.org/wiki/KISS_Principle). If you google either of these there are tons of supporting posts, and this has without a doubt made things easier for me in my work numerous times in the past.
The approach you advocate is sacrificing the DRY-ness and readability of your html and css in order to prematurely optimize the re-use of every single style block on the entire site. I'd rather build out the styles as they originally were specified in the design mock, with the cleanest and most readable markup possible, and if a change comes in later that re-uses a style that was not previously used anywhere else, consciously bump up the scope of that style as needed.
I have no idea how BEM sacrifices DRYness—it does the exact opposite, in fact. You write block styling once, independent of markup, and then re-use it whenever you need it regardless of the structure of your markup or where it is contained. Having several selectors to re-use styling in 3 different places sacrifices DRYness. Having to refactor you CSS (and your HTML) because 3 months down the line a component you deemed to be in the scope of a 'page' now needs to be 'global' because the client wants a new section and your new mocks re-use a bit of an existing page in a completely new place on a new page but with slightly different styling because you drew the line of 'you might not need it' in the wrong place. ;)
Your posts seem to assume that BEM makes things more complicated. It doesn't — it makes things simpler in the right place (your CSS) offloading the complexity to the bit where it's easier to manage (your markup). Sass negates some of this via @include and the much-abused @extend but it can get out of hand very easily. I'm all for keeping things simple and OOCSS does this. If you're just getting hung up on the (initially ugly) syntax then you're priorities are probably misaligned. When you get used to the syntax it's more readable. To quote Harry Roberts:
The point of BEM is to tell other developers more about what a piece of markup is doing from its name alone. By reading some HTML with some classes in, you can see how – if at all – the chunks are related; something might just be a component, something might be a child, or element, of that component, and something might be a variation or modifier of that component.
Again, I would recommend actually trying BEM (or even just plain old OOCSS) on a project before you make assumptions about things like DRYness. :)
To each his own though, you're clearly happy with the way you do things so why question it?
I have no idea how BEM sacrifices DRYness
li.menu__item li.menu__item-selected li.menu__item-selected-whatever-else
See any repetition here? And don't even make me bring up how the html looks haha.
you drew the line of 'you might not need it' in the wrong place
Not the right mindset. You draw the lines based on "need it" or "don't need it" -- YAGNI. "Might" is not even a thought. If you need it later, you take the style block and move it up one scope level. It's not a disaster or a major refactor, it's simply widening the scope to the appropriate level.
When you get used to the syntax it's more readable
Haha you could say this about anything, I'm pretty sure. Not sure I'm on the train with this one.
Absolutely! And it would be silly for you not to! If you have a small project with just a tiny bit of js interaction, setting it up with backbone or angular or some huge framework you don't actually need but might want later if changes or additions come down the line is, in my opinion, doing it wrong. You add things when you need them, not when you might possibly need them eventually.
before you make assumptions about things like DRYness
These are not assumptions, these are facts. There is a massive amount of repetition when you write and re-write the same block name over and over for each piece within the block, rather than nesting. I gave an example in the writeup I originally posted of exactly this. There really is no argument about it, bem is more verbose and involves more repetition than nesting. You can (and have) argued that the extra repetition offers more flexibility, but you can't argue that it doesn't involve a huge amount of repetition.
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.