Does not classifying it as a programming language help this situation at all?

LocalPCGuy may just be responding to the grandparent comment which claims that it is:

> Imagine a programming language that only had global variables. You have to carefully name your variables using complicated conventions in order to avoid any conflicts or unexpected behavior. Even your functions don't have local variables; there is no lexical scoping. Any function can overwrite or mutate what any other function is doing inside. There is no real encapsulation.

That simply isn't true; CSS specifies a bunch of declarative rules, which statically evaluate. Though the evaluator may be stateful, reasoning about how the properties for each document node are determined doesn't require state. It requires reasoning about the targets of the rules, and when they overlap, about their relative scopes and priorities.

I am the grandparent, and never mentioned anything about state. Not sure why state matters. Declarative CSS rules have effects. The scope of those effects can be both unlimited and unintended, and you can't "opt out" of being affected by rules – if some rule is targeting you, you're out of luck, unless you anticipate it and apply everything with the greatest specificity possible.

Pardon me; I was thrown off by wording like "overwrite or mutate".

And HTML is a markup language for hypertext, a document rather than an application.

But it turns out that we're using it and CSS and JavaScript to build full blown applications. So, because we're trying to solve problems with applications rather than documents, we have to map the problems of application programming onto it.

So, to build an application, we run into problems CSS wasn't designed to solve (being a not-programming language.) Whether it is or isn't a programming language is irrelevant - to solve our problems (writing applications), we have to treat it as if it is.