Is there too much CSS now?
css-tricks.com
css-tricks.com
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.
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?
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 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.
CSS Tricks also has
See csswg
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.
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
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].
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.
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.
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...
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 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.
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
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
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].
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.
The WebKit team first proposed keyframe animation in 2009 [1], so that’s been here for a while.
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.
Animation control is where things start to get weird.
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%.
I think most people dislike it nowadays because it requires two skillsets: visual creativity and technical aptitude (most people can only fulfill one of those halves).
It can be easy to project shortcomings in visual creativity onto the language which I don't think is very fair but I tend to see often being at the root of people's dismissals of the language.
If you're just taking designs from someone else and implementing them, the CSS part of front-end is comparatively easy to what it was just a decade and change ago. It's still not perfect (and never will be with competing browser vendors/rendering engines), but the time investment to implement complex designs is substantially less than it was. That's a win.
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.
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.
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.
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.
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:
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.
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.
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?
:)
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.
Do painters also complain that they are not using all possible colors, shapes and techniques?
This makes me feel old. We've come full circle. The rediscovery of SSR in the JS community is now considered "new" again.
2. The CSS WG at W3C must deliver formal specification rather than the prose they're writing up now. For an idea how a (partial) formal spec for CSS rendering looks like, see eg. [1], [2] (with limitations).
The one way complexity that both W3C and WHATWG have delivered over the past 15 years with complete lack of mental discipline due to financial dependency/job security will be a major source of confusion for generations to come, and will not be looked at favorably.
* 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.
CSS is bloated because it needs to be bloated, do you remember the days before CSS? no, well we use to relay a lot from the HTML Spec (thats why some ppl kept pushing for some weird things like xhtml), we had to put in the all the elements HTML all the styles for every element on the website (and it wasn't like today that you put style tag and of you go), we had specific pourpose html elements (marquee, center, etc) to do certain things and it was a mess, as soon as CSS was available every developer started demanding it, Microsoft/IE couldn't keep up with the other browsers so he delivered a half-assed implementation (because they were pushing for activex/com shenanigans), that's were the infamous "css hacks" were born, because every major browser were luring users with features that devs had to support if their website aimed to be worldwide accessible, m so old for this shit that i remember Opera being loud on the ACID thing, it even went to my school to promote the CSS level support.
Now lets get back to 2022, all browsers politically agree to implement the things everyone wants, there are still half-assed solutions and workarounds (for older browser support, mainly Sucksfari), but the browser wars are over the winner was webkit=>chromium, now we live in the post war era, nobody wants to touch anything old because it might break the internet (and start another browser support war), so they keep pushing for new things build on top of old things (thats why we have a confusing state of what is better flex vs grid or the fact that we still need a css reset) because some old website (facebook, google, microsoft, etc.) has a vote on the w3c/whatwg table.
The solution? you might not like... lets break the internet, start deprecating the things and start promoting the new ones. Lets get rid of Safari!
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.
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 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.
At least I can have fun with WebGL/WebGPU, even if they lag behind native 3D APIs.
I'm going on a stretch here and say that the html part of the interwebs is transitioning back to simpler and less dynamic hypertext documents with a lot less UI fluff. The strength of html are it's textual hypertext capabilities.
Also, with Webassembly I do not see the point of expanding the UI capabilities of html.