9 ms·

The State of CSS 2019

98 points by mhr_online 7y ago

dmitriid 7y ago
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.
- blowski 7y ago
  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.
  - dmitriid 7y ago
    > If half the effort put into shitting on CSS went instead to improving it, maybe it would be perfect by now. 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-7952221fcbe4 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_other 7y ago
      And you can't run Delphi or QT based projects on Windows, macOS, Linux and Haiku, in most of the browsers that run on all those operating systems.
      - dmitriid 7y ago
        You can definitely run Qt on various platforms. That's the whole point of Qt to begin with :) 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.
      - jcelerier 7y ago
        > QT based projects on Windows, macOS, Linux and Haiku, Qt supports all of those and much more.
Liquidor 7y ago
I just can't take this website serious. Is it a parody or a joke? It looks awful and it doesn't even fit on mobile (https://i.imgur.com/6GD8yfD.png https://i.imgur.com/6GD8yfD.png && https://i.imgur.com/lxs0gVG.png https://i.imgur.com/lxs0gVG.png) What happened to keeping it simple? http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/ or http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/
- usrme 7y ago
  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.
- ilikehurdles 7y ago
  It looks pretty perfect on mobile for me on Safari on iOS
- orpheline 7y ago
  > and it doesn't even fit on mobile It loaded fine for me... Firefox Focus on OnePlus 6T
- LoSboccacc 7y ago
  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
- sweece 7y ago
  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.
- txtsd 7y ago
  Works fine in Mozilla's Reference Browser on Honor 7X.
Theodores 7y ago
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.
- okbake 7y ago
  It looks like a <main> element is allowed to have div ancestors: https://html.spec.whatwg.org/multipage/grouping-content.html#hierarchically-correct-main-element https://html.spec.whatwg.org/multipage/grouping-content.html...
  - Theodores 7y ago
    True, you can have as many divs as you want. But it can't be in a more sensible element and there is no good reason with today's CSS layout to want to put it in untold wrappers. Maybe it is a react thing where everything has to be in div wrappers. Anyway, if the spec matters more than the toolchain it should not be anywhere but directly under the body element.
    - korm 7y ago
      The comment you replied to points out that "main" can be inside a div according to the spec. Also, React doesn't require the wrappers.
tangue 7y ago
I'm curious about the 8% of people using cm as a unit in css...
- robin_reala 7y ago
  The same people doing print stylesheets?
  - magicbuzz 7y ago
    Doing metric print stylesheets.
    - ilikehurdles 7y ago
      Even more absurd than metric is those using imperial units.
      - deleted 7y ago
        [deleted]
  - tangue 7y ago
    Of course. I thought it was a lost art but it makes sense.
- thomasfedb 7y ago
  While I prefer millimeters, I do find using measures of physical length useful when mocking up paper forms in CSS.
hornet-run 7y ago
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.
- Sahhaese 7y ago
  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.
  - rimliu 7y ago
    Maybe web tech for applications is the failed project, not the CSS.
  - goatlover 7y ago
    > It works for DOM trees that can be legitimately considered documents 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.
  - hkai 7y ago
    Many people heard your pain so this is why in Vue.js CSS is isolated, while in react you can use styled components for encapsulation, sort of.
Cogito 7y ago
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.
btbuildem 7y ago
Why is my laptop suddenly cooking when I'm just reading that page?
thex10 7y ago
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?!)
jjcm 7y ago
I think the most offensive thing here is that 6.2% of people use inches as a unit of measure in their css. The thought of 𝚋𝚘𝚛𝚍𝚎𝚛: 𝟶.𝟸𝚒𝚗 𝚋𝚕𝚊𝚌𝚔; sitting in someone's css is terrifying.
- blowski 7y ago
  I've used inches when doing print-based CSS, although I'd be surprised if that accounts for all of it.
- jstimpfle 7y ago
  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!)
  - jjcm 7y ago
    Inches in css aren't in any way related to physical inches. CSS has no knowledge of your physical screen dimensions. Rather an inch was defined early on in the history of css as "1 inch in pixels of a 17 inch screen at 1280x1024 resolution" This happens to be 96.42 pixels, which rounded down to 96. So not only is it an obscure unit, it's also a misleading one. 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).
    - ChrisSD 7y ago
      That said, Mozilla did use to have the experimental `mozmm` unit that attempted to accurate represent the millimetre. However it was removed a few versions back.
