> Generating CSS with JavaScript was a possibility, but boy oh boy is that ever a bad idea.
lol.
As a backend developer that pretends to be full-stack, I enjoyed the hell out of reading this. CSS is such a mosh pit that it's just about impossible to find a summary of why things developed as they did. Plus I feel curiously reinforced about the times I've come at this with fresh backendy ideas, asking frontend devs "uh, why are we doing it this way?" and they only make strangled noises in response.
As someone who was doing frontend development since before CSS existed (I jumped in somewhere around when the <center> tag was introduced), I can probably answer any of your questions.
Most answers—especially for those early features—boil down to folks from the desktop publishing world wanting features they've always had, using terminology few programmers had ever heard, and looking to use layouts everyone in their community was already intimately familiar with.
Some things got lost in translation, but a lot is just an artifact of desktop publishing not having the same goals or desire for algorithmic elegance that developers were used to. Then of course were the tradeoffs. Remember that when CSS was first introduced in Internet Explorer, 16-32MB of RAM was typical if not advanced. The user had a 512MB hard drive on a good day. There were no GPUs as we think of them today. There were some 2D accelerators (good ole Diamond video cards) that took ridiculously slow rendering up to the level of very slow rendering. 800x600 target resolution was typical for web development.
No one really knew what they were doing, but everyone had an opinion, and a lot of those opinions were incompatible with one another. A lot of temporary stopgaps were put in just to solve the problem of the day only to end up part of our technical debt today.
ActiveX and Flash (and <applet>) solved real problems, but were never architected as a cohesive part of the whole. SVG took way too long and progress was crushed under the weight of committee. XML touched everything and was universally agreed upon as the glue moving forward… until it wasn't. We still call them XHR calls even though they rarely fetch XML resources anymore.
And layout is hard. Damn hard. Ridiculously hard to get right, and that's when you have a well-thought out plan and universal agreement. Which Microsoft and Netscape most certainly did not have. Neither really had a solid reference point. Correct behavior mostly boiled down to "how it renders in that browser version right now".
We really have come a long way. One should expect warts and scars. All things told, I'm really happy with how modern CSS turned out. It may be complex, but so are the outputs it is meant to produce. Those who pine for something substantially simpler I believe have a diminished understanding of the problem space.
As a mostly front-end person who knows CSS pretty well, it’s still baffling as to why things developed the way they did and why there are so many ways to do certain things like layout. The sheer number of layout options and their inherent quirks make designing any site or app from scratch a nightmare. This is why most modern applications use layout engines like Bootstrap or foundation (especially because it does most of the responsive design for you).
Is there anything in specific you can point to in terms of layout? IME Most of the time you can just `display: flex` or `display: grid` (and then tweak the necessary properties on the children) and it generally works well.
As a full stack dev that wants to be backend: Fully agree with you there. Frontend is so much more of a pain for me than backend because so much of it just seems bad in terms of usability for no real reason.
On the frontend, the users control the execution environment. On the backend, developers control the execution environment. It had to be this way for the web to scale the way it did.
Most developers are control freaks. "I put in input, and the computer does what I say." Far more so than the general population, I think. That lack of control on the frontend will predictably not be looked on highly by many in our profession. I think those who are more comfortable having a more loose grip on their environment tend to be more comfortable with front end development—more accepting the state of how things are, not some elegant and provable state that can be verified to the nth degree.
We've molded and shaped our world in the backend to be as predictable and controllable as possible. Arguably, the frontend is more representative of the real world and its compromises.
lol.
As a backend developer that pretends to be full-stack, I enjoyed the hell out of reading this. CSS is such a mosh pit that it's just about impossible to find a summary of why things developed as they did. Plus I feel curiously reinforced about the times I've come at this with fresh backendy ideas, asking frontend devs "uh, why are we doing it this way?" and they only make strangled noises in response.