The worst thing about CSS is that a lot of people don't bother learning it, then have a strong opinion after they were forced to use it for a day.
The worst thing about CSS is that a lot of people don't bother learning it, then have a strong opinion after they were forced to use it for a day.
I learned CSS 20 years ago. My strong opinion is that it should be renamed Crappy Style Sheets, but that would take away from its primary fault, that it's cascading. As we learned in many other things, "inheritance" is not a great idea. Especially for something that gets applied globally, by a team of five people. "I will now adjust this thing over here, which will mess up everything my colleague is doing over there" is not a good feature. Its main feature is to give you complex rules how to overrule a certain rule. As a feature it's a a headache, when that's what you base everything around, it's bad. It gives you complex ways to target things, and over time it became even more complex. If you're a sane person, you've learned to avoid most of these otherwise you'll end up with .foo > .bar:nth-child(2n) ~ .baz . Then you will adjust that and come full circle to my argument, which is that it will break Mark's completely unrelated thing.
At the same time doing the simplest imaginable layout was a headache. I've done it, and it was interesting as in, this is a challenge and I am taking it head on, but it never should've been a challenge. Things have improved exponentially here, but it should've been the idea all along. Not how to cascade rules.
All other criticism, the syntax etc. is nitpicky and not important. As long as it's allowing you to do something useful without much fuss, I am ok with any syntax. But it didn't and it never did. Making a webpage layout should not be a full time job.
I love the fact that CSS is cascading; inheritance is a great idea, "where it fits". The main reason I like the cascading in CSS is because it is inherently a tree, and when it comes to parsing documents (using context free or non context free languages) a tree is very often a good fit. That and humans have long used trees (abstract or otherwise) to organise knowledge.
And since documents "fit" trees way more often than not; I'd say CSS is a good fit.
The issue is you never really know which property "cascades" or not. There are special cases for block elements, flex elements, flex children elements, sometimes even the boring "a" link object. It's basically trial and error until you somehow remember the most common cases.
I learned it 30 years ago and back then and for some time it was not clear whether it will prevail.
There used to be DSSSL and JSS. The former came out if the SGML world, like HTML itself, and it was kind if the obvious solution to adapt it for the web. The latter used JavaScript syntax and was Netscape's favourite, which also made sense, them being JavaScript's inventors.
(A maybe interesting aside to this story is that JavaScript actually predates CSS, at least if we go by the dates each shipped in a browser.)
I have also been doing CSS for 20 years but it seems you have some skill issues?
I remember the my 'one day'. I was messing around making a podcast app awhile back and thinking it shouldn't be hard to make a floating footer in css that's (1) always at the bottom, (2) always visible, (3) doesn't permanently occlude content and (4) doesn't require any hacks or artifacts eg. putting a same sized buffer in the scrolling content to handle item #3. Turns out it's just not possible. Great system.
What do you mean it's not possible?
It's not possible to do without violating one of the conditions I listed. Of the solutions people have posted on SO and on blogs they either will be pushed off the screen when there's too much content (violating #2), will be pulled up to under the last rendered element if there's not enough content (#1), or will occlude content if you use absolution positioning (#3). This forces you to use an empty element of the same size as the footer, which has absolution positioning, which ends up being the element which scrolls under the footer (#4). This is what google podcasts did iirc, but it's just a hack. You'd think there'd be a simple way without having to make sacrificial elements on your page.
If the content that you don't want occluded has a bottom padding, your floating footer will be right atop that extra padding.
But further more, with flex and grids you can handle it even better. Without any hack. This doesn't sound like the most complex thing I've seen done with CSS.
You've identified the hack I already mentioned in my post. If there are simple flex or grid solutions feel free to post them.
> The worst thing about CSS is that a lot of people don't bother learning it
How dare people use CSS without learning in-depth all 20+ specifications! It's an outrage!
When people have problems using a tool, you should look at the tool rather than blaming the people. People aren't going to change. You don't tell people to be more careful using a bandsaw; you install safety features.
You obviously don't need to learn 20+ years of specs, just as with any programming language, markup language there is some stuff you need to use it in a modern way, the other stuff you can pick up as time goes on.
You actually don’t let people use a bandsaw if they’ve demonstrated reckless behaviour.
Yes, but that is not the same as telling competent professionals to exercise more care. Accidents are prevented by creating systems that make accidents hard, not by requiring more vigilance from individuals. This is why bandsaws come with guards and other safety features.
Someone who can't figure out how to use CSS effectively in about an hour is not a "professional". CSS is very simple, and very powerful. People's underdstanding of it seems to be lacking, and it almost seems like from these comments that it comes down to willful ignorance.
Would you hold another programming language, such as JS, to the same standard?
Of course. I think JS is full of mistakes. To be fair some of the more egregious ones have been fixed, but there are still plenty left.
I'm a big believer in learning new stuff, when that stuff has lasting value. However it is far more efficient to fix things, a one time cost that benefits everyone, than to ask everyone to learn the quirks of a tool, a cost that is paid every time someone new comes along.
Are you implying that having both String.prototype.substring and String.prototype.substr is somehow confusing?
JS is in general better because by the time it came out people knew what to expect from a scripting language.
CSS didn't really have a lot of earlier styling and layout languages to copy. Also the original vision was much more limited.
> Also the original vision was much more limited.
Is this about CSS or JS (and things like Node)?
You don't tell people to be careful when using a saw?!
How about we do both? We expect people to be able to use the tools, you know, properly, and make sure the tools are well-designed?
> How dare people use CSS without learning in-depth all 20+ specifications! It's an outrage!
Is strange reaction to:
> ... then have a strong opinion after they were forced to use it for a day.
There is not problem with using something without understanding all complex rules. Point is about forming strong opinion based on superficial knowledge.
People are not humble these days.