jjcm 7y ago
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.
- azangru 7y ago
  > 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. What do semicolons - or braces, for that matter - have to do with production worthiness? Style inconsistencies do not cause bugs. Poor CSS rules do.
  - jjcm 7y ago
    Inconsistencies in the source file do not affect production worthiness in the moment, but they do affect maintainability down the line. If for instance your team wants to move to a new css preprocessor that's the next big thing in 10 years, a consistent style means you can programatically convert to the new syntax. Or maybe there's a tool that can help you write better css and detect where rules are unused -variable syntax will be sand in the gears for something like that. Mishmoshed syntax everywhere is a nightmare for programatic accessibility, though is excellent for simply trying things out. 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.
azangru 7y ago
> 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!
- sureaboutthis 7y ago
  For a long time, it didn't need any of those things. It's only been a recent need for marketing, mainly.
  - actionscripted 7y ago
    Not even close. Marketing has lead to some absurd uses of CSS but it's more about adaptive/responsive design. When you need to handle an almost unlimited range of screen sizes having your visual system able to handle a little math is critical.
    - sureaboutthis 7y ago
      First there was marketing. Then there was adaptive design. And variables are new compared to almost everything else.
      - Bluestrike2 7y ago
        There's a CSS & FP Working Group note that listed variables--or more specifically, symbolic constants--as a proposed future extension to CSS2 back in 1998,[0] and I'd assume that there are even earlier discussions on the matter as well. The idea of using variables in CSS isn't new by any means. If you read this 2008 essay by Bert Bos[1] against extending CSS to include variables Bos makes a really intriguing comment that "macros help for authors, not for the semantic Web" in his conclusion. 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. 0. https://www.w3.org/TR/NOTE-CSS-potential#id05684046681 https://www.w3.org/TR/NOTE-CSS-potential#id05684046681 1. https://www.w3.org/People/Bos/CSS-variables https://www.w3.org/People/Bos/CSS-variables
sweece 7y ago
Given the results on layout tools: 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?
pier25 7y ago
> 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.

98 points by mhr_online 7y ago

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.

blowski 7y ago
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.
- dmitriid 7y ago
  > If half the effort put into shitting on CSS went instead to improving it, maybe it would be perfect by now. 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-7952221fcbe4 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_other 7y ago
    And you can't run Delphi or QT based projects on Windows, macOS, Linux and Haiku, in most of the browsers that run on all those operating systems.
    - dmitriid 7y ago
      You can definitely run Qt on various platforms. That's the whole point of Qt to begin with :) 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.
    - jcelerier 7y ago
      > QT based projects on Windows, macOS, Linux and Haiku, Qt supports all of those and much more.

Liquidor 7y ago

I just can't take this website serious. Is it a parody or a joke? It looks awful and it doesn't even fit on mobile (https://i.imgur.com/6GD8yfD.png https://i.imgur.com/6GD8yfD.png && https://i.imgur.com/lxs0gVG.png https://i.imgur.com/lxs0gVG.png) What happened to keeping it simple? http://motherfuckingwebsite.com/ http://motherfuckingwebsite.com/ or http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/

usrme 7y ago
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.
ilikehurdles 7y ago
It looks pretty perfect on mobile for me on Safari on iOS
orpheline 7y ago
> and it doesn't even fit on mobile It loaded fine for me... Firefox Focus on OnePlus 6T
LoSboccacc 7y ago
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
sweece 7y ago
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.
txtsd 7y ago
Works fine in Mozilla's Reference Browser on Honor 7X.

Theodores 7y ago

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.

okbake 7y ago
It looks like a <main> element is allowed to have div ancestors: https://html.spec.whatwg.org/multipage/grouping-content.html#hierarchically-correct-main-element https://html.spec.whatwg.org/multipage/grouping-content.html...
- Theodores 7y ago
  True, you can have as many divs as you want. But it can't be in a more sensible element and there is no good reason with today's CSS layout to want to put it in untold wrappers. Maybe it is a react thing where everything has to be in div wrappers. Anyway, if the spec matters more than the toolchain it should not be anywhere but directly under the body element.
  - korm 7y ago
    The comment you replied to points out that "main" can be inside a div according to the spec. Also, React doesn't require the wrappers.

tangue 7y ago

I'm curious about the 8% of people using cm as a unit in css...

robin_reala 7y ago
The same people doing print stylesheets?
- magicbuzz 7y ago
  Doing metric print stylesheets.
  - ilikehurdles 7y ago
    Even more absurd than metric is those using imperial units.
    - deleted 7y ago
      [deleted]
- tangue 7y ago
  Of course. I thought it was a lost art but it makes sense.
thomasfedb 7y ago
While I prefer millimeters, I do find using measures of physical length useful when mocking up paper forms in CSS.

hornet-run 7y ago

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.

Sahhaese 7y ago
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.
- rimliu 7y ago
  Maybe web tech for applications is the failed project, not the CSS.
- goatlover 7y ago
  > It works for DOM trees that can be legitimately considered documents 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.
- hkai 7y ago
  Many people heard your pain so this is why in Vue.js CSS is isolated, while in react you can use styled components for encapsulation, sort of.

Cogito 7y ago

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.

btbuildem 7y ago

Why is my laptop suddenly cooking when I'm just reading that page?

thex10 7y ago

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?!)

