The css tricks website definitely has always had way too much css. Imo a very jarring user experience that often had me hitting the back button and clicking the adjacent w3schools article for whatever "css trick" I was searching for.
This article seems to think the CSS spec is too big, which I don’t think is the case. We should be able to access lots of rendering options via CSS. But CSS stylesheets are definitely way too big.
Is disagree. I have no idea how to do CSS after five years of web programming, except using trial and error.
Reading "what is new in CSS3" did not help much, but at least flexbox means I don't use howtocenterincss.com any more;
while grids became my go-to for all problems, with four attributes that do something about margins and centering but I ignore them out of a lack of memorization.
I was really really good at CSS circa 2010 and understood and could apply a very broad set of its features, but I stepped away from web front-end around 2013 or 14 and when I look at a modern stylesheet I struggle to make any sense of it. And that's without SASS or whatever in the mix.
I don't think so. New CSS features are pretty low overhead to learn, and save me a ton of time. I used to use all those black magic tricks they mention at the beginning of the article, and it was way harder to create layouts back then. Not even close. Adding more features has mostly just made it easier, so it's worth the tradeoff.
On the upside, all the basic properties and selectors work now across browsers. You don't need to know about hasLayout, mysterious 3px margins or inline-table hacks. If you don't follow the latest hotness of the week, you can develop in one browser, then just quickly check in a couple of others, and 99% of the time it's fine.
No, I think it's because Microsoft failed their way out of the browser game and then we got auto-updating browsers. IE6 did a terrible job of implementing web standards, with MS deciding to just make up their own damn standards. And updates to IE6 were locked to Windows updates, IIRC. IE7 was big step in the right direction, but it wasn't until IE11 that you could be reasonably sure that developing in FF/Chrome meant it would work roughly the same in IE. But even then, MS wouldn't let you go past IE9 on XP, so in a lot of ways IE9's marketshare was tied with XP's, which took years to dwindle away to a point where you could safely ignore it.
Then Chrome rose to power, which is repeating some of MS's failures with "their own damn standards" here and there, but is largely avoiding the big failures because the browsers update themselves now. Shy of people being stuck on X version because of their work situation, you don't have to worry about a huge chunks of your userbase being stuck on a 5 year old browser anymore because most folks are getting auto-updated and those updates aren't arbitrarily locked behind OS versions like IE was.
There is a lot of CSS now…but so many of the recent additions have been useful. Really useful. Like, solves real-world problems, easy to understand, on their way to being very well-supported.
For example, :has() has nearly 83% global support already [1]. Once Firefox enables it by default (it’s behind a flag currently) and more upgrade to the latest versions of macOS and iOS, we’ll soon exceed 90%.
I wouldn't compare it to a scripting language specifically; it's maybe powerful like JS, but I wouldn't say it's "very JavaScript-like" in any other way. I'd compare modern CSS more to a logic language like Prolog or SQL; or maybe to whatever you'd call Excel (dataflow programming?)
In places where CSS takes expressions, they're always declarative, functional expressions; and they're always guaranteed to auto-update when their dependent values update, instantaneously as part of the update to the dependent values. Like an Excel grid-cell.
To me, however constrained "programming" in CSS still is, this makes for far better "programming ergonomics" than JS could ever give me — which, as you say, has me always reaching for a CSS solution before one in JS.
CSS is also interpreted. CSS is faster because it's not a general purpose language and so its expressions have many optimization opportunities for reusing partial computations and parallelization.
By that argument JavaScript is also compiled, so this point is wrong no matter how you interpret it: if "interpreted" means source code is transmitted and then executed in whatever fashion, then both JS and CSS are interpreted, if "interpreted" means a specific execution model on the client machine, then they are both JIT compiled and neither are interpreted.
By that argument JavaScript is also compiled, so this point is wrong no matter how you interpret it…
The primary difference between a traditionally compiled language (like C) and CSS and JavaScript is C is compiled before execution and CSS and JavaScript are compiled during execution.
There’s a reason why JIT stands for Just In Time compilation [1].
Yes I know the difference, the point is that the original poster said CSS is faster because JS is interpreted. There is no way to intrepret that statement in a way that makes sense.
Sure there is - some people use interpreted to mean step-by-step, as in imperative. "CSS is faster because JS is imperative" is a charitable and correct reading.
But that is not correct, js is not interpreted/executed step-by-step in many cases (it is a bit more complicated, there are multiple interpreters and JIT compiler in the picture, it usually is started up by interpreting but then switched to JIT compiled native machine code).
The correct difference to make is the execution model, one being basically a Turing machine while the other is more similar to logic programming languages.
yes, declarative is exactly how i'd describe css "programming". you supply constraints and the css engine applies them as best it can. the constraint declaration language of css is becoming more sophisticated, which is much needed and welcome, but it's not anywhere close to scripting (as in, providing a precise flow of instructions).
I mean some of those things just make sense. Why shouldn't CSS allow you to mix units and do some basic maths like with calc? Having had to resort to JS for that stuff is the real issue there.
CSS in my eyes should be able to handle 99% of visual style related needs with ease, JS should be there for the rest.
I already want an add-on that allows me to disable certain CSS features just like I block JS by default. It's becoming a problem for sure.
You’ve pretty much always been able to do this via user style sheets [1], which override author (the author of the website you’re viewing) stylesheets.
What I'm missing is a sane set of defaults applied to every page automatically with a nice UI so I can enable specific features on a per-domain basis with a couple clicks. If I get the time I'll write the firefox add-on myself, but in the meantime I'm hoping someone else will save me the trouble
In about:config you can enable or disable features individually.
Recently they added ":modal" that will make paywalls harder to bypass. Most sites haven't implement yet, but I've already disabled this "feature" on config.
Every once and a while I have a look at the changelog of the FF dev. It is good way to find the flags to disable features and to have an idea how the web is changing overall.
The downside of cherry picking features is that your browser fingerprint becames pretty much unique.
This take is a disaster. So we get a decade of bloated frameworks to compensate for missing properties and then just when browsers are about to catch up and make all that cruft pointless we get people complaining about it. This isn't a thing. This is some software engineer edgelording. Yeah, we get it, you don't like CSS because you aren't good at it. Just stop.
This reminds me of how the whole philosophy of python is 'simplicity', but the moment you want to start building something you must be reminded of how you haven't updated to the latest version of gnu-anaconda-conda-py-pip3-x86_64-cpython-limited-edition and are consequently prompted to download 5 Gigabytes of inference APIs to print hello world on a distributed multi-cloud pay-for-what-you-use Kubernetes instance .
* the burden of CSS implementation of standards, is mostly on browsers
* the new standards are supposed to be reducing complexity. Nobody wants to go back to hacking rounded corners together. CSS Grid finally gave us a sane way to specify 2D layouts, which were previously all designed by hacking 1D-priority things.
Dockerized environments are a godsend for this problem. I keep a generic docker env that I can clone into a new project in a few keystrokes. Hello world from local in minutes or less, on a recent version of python.
...what mirror-universe version of Python are you using?
One of my two main languages nowadays is Python, mostly deployed on single cloud instances, and it's still a case of writing a text file, sticking a #!/usr/bin/python at the top, and running it.
Obviously if you're doing something that pulls in a ton of dependencies and uses live ever-changing APIs, you're in a much more complicated situation, but Python has never stopped being really darn simple for the simple use cases.
This is Chris Coyier, who launched css-tricks back in 2007 and codepen in 2012. He's worked in this field for over 15 years and is one of the most recognisable figures in the webdev community.
Too much cognitive load, definitely, I do think so. As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve, which means to me, it's laden with baggage. Some new CSS feature pages on MDN are absolutely gigantic in their explanations, and that means that there is a lot of 'talking' required to overcome its unintuitive nature. Of course, once you start using it, it becomes just another tool.
> Too much CSS, possibly.
> Too much cognitive load, definitely, I do think so.
That's a good way to put it. AFter reading those two statements, it started to occur to me that a well-organized concept can have breadth, but not tax one's cognitive facilities. I think of programming languages. They ALL started simple, but then accrete. Look at K&R's original C, then look at C2x. The cognitive load increases. Like you said, "require a historical knowledge"[1].
Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner". Intel & the PC maintained massive backwards compatibility, but parts of the architecture are a nightmare (like the intel instruction decoder); whereas early Apple tossed backwards compatibility routinely for better tech (now they do it for profit, I'm afraid). Same with Windows v. (early) MacOS.
When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there?
[1] (there was a post the other day on HN where a programmer was talking about a text editor and how he used nonprintable unicode to indicate new pages: this young cub had apparently never heard of the first 31 characters of ASCII!!)
> When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there?
The W3Schools page for <frame> says it is not supported in HTML 5 [0]. The MDN page for it warns that it may be removed from browsers at any time, though the compatibility table says it's still supported in every browser.
>Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner".
I think it's pretty much inevitable when use case and/or feature set significantly changes but there's not a comprehensive overhaul of existing work. I think programming languages, code bases, and even cities all have basically the same issue: if the goal or the environment has significantly changed after a lot of work has been done, you're likely to end up with a final product that isn't what you'd choose if you were starting today.
When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there?
Yes; in the early 2000’s, the W3C created XHTML 2.0 [1], a strict XML-based re-implementation of HTML. Because it dropped backwards compatibility to HTML4, it created a lot of backlash that (eventually) resulted in the browser vendors forming their own standards organization (WHATWG) which lead to the creation of HTML5.
I've just started playing around with CSS after a seven year break from web programming and have the opposite impression. The two biggest additions I've seen are flexbox and grid both of which massively decrease the cognitive load—compared to past options, it almost feels like cheating. Moreover, they do this by consciously not building on top of past layout features but instead doing their own thing.
CSS is still a mess of random features that can't be cleanly composed or extended—it's the complete opposite of a language that can grow[1]—but it's a more usable mess than it used to be.
> CSS is still a mess of random features that can't be cleanly composed or extended
The lack of orthogonality and composability has always been the core issue. It's definitely better now, and atomic CSS makes this pretty close to simple.
CSS is still a mess of random features that can't be cleanly composed or extended
If you separate old CSS from new CSS, it’s not so bad.
Yes, CSS has some technical debt from the olden times (like any programming language does) but these days, you need less and less of the old stuff.
For example, all of the alignment stuff created originally for Flexbox (justify-content, align-items, justify-self, etc.) were broken out in their own specification [1] and now CSS Grid and any future specification uses the same terminology to describe how to align something in a box.
Instead of every color model having it's own syntax, which is how CSS started, there's now color functions that can specify any color in any color space [2].
As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve…
Disagree.
The beauty of CSS Grid and Flexbox is that you don’t need to know anything about the hacks and work-arounds which were the industry standard to approximate what these specifications give us today.
The reason why you see seasoned web developers go on and on about how it used to be is due to how unintuitive and fragile those methods were compared to today.
It’s similar to young people today: they don’t need to know anything about using a modem to dial-up to an ISP to access the internet in the age of broadband and Wi-Fi.
> As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve
There's no real way to debug unexpected behavior short of digging through the W3 spec. For example you can't set height / width on inline elements, but you'll never see any error messages or warnings in devtools / IDEs when you try. It doesn't help that tutorials rarely discuss how "layout algorithms" [0] (block, inline, flex, grid) affect certain rules.
No. It's finally getting to be reasonable. The hackarounds are being displaced in droves now.
Ever since CSS grid became a thing, I dumpstered all of the 3rd party web framework stuff I had been using. Placing elements in the right parts of the viewport (across all target devices) has always been 95% of the reason I consumed 3rd party libraries.
Yes, but consider that the broader web is littered with answers to questions predicated on old misunderstandings of CSS. How long will it take for outdated answers on Stack Overflow, Quora, and the SEO farms that rehash Q&A or use AI-generated text to drop from the search rankings?
The information environment is absolutely saturated with pollution from outdated answers to outdated questions. So while CSS might be getting to be reasonable, good luck to the random newbie trying to get things to work.
I found watching Kevin Powell's intro on YouTube really helpful. I already had a basic understanding of grid before watching it, but this helped me make sense of the snippets I'd pieced together in my brain over the last couple of years.
Do you find element placement to be a one and done solution in regards to using grid, flex or table? Or do each have their own use cases? I tend to default to flex for most things because I am very comfortable with it.
I guess I find keeping all the css properties in my head for all the different placement solutions cumbersome, flex and especially grid have a huge amount of functionality and custom properties, and I have been achieving everything fine using flex and a table when I need a literal table of data.
The general rule is that grid is for 2d layout and flex is for 1d layout.
I almost always combine the two by way of a nested hierarchy of elements. Grid is used for the strategic layout, and then within each area I may have flex (or more grid) as appropriate.
As for a "literal table of data", I still use table elements for this exact purpose. I do not use tables for layout anymore, unless its for HTML email.
I've struggled with children sizing in flex. Children take up more space depending on their content. If the content overflows, flex doesn't handle that well either.
Grid seems to handle this better when you specify grid-template-column.
I find myself having to relearn Grid every time I try to use. It actually reminds me a lot of RegEx. Super powerful and helpful but nothing about it sticks in memory.
Me too. But nowadays you can define them with with something like a ascii table.
Also, check "massonary".
There are so many cool features in css being released today that soon that banner "Best viewed on Netscape 3 on 800*600 resolution" may be common in some niche design sites.
But more likely as "Best viewed on Google Canary xxx, on flip screen devices with 10 bit depth colorspace".
By the way, did you know there is a css spec for rounded screen devices?
Yes, because the whole web has become infected with the server side dictating rendering for you instead of just delivering documents and letting the user render how they desire.
Yeah, I would definitely want to write a whole frontend for Facebook before being able to see my feed. But sure, I might as well read through a json response, how great that would be!
Oh god, yes. It's an overlooked culprit (though far from the only culprit, obviously) in web performance and resource use being clown-shoes. We used to be aware that using some CSS features had a serious resource cost on the client side and keep things halfway sane, but it never comes up anymore, while we've added even more ways to eat resources with it.
there's a very old argument in computer science between minimal standards and "batteries included" standards — RISC vs CISC, C vs C++, scheme vs common lisp, Algol W vs Algol 68 etc.
The web community, for whatever reason, is firmly in the "batteries included" camp. CSS alone is approaching the number of built-in symbols as a "big" language like common lisp or Perl. New features are always loudly celebrated, even if they overlap with existing features, are very complicated, and/or serve very niche use cases.
Personally I think we need a "scheme" for the web — a little language that handles all the important pieces (layout, interaction, accessibility) with as little surface area as possible. It would be easier to learn, easier to understand others' code, easier to implement.
Big languages are optimized for copy-and-paste; the more built-in features your language has, the fewer characters you need to steal from a StackOverflow answer. This meshes well with the copy-and-paste culture of web development, so it's likely that web technologies will always be complex this way.
> Personally I think we need a "scheme" for the web
Yes!
And since it's the web, perhaps put some training wheels for newcomers: easy global variables, more familiar syntax... let me time-travel and see how it goes:
time travels
Sorry, turns out those training wheels were a bad idea!
Other than that, please open up your devTools console and tell me: what do you think?
> And that’s where I, myself, land in the end. I’ve made my peace with the fact that I will probably never use — or even know about — all possible CSS features.
Do painters also complain that they are not using all possible colors, shapes and techniques?
Being a backend web developer, for the longest time I felt I could get by using CSS frameworks but now it's so bloody complicated even with the framework.
While I'm glad that CSS is more expressive and hacks are becoming a thing of the past I feel that it is a discipline that I can no longer half ass.
I wonder where it goes from here. Maybe at some point the whole thing will implode, and chrome will come up with a simpler skinning toolkit and people will start using that one and css gets forgotten
No, it's amazing what you can accomplish with CSS now! You used to have to listen for user events with Javascript (later jQuery, around 2006) to add/remove CSS classes. There was no :hover :focus etc.
Today, CSS pseudo-classes cover just about every transition state you need when designing a web application.
I appreciate the approach frameworks like Tailwind are taking to CSS. At first I found it awkward to include so many classes in my markup, but I've come to appreciate the flexibility (without surprising behaviors).
10 years ago, I caused all kinds of headaches for myself by trying to customize .btn with crap like a#sales-promo-1.btn a#sales-promo-2.btn - truly a mess.
For anybody who's as confused as I was: :hover and :focus have been around since CSS2, which was released in 1998 ... but Internet Explorer only supported them on links for a long time, not on arbitrary elements, so that was where jQuery came in.
Ahh, I really really don't miss those days, and I'm rather happy to have reclaimed the giant chunk of memory that used to hold things like quirks mode and hasLayout.
Ahh thank you, I had forgotten the exact details! I still remember the burning frustration like it was yesterday though, hah.
CSS/HTML were my gateway into the tech industry though, so I'm glad I pushed through it. In retrospect, I could see why most "real programmers" were happy to push this tedious work over to me.
All those were in the spec in 2006 (ok not sure about focus pseudo selector but I think so, I mean first-line was supported focus must have been), unfortunately due to MS they were not completely implemented for every element they were specified so and thus the jQuery hacks you remember.
Nope. Flexbox makes it easy to just use plain CSS nowadays. No more SASS or any other preprocessor nonsense. Not even a fan of Tailwind (too much complexity for dubious benefit).
CSS has never been better and now there's just the right amount of it. Also now that there's no more need for crazy JS hacks, you can have just a little bit of JS for interactivity and that's it. Front end development is finally pleasant again.
I’m personally more annoyed at the SVG pollution in modern day frontends. I’m not saying I hate SVGs but why in the heck are we producing 10k like html files by incorporating SVG paths directly into the HTML? There should be a standardized browser protocol to be able to insert SVG via filename and pass it any styling references.
What's wrong with having the SVG embedded in the HTML?
Someone who knows more about the inner workings of network technologies can correct me if I'm wrong, but I would have figured it's better to send a single large file than a bunch of smaller files.
Apparently HTTP2 makes multiple small files much less of a performance issue (or maybe even turns it into a performance gain, I haven't looked into it too closely)
See example here: https://imgur.com/a/XMEkAu1 it's 28 lines total...1 button + 2 svg images, should total 6 lines of code tops! This is my frustration and this is what I call SVG pollution.
It's 28 lines because it's formatted to have every attribute on a different line.
I'd put the <svg> tag and all its attributes on a line, the entirety of the path on a single line, and then with the closing </svg> tag it's reduced to 3 lines.
Since this went by the HN wayside earlier today I thought I would share it amongst people with thoughts on CSS. I made a very absurd hommage to CSS (the language, itself) over the weekend - https://css-magnetic-poetry.tone-row.com/
Definitely not too much CSS IMO. It's a language in flux for sure, but as someone who has been doing frontend for more than a decade, I would rather have 5 ways to accomplish something than 1 way that's a hack and only works on some browsers.
I still remember a time where CSS pundits claimed that the box model was "simple" and if you didn't understand how to make a layout with "float" you were an idiot.
There is a reason why people resorted to tables at the time, because tables were simple to reason about. Grids are kind of tables 2.0 and that float stuff was never good nor simple. So F. you to all the people all these years that claimed there was nothing wrong with CSS, float layouts were a hack and it was bad.
CSS is now actually much much simpler than it used to be, all you need to know as a developer is basically flexbox and/or grids to make beautiful layouts.
CSS can succeed where the DOM failed: CSS can become a great tool that makes using CSS frameworks _unnecessary_, it just needs some kind of module system for scoped CSS rules, which AFAIK doesn't exist in the spec yet.
The web standards stack has become too large, period. Google has way too many people working on Chrome/Chromium. CSS is a relatively small part of the insane strategic complexity they have orchestrated.
By the way, it would interesting to know how many they are now. Has anyone done any stats via Git lately? It was 2000+ in 2015 or so, iirc.
124 comments
[ 3.0 ms ] story [ 86.7 ms ] threadReading "what is new in CSS3" did not help much, but at least flexbox means I don't use howtocenterincss.com any more; while grids became my go-to for all problems, with four attributes that do something about margins and centering but I ignore them out of a lack of memorization.
Then Chrome rose to power, which is repeating some of MS's failures with "their own damn standards" here and there, but is largely avoiding the big failures because the browsers update themselves now. Shy of people being stuck on X version because of their work situation, you don't have to worry about a huge chunks of your userbase being stuck on a 5 year old browser anymore because most folks are getting auto-updated and those updates aren't arbitrarily locked behind OS versions like IE was.
For example…
…Container Queries. (https://www.smashingmagazine.com/2021/05/complete-guide-css-...)
…Cascade Layers. (https://css-tricks.com/css-cascade-layers/#browser-support-a...)
…the :has() selector. (https://www.bram.us/2021/12/21/the-css-has-selector-is-way-m...)
For example, :has() has nearly 83% global support already [1]. Once Firefox enables it by default (it’s behind a flag currently) and more upgrade to the latest versions of macOS and iOS, we’ll soon exceed 90%.
[1]: https://caniuse.com/?search=%3Ahas
It has become very JavaScript-like and this is why I always try to see if I can do something in CSS first before I resort to JS.
[0] https://www.w3.org/TR/css-nesting-1/
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/@keyframes
[2] https://developer.mozilla.org/en-US/docs/Web/CSS/calc
Animation control is where things start to get weird.
In places where CSS takes expressions, they're always declarative, functional expressions; and they're always guaranteed to auto-update when their dependent values update, instantaneously as part of the update to the dependent values. Like an Excel grid-cell.
To me, however constrained "programming" in CSS still is, this makes for far better "programming ergonomics" than JS could ever give me — which, as you say, has me always reaching for a CSS solution before one in JS.
CSS is actually compiled. WebKit uses a Just In Time (JIT) compiler [1]; I suspect all modern web engines do something similar.
[1]: https://webkit.org/blog/3271/webkit-css-selector-jit-compile...
The primary difference between a traditionally compiled language (like C) and CSS and JavaScript is C is compiled before execution and CSS and JavaScript are compiled during execution.
There’s a reason why JIT stands for Just In Time compilation [1].
[1]: https://en.wikipedia.org/wiki/Just-in-time_compilation
The correct difference to make is the execution model, one being basically a Turing machine while the other is more similar to logic programming languages.
If JavaScript is not compiled how does hoisting work?
CSS in my eyes should be able to handle 99% of visual style related needs with ease, JS should be there for the rest.
You’ve pretty much always been able to do this via user style sheets [1], which override author (the author of the website you’re viewing) stylesheets.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Cascade#use...
Recently they added ":modal" that will make paywalls harder to bypass. Most sites haven't implement yet, but I've already disabled this "feature" on config.
The downside of cherry picking features is that your browser fingerprint becames pretty much unique.
The WebKit team first proposed keyframe animation in 2009 [1], so that’s been here for a while.
[1]: https://webkit.org/blog/324/css-animation-2/
* the burden of CSS implementation of standards, is mostly on browsers
* the new standards are supposed to be reducing complexity. Nobody wants to go back to hacking rounded corners together. CSS Grid finally gave us a sane way to specify 2D layouts, which were previously all designed by hacking 1D-priority things.
One of my two main languages nowadays is Python, mostly deployed on single cloud instances, and it's still a case of writing a text file, sticking a #!/usr/bin/python at the top, and running it.
Obviously if you're doing something that pulls in a ton of dependencies and uses live ever-changing APIs, you're in a much more complicated situation, but Python has never stopped being really darn simple for the simple use cases.
This is Chris Coyier, who launched css-tricks back in 2007 and codepen in 2012. He's worked in this field for over 15 years and is one of the most recognisable figures in the webdev community.
Too much cognitive load, definitely, I do think so. As a whole, modern CSS features feel unintuitive and often require a historical knowledge of the problems this new feature X was trying to solve, which means to me, it's laden with baggage. Some new CSS feature pages on MDN are absolutely gigantic in their explanations, and that means that there is a lot of 'talking' required to overcome its unintuitive nature. Of course, once you start using it, it becomes just another tool.
That's a good way to put it. AFter reading those two statements, it started to occur to me that a well-organized concept can have breadth, but not tax one's cognitive facilities. I think of programming languages. They ALL started simple, but then accrete. Look at K&R's original C, then look at C2x. The cognitive load increases. Like you said, "require a historical knowledge"[1].
Do you think this is inevitable? I tend to think languages need major overhauls and backwards-compatibility breaking in order to become "cleaner". Intel & the PC maintained massive backwards compatibility, but parts of the architecture are a nightmare (like the intel instruction decoder); whereas early Apple tossed backwards compatibility routinely for better tech (now they do it for profit, I'm afraid). Same with Windows v. (early) MacOS.
When was the last time there was a major shift away from backwards compatibility in HTML/CSS? I don't think there has been... has there?
[1] (there was a post the other day on HN where a programmer was talking about a text editor and how he used nonprintable unicode to indicate new pages: this young cub had apparently never heard of the first 31 characters of ASCII!!)
The W3Schools page for <frame> says it is not supported in HTML 5 [0]. The MDN page for it warns that it may be removed from browsers at any time, though the compatibility table says it's still supported in every browser.
[0] https://www.w3schools.com/tags/tag_frame.asp
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fr...
I think it's pretty much inevitable when use case and/or feature set significantly changes but there's not a comprehensive overhaul of existing work. I think programming languages, code bases, and even cities all have basically the same issue: if the goal or the environment has significantly changed after a lot of work has been done, you're likely to end up with a final product that isn't what you'd choose if you were starting today.
Yes; in the early 2000’s, the W3C created XHTML 2.0 [1], a strict XML-based re-implementation of HTML. Because it dropped backwards compatibility to HTML4, it created a lot of backlash that (eventually) resulted in the browser vendors forming their own standards organization (WHATWG) which lead to the creation of HTML5.
[1]: https://en.wikipedia.org/wiki/XHTML#XHTML_2.0
CSS is still a mess of random features that can't be cleanly composed or extended—it's the complete opposite of a language that can grow[1]—but it's a more usable mess than it used to be.
[1]: Wonderful talk on language design by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0
The lack of orthogonality and composability has always been the core issue. It's definitely better now, and atomic CSS makes this pretty close to simple.
If you separate old CSS from new CSS, it’s not so bad.
Yes, CSS has some technical debt from the olden times (like any programming language does) but these days, you need less and less of the old stuff.
For example, all of the alignment stuff created originally for Flexbox (justify-content, align-items, justify-self, etc.) were broken out in their own specification [1] and now CSS Grid and any future specification uses the same terminology to describe how to align something in a box.
Instead of every color model having it's own syntax, which is how CSS started, there's now color functions that can specify any color in any color space [2].
[1]: https://drafts.csswg.org/css-align/
[2]: https://drafts.csswg.org/css-color-5/#color-function
Disagree.
The beauty of CSS Grid and Flexbox is that you don’t need to know anything about the hacks and work-arounds which were the industry standard to approximate what these specifications give us today.
The reason why you see seasoned web developers go on and on about how it used to be is due to how unintuitive and fragile those methods were compared to today.
It’s similar to young people today: they don’t need to know anything about using a modem to dial-up to an ISP to access the internet in the age of broadband and Wi-Fi.
There's no real way to debug unexpected behavior short of digging through the W3 spec. For example you can't set height / width on inline elements, but you'll never see any error messages or warnings in devtools / IDEs when you try. It doesn't help that tutorials rarely discuss how "layout algorithms" [0] (block, inline, flex, grid) affect certain rules.
[0] - https://www.joshwcomeau.com/css/understanding-layout-algorit...
I’ve seem dev tools highlight code that either doesn’t make sense or doesn’t have any affect.
I wonder if something like Stylelint [1] would catch this.
[1]: https://stylelint.io
Ever since CSS grid became a thing, I dumpstered all of the 3rd party web framework stuff I had been using. Placing elements in the right parts of the viewport (across all target devices) has always been 95% of the reason I consumed 3rd party libraries.
The information environment is absolutely saturated with pollution from outdated answers to outdated questions. So while CSS might be getting to be reasonable, good luck to the random newbie trying to get things to work.
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
https://developer.mozilla.org/en-US/docs/Web/CSS/grid
https://cssgrid.io/
CSS Tricks also has
https://css-tricks.com/snippets/css/complete-guide-grid/
https://www.youtube.com/watch?v=rg7Fvvl3taU
See csswg
I guess I find keeping all the css properties in my head for all the different placement solutions cumbersome, flex and especially grid have a huge amount of functionality and custom properties, and I have been achieving everything fine using flex and a table when I need a literal table of data.
I almost always combine the two by way of a nested hierarchy of elements. Grid is used for the strategic layout, and then within each area I may have flex (or more grid) as appropriate.
As for a "literal table of data", I still use table elements for this exact purpose. I do not use tables for layout anymore, unless its for HTML email.
Grid seems to handle this better when you specify grid-template-column.
Anybody know a good flex-specific solution?
The searchable keyword for that is "responsive".
Using length units related to viewport size on max-widht may help.
I find myself having to relearn Grid every time I try to use. It actually reminds me a lot of RegEx. Super powerful and helpful but nothing about it sticks in memory.
Also, check "massonary".
There are so many cool features in css being released today that soon that banner "Best viewed on Netscape 3 on 800*600 resolution" may be common in some niche design sites.
But more likely as "Best viewed on Google Canary xxx, on flip screen devices with 10 bit depth colorspace".
By the way, did you know there is a css spec for rounded screen devices?
https://css-tricks.com/snippets/css/complete-guide-grid/
This makes me feel old. We've come full circle. The rediscovery of SSR in the JS community is now considered "new" again.
The web community, for whatever reason, is firmly in the "batteries included" camp. CSS alone is approaching the number of built-in symbols as a "big" language like common lisp or Perl. New features are always loudly celebrated, even if they overlap with existing features, are very complicated, and/or serve very niche use cases.
Personally I think we need a "scheme" for the web — a little language that handles all the important pieces (layout, interaction, accessibility) with as little surface area as possible. It would be easier to learn, easier to understand others' code, easier to implement.
Yes!
And since it's the web, perhaps put some training wheels for newcomers: easy global variables, more familiar syntax... let me time-travel and see how it goes:
time travels
Sorry, turns out those training wheels were a bad idea!
Other than that, please open up your devTools console and tell me: what do you think?
:)
I have similar feelings about javascript. But, I figure I can ignore all new features and worry about learning them when the need for them arises.
Do painters also complain that they are not using all possible colors, shapes and techniques?
While I'm glad that CSS is more expressive and hacks are becoming a thing of the past I feel that it is a discipline that I can no longer half ass.
Today, CSS pseudo-classes cover just about every transition state you need when designing a web application.
I appreciate the approach frameworks like Tailwind are taking to CSS. At first I found it awkward to include so many classes in my markup, but I've come to appreciate the flexibility (without surprising behaviors).
10 years ago, I caused all kinds of headaches for myself by trying to customize .btn with crap like a#sales-promo-1.btn a#sales-promo-2.btn - truly a mess.
Ahh, I really really don't miss those days, and I'm rather happy to have reclaimed the giant chunk of memory that used to hold things like quirks mode and hasLayout.
CSS/HTML were my gateway into the tech industry though, so I'm glad I pushed through it. In retrospect, I could see why most "real programmers" were happy to push this tedious work over to me.
All those were in the spec in 2006 (ok not sure about focus pseudo selector but I think so, I mean first-line was supported focus must have been), unfortunately due to MS they were not completely implemented for every element they were specified so and thus the jQuery hacks you remember.
CSS has never been better and now there's just the right amount of it. Also now that there's no more need for crazy JS hacks, you can have just a little bit of JS for interactivity and that's it. Front end development is finally pleasant again.
Someone who knows more about the inner workings of network technologies can correct me if I'm wrong, but I would have figured it's better to send a single large file than a bunch of smaller files.
I'd put the <svg> tag and all its attributes on a line, the entirety of the path on a single line, and then with the closing </svg> tag it's reduced to 3 lines.
This is how I do embedded SVGs:
https://imgur.com/a/zVVEVps
Note your example also looks way worse because of line wrap
Definitely not too much CSS IMO. It's a language in flux for sure, but as someone who has been doing frontend for more than a decade, I would rather have 5 ways to accomplish something than 1 way that's a hack and only works on some browsers.
There is a reason why people resorted to tables at the time, because tables were simple to reason about. Grids are kind of tables 2.0 and that float stuff was never good nor simple. So F. you to all the people all these years that claimed there was nothing wrong with CSS, float layouts were a hack and it was bad.
CSS is now actually much much simpler than it used to be, all you need to know as a developer is basically flexbox and/or grids to make beautiful layouts.
CSS can succeed where the DOM failed: CSS can become a great tool that makes using CSS frameworks _unnecessary_, it just needs some kind of module system for scoped CSS rules, which AFAIK doesn't exist in the spec yet.
By the way, it would interesting to know how many they are now. Has anyone done any stats via Git lately? It was 2000+ in 2015 or so, iirc.
It has been an amazing journey only to learn the language has evolved gracefully and with a delicacy I really like.
Working with alignment of layout and positioning is much easier. It's implemented nicely.
Another really great thing about css imo is that it has no competition or the same crazy amount of libraries as javascript.
I like where its going.