1) Why is it using an NIH format instead of using XML or INI or something?
2) Why does it use symbols instead of words for selectors? HTML calls them "id" and "class", why does CSS call them "#" and "."? Yes you learn that quickly, but terseness isn't really defensible when the verbosity already exists in the other file that you download and edit more frequently.
3) It's too global. This is good for consistent styling but bad for modularity.
4) It's too much of a moving target. Best practice for html+css+js changes constantly.
5) The long history of stuff like "centre a div vertically" shows how it fails the "easy things easy and hard things possible" test.
6) Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
I mean there are good reasons for it to suck. Anything that has grown organically since 1996 with no coherent versioning or deprecation strategy is going to be a hot mess. But it is what it is.
1) doesn't seem to be a very big issue, the syntax is quite simple and readable. Arguably, INI or XML would have been worse. INI especially would have been a shame, now that we can nest blocks. XPATH selectors would have been nice, they are more powerful and barely less readable.
2) doesn't seem to be a very big issue, this kind of stuff is very common in many programming languages as well. I don't remember struggling with this even as a beginner, and it's the first time I encounter a complaint about this as well.
3) Fair point, and the inheritance and specificity rules are very complex as well
4) On the other hand, backward compatibility is stellar (and I guess that it's your point in your last paragraph). Your 20 years old CSS file still works today and doesn't even feel really out of place. We could wish the web platform didn't evolve so rapidly, it makes it very difficult to implement.
5) It's very easy to center a div vertically now. Therefore, it can only be a critic of old versions of CSS, not the current one. Do you have another example of basic things that ought to be easy but aren't, or aren't possible?
5) Doesn't seem to be a very big issue. I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
> I wish the double colon syntax didn't exist and we'd just use single colons, but as you say, it is what it is
Single-colon is a pseudo-class, for targeting elements based on some external state. I learned these as "pseudo-selectors" but it seems that's not the right name.
Double-colon is a pseudo-element, for targeting inner parts of an element that themselves aren't actually an element in the document.
Right! Thanks for this. I've never really looked into this and have been writing whatever worked, with a preference for the single colon.
CSS 1 & 2 apparently conflated the two, and CSS 3 allows one column for CSS 1 & 2 pseudo elements. I never noticed it wasn't all of them. Since I learned CSS right before CSS3, my situation kinda makes sense I guess.
Single colons everywhere have felt easier and more regular to me, so I've written basically everything with single colons except maybe the odd CSS 3 pseudo element here and there. But it seems the two colons will be mandated going forward.
I guess I'll have some edits to do, though I do hope and kinda expect they won't break backward compatibility.
> Why is it using an NIH format instead of using XML or INI or something?
The original suggestion was LISP-like or X.11 configuration file syntax (https://www.w3.org/Style/CSS20/history.html) - XML was still too new (but look at https://www.w3.org/wiki/Xsl-fo if you want to see what the W3C came up with for "styling, but in XML format for XML documents"). My guess is that the declarative shape imitates SGML with a C syntax to make it easier to understand.
> It's too global. This is good for consistent styling but bad for modularity.
Yeah, that was an explicit design choice - one that we're now asking for (and getting) more control over as the web continues to expand, but it's not like it wasn't considered, it was considered and rejected for MVP as it were.
> Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
Ah, cool. I wasn't sure what "here" could possibly mean when we're talking about a language that was part of the web standard.
AFAIK, CSS syntax is inspired by the syntax of STTS, and STTS intentionally didn't use XML because it's a pain in the ass to hand-write and hand-read. I cannot argue with that assessment.
So CSS's syntax was based on an existing syntax, but it happened to be a syntax that didn't catch fire (which is so often the history of such things): it made plenty of sense at the time when the devs were looking at the options and maybe went "Well, we know XSLT and... It sucks and is hard to use, so what alternatives are there?" And STTS was apparently billed as an XSLT that human beings could write and read.
1) Why is it using an NIH format instead of using XML or INI or something?
2) Why does it use symbols instead of words for selectors? HTML calls them "id" and "class", why does CSS call them "#" and "."? Yes you learn that quickly, but terseness isn't really defensible when the verbosity already exists in the other file that you download and edit more frequently.
3) It's too global. This is good for consistent styling but bad for modularity.
4) It's too much of a moving target. Best practice for html+css+js changes constantly.
5) The long history of stuff like "centre a div vertically" shows how it fails the "easy things easy and hard things possible" test.
6) Pseudo-classes are ugly and weird and were a way-too-late NIH thing.
I mean there are good reasons for it to suck. Anything that has grown organically since 1996 with no coherent versioning or deprecation strategy is going to be a hot mess. But it is what it is.