> CSS on the other hand has always been the studious, well-behaved kid who always stays polite and never makes a rash decision
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!
There's a missing feature. Look at a css page and know how the site will behave. Every programing language you look at code (if well written) and u know what it will do. In css you know what are the attributes set but it doesn't really tell you what is going you happen. That's the only thing I don't like in css.
This is the killer reason why I hate doing anything with CSS. There's close to zero predictability.
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.
What layout system/language would work in a readable manner? To me layout is basically a way to express a set of constraints which can be sometimes contradictory. In CSS a problem rises because the system will always manage to resolve them, somehow, and there are no warnings. LaTeX or AutoLayout will help you write an unambiguous layout, but they are still inscrutable at a glance.
CSS is a list of declarations. There is nothing esoteric about it.
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.
Unsurprisingly Stylus is one of the preprocessors that people want to avoid the most (beating less by 1% in user satisfaction). The preprocessor is very apathetic to what style you use - it's the antithesis of a linter. Want to use a semicolon on this line, and not one on the next? Go for it! Not the best when you want to write something production worthy.
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.
The HTML in the report tells me as much about the state of CSS as what is in the report.
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.
Won't comment about whether it looks awful or not, but in terms of the mobile experience it seems to work fine for me on my OnePlus 6T with Firefox Focus, and subsequent tests on desktop using the Responsive Design Mode in Firefox with various size also worked as expected.
I mean, even before getting to not responsive the choice of colours is annoying: two not so distant shades of blue, a joy to watch on mobile, especially with the blur shadow added to headers
There is such a thing as a bug or oversight and you found one. No need to get carried away w/ the blame game. Lots of other devices are experiencing this site just fine.
Well.. as a developer who probably works more with CSS and HTML than anything else, I really enjoyed this report. I found the visualizations and even the overall design provocative, and I even learned a few things in the process (overscroll-behavior?!)
If this was a photo pasted into word that was then printed and faxed it wouldn’t make the content any less meaningful.
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.
> JavaScript has developed a bit of a reputation as the angry, rebellious teenager going through a new phase every year and telling you you're just too old to understand.
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?
As someone who hasn't done CSS in a while, with a 4K monitor and the knowledge how old pixel-based desktop apps look on it (VERY small), what's wrong with inches?
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!)
Kinda all you need to know about the state of CSS in 2019: the menu’s bottom items cannot be accessed on mobile Safari. Also: the scrolling is awkward/broken.
If half the effort put into shitting on CSS went instead to improving it, maybe it would be perfect by now. The requirements of CSS as a language are insanely complicated - open source, implemented by different browsers, on all different devices, for applications doing a huge variety of things, working with 20 years of legacy code. I defy anyone to explain how they would do it better and still satisfy all the constraints.
[+] [-] azangru|6 years ago|reply
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!
[+] [-] celticmusic|6 years ago|reply
[+] [-] sureaboutthis|6 years ago|reply
[+] [-] hornet-run|6 years ago|reply
[+] [-] Sahhaese|6 years ago|reply
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.
[+] [-] yoz-y|6 years ago|reply
[+] [-] rawTruthHurts|6 years ago|reply
Isn't the point of CSS that it's not a programming language? It's just a list of properties, after all.
[+] [-] Raphmedia|6 years ago|reply
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.
[+] [-] jjcm|6 years ago|reply
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.
[+] [-] azangru|6 years ago|reply
What do semicolons - or braces, for that matter - have to do with production worthiness? Style inconsistencies do not cause bugs. Poor CSS rules do.
[+] [-] Theodores|6 years ago|reply
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.
[+] [-] okbake|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] douglaswlance|6 years ago|reply
[+] [-] Liquidor|6 years ago|reply
What happened to keeping it simple? http://motherfuckingwebsite.com/ or http://bettermotherfuckingwebsite.com/
[+] [-] usrme|6 years ago|reply
[+] [-] LoSboccacc|6 years ago|reply
[+] [-] sweece|6 years ago|reply
[+] [-] ilikehurdles|6 years ago|reply
[+] [-] orpheline|6 years ago|reply
It loaded fine for me... Firefox Focus on OnePlus 6T
[+] [-] txtsd|6 years ago|reply
[+] [-] thex10|6 years ago|reply
[+] [-] Cogito|6 years ago|reply
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.
[+] [-] btbuildem|6 years ago|reply
[+] [-] tangue|6 years ago|reply
[+] [-] robin_reala|6 years ago|reply
[+] [-] thomasfedb|6 years ago|reply
[+] [-] pier25|6 years ago|reply
Couldn't agree more.
I imagine one of the many reasons is because CSS features can't be transpiled but many of JS can.
[+] [-] sweece|6 years ago|reply
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?
[+] [-] jjcm|6 years ago|reply
The thought of 𝚋𝚘𝚛𝚍𝚎𝚛: 𝟶.𝟸𝚒𝚗 𝚋𝚕𝚊𝚌𝚔; sitting in someone's css is terrifying.
[+] [-] jstimpfle|6 years ago|reply
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!)
[+] [-] blowski|6 years ago|reply
[+] [-] jmull|6 years ago|reply
[+] [-] Nicksil|6 years ago|reply
[+] [-] edflsafoiewq|6 years ago|reply
[+] [-] dmitriid|6 years ago|reply
[+] [-] blowski|6 years ago|reply