The State of CSS 2019
2019.stateofcss.com
2019.stateofcss.com
This is such a strange picture to paint!
CSS has always been the dim-witted kid. For a long time, it couldn't do math. For a long time, it couldn't have varibles. For a long time, it did not have a reasonable syntax for page layout. Its rules have global visibility (if we don't consider shadow DOM). And those vendor prefixes! This is one hell of a kid!
When you need to handle an almost unlimited range of screen sizes having your visual system able to handle a little math is critical.
Perhaps I'm reading into things, but it seems rather illuminative in terms of understanding how at least some key figures in the development of CSS may have viewed things. If you consider CSS in terms of two distinct audiences--authors/maintainers and users who consume CSS-styled documents--then at least some of the decisions with the CSS specifications seem to make a bit more sense. In which case, it's not so much that CSS didn't need the listed functionality as it is that other goals for the specifications were prioritized over the benefits of variables and other functionality. Reusability, modularity, and simplicity were some of the main priorities. They still are, but I think we've seen a redefinition of those terms with the direction front-end development has taken in the past decade; I also think that improvements in the uniformization of browser implementations and development of better debugging tools has helped erase some of the concerns given in the essay.
That's what I said. Until marketing forces clamored for such things, other less interesting things that weren't sparkles and lollipops took precedence.
CSS has no isolation / encapsulation, no control flow and no local state. Every line of code can modify and affect every other line. And even then, what happens is then dependent on an independently defined DOM object.
Yes, it's possible to write CSS in a way that helps ease the problems that the missing features above cause, but that's working harder to work around the language.
The raison d'etre of CSS, "style independently of the semantic document" is a failed project. It works for DOM trees that can be legitimately considered documents but fails horribly for what can be considered 'applications'. For that reason, I think an overhaul of web document styling is much needed.
The purists will cry that most of what is delivered on the web are "applications" and not "documents", especially when it comes to the morning news, but pretending that isn't the case isn't helpful.
That's because this is what the web was built for. But then everyone wanted to turn it into an application platform by building on top of a document model. Of course CSS was designed to style documents.
Isn't the point of CSS that it's not a programming language? It's just a list of properties, after all.
You can read it from top to bottom and understand what the defined styles will look like when they are rendered.
If your naming is done correctly and your files are separated by features, there is no reason why you can't understand and visualize everything that is defined.
That said I've found it phenomenal for prototyping, simple codepen examples, and teaching css. I run the prototyping efforts at Atlassian and I've built a large amount of code prototyping tools focused on allowing designers to quickly build something out. The standard template I give to designers and students uses stylus by default because it allows them to make mistakes. People who are unfamiliar with code feel defeated when a small syntax error was the one thing holding them back - it makes them question their understanding of the intention of what they wrote, even when the meaning of what they had was correct. Stylus fixes so many of these things for me. I'd highly recommend doing any of your exploratory phases in Stylus.
What do semicolons - or braces, for that matter - have to do with production worthiness? Style inconsistencies do not cause bugs. Poor CSS rules do.
I love stylus, don't get me wrong. I use it for all my projects - even in production. But if I were the head engineer of say, google.com, I wouldn't allow it in production for a codebase that large due to the potential for problems down the line.
Sure a lot of people know lots of clever CSS things, but are we over-complicating things and forgetting the basics of HTML?
This report does not use HTML properly. It is a sea of divs which is all well and good for CSS but not what this whole thing is ultimately about.
The document structure has a main element but this is in the wrong place. According to the HTML spec the main element should be directly below the body element with no extra div wrappers.
Then the page has one nav element. Beyond that it uses none of the sensible HTML5 elements for the content. Nothing is broken down into sections, articles and asides. Graphs are not in figures.
These elements are important, otherwise we might as well just give up and just post images with imagemaps.
Surely some content on the report must be a 'header' or part of what you might call a 'footer'?
I don't get this complacency when it comes to writing HTML, why everything always has to be in a div when the spec says you should only being divs when there are no better elements.
Since this report is entirely written in div soup with one nav element and one badly placed main, they don't know HTML so why should I take seriously what the report says about CSS? It is going to be the same cargo cult stuff.
Anyway, if the spec matters more than the toolchain it should not be anywhere but directly under the body element.
Also, React doesn't require the wrappers.
What happened to keeping it simple? http://motherfuckingwebsite.com/ or http://bettermotherfuckingwebsite.com/
It loaded fine for me... Firefox Focus on OnePlus 6T
Thanks for sharing the interesting results into various usages of css; I learnt about some new things, and found the usage of different things (especially units!) very interesting.
As an aside, the site worked great for me on mobile. Some images were big and slightly awkward to scroll around, but worked just fine.
Couldn't agree more.
I imagine one of the many reasons is because CSS features can't be transpiled but many of JS can.
Grid - 54.5% have used it, 43.2% heard of it, but haven't used it
Flexbox - 94.4% have used it, 4.64% heard of it, but haven't used it
...I wonder how the adoption of CSS grid will play out over time. Are people comfortable enough with flexbox that they don't feel the need to use CSS grid?
The thought of 𝚋𝚘𝚛𝚍𝚎𝚛: 𝟶.𝟸𝚒𝚗 𝚋𝚕𝚊𝚌𝚔; sitting in someone's css is terrifying.
From my own non-CSS based graphics experience, the only problem with layouts specified in absolute sizes is that small lines look really bad on standard (<100dpi) monitors if not aligned to the physical screen pixels. (Not saying that's not bad!)
On your 4k monitor 96 pixels is more than likely not an inch (unless your monitor is slightly over 42 inches), so it wont solve your small app problem in any form, it will just make things more obscure.
In addition to this, you'll also end up with many subpixel values. While this wont matter for 𝚋𝚘𝚛𝚍𝚎𝚛 in the example I posted above (as border always snaps to the nearest dp unit), it will create blurry effects on lower DPI screens for other css rules that do respect subpixel values (i.e. 𝚋𝚘𝚡-𝚜𝚑𝚊𝚍𝚘𝚠: 𝟶 𝟶 𝟶 𝟶.𝟸𝚒𝚗 #𝟶𝟶𝟶; will create a blurred border effect).
That's good to know. My 4k monitor, coincidentally, is about 40.5 inches, so CSS inches are displayed almost correctly.
For the most part, use percentage, `em`, or `rem`. This is based off the the font size, which is more accessible (your app will still look good if someone with poor eyesight changes the font size). It'll also mean your app works well with fractional scaling out of the box. I believe that most desktop-level graphics frameworks like GTK support `em` units. At the very least, on the web, avoid pixel measurement in most cases.
It turns out that device font-size is a good measurement to capture most of the variable parts of user experience -- a pixel dense device that's held close to your eyes will have a small font size, a high resolution monitor that's farther away will have a larger font size -- and `em` will work great in both cases.
At least the inch is a unit whose physical size, by the name, you could assume to not change when screen resolution changes. And also, DPI (or just the physical monitor size) is usually something the user can configure in the operating system - to account for viewing distance or personal preferences.
It's not even an HTML/browser issue. There's a general problem with knowing in software the real-life physical size or length of something displayed on screen. The calibration information available isn't generally reliable, though I think people are paying more attention these days with the growing interest in AR.
More than half of effort is put into improving it. Too little reaches the final stages.
> I defy anyone to explain how they would do it better and still satisfy all the constraints.
I had a rant or two about this in the past: https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-... :)
CSS and HTML still pretend they are just text and images on a paper (or a 2D plane). And this hasn't been the case for over 10 years. As a layout engine CSS still has less capabilities than Delphi or Qt from early 2000.
The ability to have CSS in most browsers (a total of three of them as of 2019 since IE is switching to Chromium) is not really an excuse for the state of CSS.
Qt supports all of those and much more.