Except that nested selectors trivially convert to traditional selectors. i.e.:

  .container {

    .line {

      input {
      }

      button {
      }
    }
  }

corresponds to:

  .container .line input {
  }
  .container .line button {
  }

So there could just be a really simple internal translation step, if that's needed for performance reasons.

No, I think you misunderstood. The concern is not for the translation, but rather that for every <input> node, it would have to check if it has an ancestor node that has the class "line", and then an ancestor node that has the class "container".

It's more efficient, in the case of a complete selector like "#person_name", to simply see if a given node has that id.

This makes simple selectors more favorable than complex selectors that depend on node hierarchical interrelationships, so it's best to have a syntax that favors having simple selectors, than a syntax that encourages bad, complex selectors.

Hmm. Interesting reasoning, but I'm not sure whether that would actually be a basis for this kind of design decision. Do you have a source where this was mentioned in the context of a proposal?

No, like I said, I only imagine this is the case.

There's also the fact that complex selectors are more dependent on the structure of the DOM, so they could also be considered bad practice from the angle that the selector might needlessly tie them to a structure that semantically their styling shouldn't depend on. From the readability side, it's also easier for a developer to find affected nodes when reading simple selectors like `#foo` or `.bar` (they just need to search for the identifier with grep or the like) than when reading complex ones that require them to look into the structure of the document.

I don't think it's unreasonable to think that languages are designed to encourage what people would consider to be good practices. After all, if developer power trumped all, we could replace HTML and CSS with Javascript (and we do when either HTML or CSS don't suffice), but HTML and CSS exist to improve readability for developers and the ability for browsers to optimize their implementation.

It's certainly not bad practice from a semantic/structural perspective. Contextual selectors become absolutely essential the moment your DOM becomes at all modular.

That said, there are things like BEM (http://getbem.com/naming/) which have popped up to try and maintain that general pattern while trimming down the performance cost. I'm just not sure what that cost actually looks like, impact-wise.

I don't mean that structure in selectors should never be expressed, but I do think that selector complexity should be avoided. Nesting seems to encourage selectors of arbitrary depth, while having them always start with no context seems to discourage making them too deep.

In any case, I found this Editor's Draft[1]. I don't know what the current plans are for it, though.

[1] https://tabatkins.github.io/specs/css-nesting/