&gt; That&#x27;s exactly how Bootstrap&#x27;s classes for lists work. And they are tied to the DOM structure, though not necessarily to particular elements: .my-list has to go on a container element, and .my-list__item has to go onto children of that element.<p>Not quite exactly. My solution doesn&#x27;t require list items to be child elements of the list. Bootstrap&#x27;s &quot;list item&quot; needs (by definition&#x2F;rule) to be a &quot;direct&quot; descendant - a child element of a given type (a selector with &quot;&gt; li&quot;) of the list. They have classes for lists, and then style the list items via element and &quot;descendancy&quot; (i.e. .my-list &gt; li).<p>If somewhere along the way you decide&#x2F;are asked to change the mark-up in order to have an element for grouping list items (so, you&#x27;d have elements between the list and list items ), Bootstrap&#x27;s way of creating rules wouldn&#x27;t work anymore - list items wouldn&#x27;t be child elements of the list, despite you wanting to keep the styling in them. Independently of how you solved this in the mark-up, if your rule was like Bootstrap&#x27;s .my-list &gt; li, then it wouldn&#x27;t work anymore because list-items wouldn&#x27;t be &quot;direct&quot; descendants of .my-list.<p>This might seem minor or unusual, but I assure it&#x27;s not - this is the kind of changes in structure that happen very frequently and make DOM-tied CSS fail. And bear in mind the Tetris effect on this: your less-than-experienced team member might solve this with yet another rule, but a even more specific one (.my-list &gt; .group &gt; li) which will yield harder to maintain CSS (this rule is very specific; it would need even more specific rules to be overridden when necessary). If your development rule was &quot;no DOM tying; just use classes), the problem of escalating specificity would&#x27;ve also been avoided.<p>&gt; The point I was trying to make was that at a component level, your CSS classes are usually going to depend on a particular hierarchy in the DOM elements that the classes are applied to, or they won&#x27;t work correctly. How much of a dependency you have is a tradeoff; you can design your framework to minimize the dependency, but you&#x27;re likely to create a more complicated framework in exchange.<p>I understand your point, but I don&#x27;t agree with the notion that &quot;but you&#x27;re likely to create a more complicated framework in exchange&quot; by minimizing the dependency on the DOM. You&#x27;re likely, definitely, to create a more verbose CSS framework, with a way bigger amount of classes. But I don&#x27;t think this is the same as complicated; it&#x27;s more verbose, it may require you to write more code[1], but I think it&#x27;s very predictable and easier to follow by team members with different expertise levels.<p>P.S. Also, bear in mind that BEM-like solutions also have hierarchy. Elements which belong to blocks. They just don&#x27;t depend on a specific hierarchy on the DOM; DOM hierarchy is independent of styling hierarchy.<p>[1] I&#x27;d argue it will make you write more code <i>in the beginning</i>. Traditional DOM-tied styling will eventually catch-up and the code you have to write to overwrite &quot;over-specific&quot; selectors and similar issues will grow bigger.