jjcm 7y ago

I think the most offensive thing here is that 6.2% of people use inches as a unit of measure in their css. The thought of 𝚋𝚘𝚛𝚍𝚎𝚛: 𝟶.𝟸𝚒𝚗 𝚋𝚕𝚊𝚌𝚔; sitting in someone's css is terrifying.

blowski 7y ago
I've used inches when doing print-based CSS, although I'd be surprised if that accounts for all of it.
jstimpfle 7y ago
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!)
- jjcm 7y ago
  Inches in css aren't in any way related to physical inches. CSS has no knowledge of your physical screen dimensions. Rather an inch was defined early on in the history of css as "1 inch in pixels of a 17 inch screen at 1280x1024 resolution" This happens to be 96.42 pixels, which rounded down to 96. So not only is it an obscure unit, it's also a misleading one. 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).
  - ChrisSD 7y ago
    That said, Mozilla did use to have the experimental `mozmm` unit that attempted to accurate represent the millimetre. However it was removed a few versions back.

jjcm 7y ago

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.

azangru 7y ago
> 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. What do semicolons - or braces, for that matter - have to do with production worthiness? Style inconsistencies do not cause bugs. Poor CSS rules do.
- jjcm 7y ago
  Inconsistencies in the source file do not affect production worthiness in the moment, but they do affect maintainability down the line. If for instance your team wants to move to a new css preprocessor that's the next big thing in 10 years, a consistent style means you can programatically convert to the new syntax. Or maybe there's a tool that can help you write better css and detect where rules are unused -variable syntax will be sand in the gears for something like that. Mishmoshed syntax everywhere is a nightmare for programatic accessibility, though is excellent for simply trying things out. 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.

azangru 7y ago

> 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!

sureaboutthis 7y ago
For a long time, it didn't need any of those things. It's only been a recent need for marketing, mainly.
- actionscripted 7y ago
  Not even close. Marketing has lead to some absurd uses of CSS but it's more about adaptive/responsive design. When you need to handle an almost unlimited range of screen sizes having your visual system able to handle a little math is critical.
  - sureaboutthis 7y ago
    First there was marketing. Then there was adaptive design. And variables are new compared to almost everything else.
    - Bluestrike2 7y ago
      There's a CSS & FP Working Group note that listed variables--or more specifically, symbolic constants--as a proposed future extension to CSS2 back in 1998,[0] and I'd assume that there are even earlier discussions on the matter as well. The idea of using variables in CSS isn't new by any means. If you read this 2008 essay by Bert Bos[1] against extending CSS to include variables Bos makes a really intriguing comment that "macros help for authors, not for the semantic Web" in his conclusion. 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. 0. https://www.w3.org/TR/NOTE-CSS-potential#id05684046681 https://www.w3.org/TR/NOTE-CSS-potential#id05684046681 1. https://www.w3.org/People/Bos/CSS-variables https://www.w3.org/People/Bos/CSS-variables

sweece 7y ago

Given the results on layout tools: 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?

pier25 7y ago

> 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.