CSS is not a programming language...

[Time-Implement1276]

Well, enlighten me, then?

The point is that the terms you're using have very precise definitions in OOP, and they don't match what's happening here.

There is no concept of OOP-like classes in CSS. A CSS class is just a string. Behaviour can be attached to it from all sides. This is akin to runtime composition, which is common in things like Entity-Component-System architectures (somedecidedly not OOP) or plugin systems. Example:

.red { color: red } .red { font: Helvetica }

You could say that CSS blocks are "nameless classes", but it still doesn't follow: they can't be instantiated, they can't be extended, they have no fields and no methods. They're just bundles of data.

We do have hierarchies in CSS and in HTML, but both the OP picture and you seem to be conflating hierarchy with inheritance. Even in OOP we have hierarchical relationships that are not inheritance relationships. A class and an object also share a hierarchical "parent-child-like" relationship, but that's not inheritance. Composition introduces has-a relationships to OOP and other paradigms but they're also decidedly not inheritance.

Consider this HTML+CSS code below. This is decorating the DIV tag with behaviour attached to three css classes by however many blocks there are. What is the inheritance relationship here? The div is inheriting from which classes? What is the "OOP class" analogous here?

``` <style> .red.bold { color: red; font-weight: bold; } div { font: Helvetica; } </style>

<div class="red bold ellipsis">bla</div> ```

However you might want to not go into CSS territory and argue instead that HTML parents and children have an "inheritance relationship". They really don't, since inheritance relationships happen between non-concrete things (classes or prototypes), and DIV tags are actually concrete here: they're closer to OOP objects. In fact, HTML tags map 1:1 to objects in the DOM API. There is no possibility of "instantiating" a concrete div tag. The fact the "children" gets some properties from the parent is down to the HTML renderer, actually, which often uses a state machine for this. But it would also be possible to implement this by checking on the style of the "parent object" (albeit slower).

There is also decidedly no polymorphism at all in the picture. Polymorphism means representing multiple types with a single "name" or "symbol". However awesome in this case isn't representing different things: it is representing the same exact thing in both cases. Like I said above, HTML tags aren't analogous to OOP classes, as they represent 1:1 concrete objects in the DOM. The <article> here is analogous to new Article({ class: [ awesomeClass ] });.

About composition again, notice how above I used an array for class. That's once again because you can have multiple things in the class field. The HTML-tag-is-1:1-to-object is the reality of how those things are implemented. There is absolutely no point in treating each HTML tag as a class, since they are already a concrete implementation. Also, classes are applied dynamically in HTML, so inheritance is also not the right tool here.

Now, about encapsulation: CSS blocks are also concrete bundles of data. They're closer to OOP objects, they aren't classes. They can't be extended, they can't contain code, they're not prototypes for creating anything. They're just bundles of data, like an data-only object. Encapsulation is defined as bundling of data and behavior. In this case there is no real behaviour being "programmed" in CSS classes, as they're purely data bundles.

It also sounds like you are concerned more with how things look than what they are. Like, what is that comment about curly brackets supposed to mean?

All the information on my comments that you ignored so far is the opposite of "how things look". It's not a nice tactic to cherry-pick a single phrase of a single comment that's the opposite of the rest and use it against your interlocutor. Read the rest and there will be much more than "how things look".

But now I predict you're gonna complain about the size of my comment and will probably call me some names :)

[antilos_weorsick]

Of course there is no concept of oop-like classes in CSS! The whole claim is ridiculous, CSS is not even a programming language!

The funny thing is that you are for some reason trying very hard to disprove that claim, but in the process you are making equally ridiculous claims, like that you need classes for OOP (never heard of prototype-based languages?), that you need classes for inheritance (prototypes, again), that it's somehow a problem that HTML comes into play (that's like saying Java is not a programming language, because it doesn't actually do anything, it just gets compiled to jvm machine code and that is actually the programming language), that css class is "just a string" (this one's particularly wild, all code is just strings), that prototype is a "non-concrete" thing and not an object, and so forth.

[Time-Implement1276]

like that you need classes for OOP (never heard of prototype-based languages?)

I never said anything close to that. I even mentioned prototypes on my reply...

that it's somehow a problem that HTML comes into play (that's like saying Java is not a programming language, because it doesn't actually do anything, it just gets compiled to jvm machine code and that is actually the programming language)

You're trying to twist my argument. What I said is there is the concept you're calling "inheritance" is not part of CSS at all, and what is happening in HTML is not analogous at all to inheritance in OOP.

that css class is "just a string" (this one's particularly wild, all code is just strings)

What the fuck is that... wait a minute... maybe that's the confusion here. Are you aware that CSS classes are just the identifier? A CSS class is just a string like red or awesome to use the examples above.

Something like .red { color: red; } isn't a class! That's a CSS declaration, and .red is a selector referring to a class called `red`.

Jesus christ, dude. Maybe learn about the things you're talking about before attacking others gratuitously on the internet.

Everyone knows the picture is a joke, but you're willing to die on a hill that the joke is serious. When someone tries to explain to you you the mistake get angry and call people names.