First, I commend your attempt to seek objectivity in the matter.
The primary problem though is that the aspects of the language that are objectively bad are those which (a) cause real problems and (b) can't be fixed.
For example, from the "Incomplete List of Mistakes in the Design of CSS", there's the point that because comments can go anywhere, there's no way to represent them in the CSS Object Model. Because any definition of CSS must always work with the way CSS is used in the extant web, there's no way now to limit the location of comments.
But let's take the Tricky Learning Curve. I would contend that in any language, transitioning from script monkey to programmer is hard, which is what you are essentially describing. The remarkable thing is just how far CSS can take you in script monkey mode.
CSS is hard, such as it is, not least because layout is hard. Back in the mid-1990s, around the time that CSS was being born, I was trying to teach myself Java Swing layouts. The layout modes were undoubtedly clever, but I couldn't at that time understand why I couldn't or shouldn't just put each block at position x, y with fixed dimensions. And that was generally into an fixed 2D area. CSS layouts must contend with laying out on to a canvas that theoretically stretches from minus infinity to plus infinity in three dimensions.
We generally don't get a solid grounding in layouts. What are the problems that have to be solved, and what are the issues that potential solutions have in meeting those problems. All we have is a bunch of rules that we try to apply to get the look we want.
Learning those rules could certainly be easier, if our learning resources were better. The problem is that we start with a specification that's written for the benefit of browser makers. There's nothing wrong in that per se, but it doesn't make for something that web page authors can easily learn from. For one thing, a feature that might be very important for understanding an aspect of CSS, might not have many implementation requirements, and therefore only merit a few lines in the specification. Whereas a tutorial would ideally provide innumerable examples to hammer home the point.
For instance, take the Box Model. I often feel that the many descriptions of it, here on DEV and elsewhere, miss the point somewhat, because of the way the specification is structured. The opening paragraph of section 8 (Box Model) of the CSS 2.2 spec says:
"The CSS box model describes the rectangular boxes that are generated for elements in the document tree and laid out according to the visual formatting model."
The section then goes on to describe in great detail the dimensions of the rectangles, and the point that the box model is about the generation of boxes and how those boxes relate to one another is lost.
Guides and tutorials are by necessity less rigorous than specifications, but in the lack of rigour important points can often get lost, leading to frustration when things don't work the way you'd expect. MDN does a decent job of walking this tightrope, but inevitably can't catch everything. Other sources are far, far worse. One of the most common sources for learners in W3Schools, and the quality there leaves a lot to be desired. To this day, its description of what vertical-align:middle does is not just plain wrong, but not even close. This for a behaviour that almost every learner wants to understand, and has been present unchanged in CSS for more than two decades.
So these are the limitations in which we must work within when assessing whether CSS is objectively bad. CSS is built on the sandy base that HTML gave it, and I remain in awe of Håkon Wium Lie, Bert Bos, Elika J. Etemad (fantasai), Tab Atkins and the many others who, from that, built and continue to develop something sane, and that in truth has been wildly successful. And that's the key measure for me. For all its flaws, it's used successfully by millions of people, and that can't be bad.
On the second thought (I haven't realized this before). I tried to find objective proof for a subjective matter. Categories like "good" and "bad" are subjective. For example, there are no good and bad things in math - negative numbers are bad and positive are good - nope.
What I meant to say is: what are design decisions in the language that leads to a lot of confusion and frustration. And do we have objective arguments for it?
I think that's definitely a better question, and you may want to take that to a new post. Even so, it might still be tricky to find objective reasons for what causes confusion in humans. But maybe you could look at the jumble of features wrapped up in the display and white-space properties, the seeming arbitrariness of which boxes form stacking contexts, the unique way text-decoration propagates to descendants, and so on.
Even so, it might still be tricky to find objective reasons for what causes confusion in humans
Well, this would bring us nowhere. People complained about manual memory allocation in C and now we have garbage collection (Go, Lisp, Ponylang, etc.), borrow checker (Rust), and whatever magic Zig is doing. Pointing out problems leads to a solution.
For all its flaws, it's used successfully by millions of people, and that can't be bad.
Based on this logic I can produce list of things that can't be bad:
JavaScript (type coercions, prototypical inheritance, null and undefined, this)
C (manual memory management)
Java (easily eats all memory)
etc.
Maybe they are used not because they are good, but because of Lindy effect?
And there are a lot of new languages and a lot of new research. But CSS and JavaScript have monopoly over the web, that is why they still there. Lets wait till we get WASM
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First, I commend your attempt to seek objectivity in the matter.
The primary problem though is that the aspects of the language that are objectively bad are those which (a) cause real problems and (b) can't be fixed.
For example, from the "Incomplete List of Mistakes in the Design of CSS", there's the point that because comments can go anywhere, there's no way to represent them in the CSS Object Model. Because any definition of CSS must always work with the way CSS is used in the extant web, there's no way now to limit the location of comments.
But let's take the Tricky Learning Curve. I would contend that in any language, transitioning from script monkey to programmer is hard, which is what you are essentially describing. The remarkable thing is just how far CSS can take you in script monkey mode.
CSS is hard, such as it is, not least because layout is hard. Back in the mid-1990s, around the time that CSS was being born, I was trying to teach myself Java Swing layouts. The layout modes were undoubtedly clever, but I couldn't at that time understand why I couldn't or shouldn't just put each block at position x, y with fixed dimensions. And that was generally into an fixed 2D area. CSS layouts must contend with laying out on to a canvas that theoretically stretches from minus infinity to plus infinity in three dimensions.
We generally don't get a solid grounding in layouts. What are the problems that have to be solved, and what are the issues that potential solutions have in meeting those problems. All we have is a bunch of rules that we try to apply to get the look we want.
Learning those rules could certainly be easier, if our learning resources were better. The problem is that we start with a specification that's written for the benefit of browser makers. There's nothing wrong in that per se, but it doesn't make for something that web page authors can easily learn from. For one thing, a feature that might be very important for understanding an aspect of CSS, might not have many implementation requirements, and therefore only merit a few lines in the specification. Whereas a tutorial would ideally provide innumerable examples to hammer home the point.
For instance, take the Box Model. I often feel that the many descriptions of it, here on DEV and elsewhere, miss the point somewhat, because of the way the specification is structured. The opening paragraph of section 8 (Box Model) of the CSS 2.2 spec says:
The section then goes on to describe in great detail the dimensions of the rectangles, and the point that the box model is about the generation of boxes and how those boxes relate to one another is lost.
Guides and tutorials are by necessity less rigorous than specifications, but in the lack of rigour important points can often get lost, leading to frustration when things don't work the way you'd expect. MDN does a decent job of walking this tightrope, but inevitably can't catch everything. Other sources are far, far worse. One of the most common sources for learners in W3Schools, and the quality there leaves a lot to be desired. To this day, its description of what vertical-align:middle does is not just plain wrong, but not even close. This for a behaviour that almost every learner wants to understand, and has been present unchanged in CSS for more than two decades.
So these are the limitations in which we must work within when assessing whether CSS is objectively bad. CSS is built on the sandy base that HTML gave it, and I remain in awe of Håkon Wium Lie, Bert Bos, Elika J. Etemad (fantasai), Tab Atkins and the many others who, from that, built and continue to develop something sane, and that in truth has been wildly successful. And that's the key measure for me. For all its flaws, it's used successfully by millions of people, and that can't be bad.
On the second thought (I haven't realized this before). I tried to find objective proof for a subjective matter. Categories like "good" and "bad" are subjective. For example, there are no good and bad things in math - negative numbers are bad and positive are good - nope.
What I meant to say is: what are design decisions in the language that leads to a lot of confusion and frustration. And do we have objective arguments for it?
I think that's definitely a better question, and you may want to take that to a new post. Even so, it might still be tricky to find objective reasons for what causes confusion in humans. But maybe you could look at the jumble of features wrapped up in the
displayandwhite-spaceproperties, the seeming arbitrariness of which boxes form stacking contexts, the unique waytext-decorationpropagates to descendants, and so on.Well, this would bring us nowhere. People complained about manual memory allocation in C and now we have garbage collection (Go, Lisp, Ponylang, etc.), borrow checker (Rust), and whatever magic Zig is doing. Pointing out problems leads to a solution.
Based on this logic I can produce list of things that can't be bad:
this)Maybe they are used not because they are good, but because of Lindy effect?
And there are a lot of new languages and a lot of new research. But CSS and JavaScript have monopoly over the web, that is why they still there. Lets wait till we get WASM