6 ms·

This looks terrible. Is this really necessary? I feel like purists who write CSS by hand don't want this kind of stuff, because otherwise they'd have switched

• art0rz 3y ago
  The benefit of this is that it runs in the browser. E.g. you can change a CSS variable and the change would propagate to wherever it's being used.
  • deleted 3y ago
    [deleted]
  • est 3y ago
    Who else remembers the expression() from IE5.5 ?
  • lycos 3y ago
    Yeah but only in evergreen browsers once they implement it.. plus now you are making the browser do more work compared to just having simple CSS files that don't have to do complicated things.
    • micromacrofoot 3y ago
      "CSS doesn't have to do complicated things" is already a thing of the past. There are plenty of pseudo selectors and custom properties now that can be quite complex.
    • no_wizard 3y ago
      Speed can be optimized over time, particularly as they collect huge real world usage and can optimize for common patterns. That's one unspoken benefit of having features in the browser vs pushing them to build tools. Its not always appropriate but I feel CSS benefits more often than not for this
    • JoshTriplett 3y ago
      > Yeah but only in evergreen browsers Which browsers that matter aren't evergreen at this point? EDIT: got an answer downthread, apparently at least some sites have to deal with old versions of the mobile Safari engine because of old iPhones/iPads that can't be updated and can't run other browser engines. Another good reason to wish that iPhones/iPads permitted other browsers.
      • lycos 3y ago
        There is no definitive way to answer your question. It depends entirely on your target audience and how much effort your company is willing to put towards support a, I will admit, likely minority. Some of us need to.
        • JoshTriplett 3y ago
          I'm genuinely curious to hear which non-evergreen browsers people are having to support. Niche mobile browsers from ancient Android phones? Some of the more obscure mobile browsers from https://caniuse.com/ciu/comparison https://caniuse.com/ciu/comparison , or even more obscure ones that aren't listed there? To what extent are those platforms unable to support a better browser? For instance, Firefox works all the way back to Android 5.0.
          • lycos 3y ago
            [flagged]
            • JoshTriplett 3y ago
              > and not everyone installs update (or uses devices that can't be updated); That's exactly the kind of example I was looking for, thank you; the idea that people would run iOS and not get Safari updates had not occurred to me, and that's an entirely valid use case and a potentially large user cohort for some sites. Sites with such users would indeed be unable to make immediate use of features just because they're in evergreen browsers. Thanks for the explanation. I know that there are plenty of people out there who are not looking to change their mind. This was not one of those cases. In this case, I was looking to hear the benefit of the experiences behind your comment of "Some of us need to", and hearing it helped me update from "it's safe to rely on evergreen browsers" to "it may still be necessary for some sites to check statistics on usage of old Safari among their users, and adapt accordingly".
    • kevingadd 3y ago
      Parsing a ton of CSS expansions from a preprocessor is likely more expensive in both CPU and RAM than evaluating simple functions.
  • nine_k 3y ago
    Also, the downside of it is that it runs in the browser. The more universally executable code you have to run in a low-trust environment which is a WWW document, the more interesting vulnerabilities can creep in. It's too late though: https://portswigger.net/research/ublock-i-exfiltrate-exploiting-ad-blockers-with-css https://portswigger.net/research/ublock-i-exfiltrate-exploit...
• troupo 3y ago
  I use preprocessors, and I want this in regular CSS precisely because I don't want to run a preprocessor (as it is a yet another tool that I have to set up, configure, update, maintain etc.) SASS is 16 years now. Less is 15. PostCSS is 10. That it took CSS WG this long to adopt useful features from those tools reflects quite poorly on the browsers.
• micromacrofoot 3y ago
  I write a lot of CSS and I'd prefer not to use a preprocessor at all, SASS is great for what it is, but "one less dependency" sounds wonderful.
• wccrawford 3y ago
  When I think of those pre-processors as if they're jQuery, I can see the value of just having this in the browser instead. I wish it was also stacked like SCSS. Maybe some day.
  • lycos 3y ago
    You mean nesting like this proposal? https://www.w3.org/TR/css-nesting-1/ https://www.w3.org/TR/css-nesting-1/
    • wccrawford 3y ago
      Yeah, that's the word I was looking for. :)
  • uallo 3y ago
    CSS nesting is available in all the important browsers today. https://caniuse.com/css-nesting https://caniuse.com/css-nesting
    • wccrawford 3y ago
      Wow. I've been living under a rock. Thanks!
• lelanthran 3y ago
  > Is this really necessary? Yes, because the fewer things you depend on outside of the standard, the better. I like standards, but my recent foray into FE development showed me that FE is an unmitigated disaster. Standardising helps that.
• JoshTriplett 3y ago
  Among many other reasons people have given (including eliminating the need for preprocessors): building this into the browser also allows for optimization, compared to expanding into a huge amount of CSS. If people can send one mixin and twenty invocations of it, rather than 20x the amount of CSS, then that doesn't just save bytes, it potentially allows the browser to directly generate its internal data structures and whatever caches/etc it needs, rather than parsing more textual CSS.
  • mminer237 3y ago
    I feel like eliminating the compilation step adds more client-side processing. Instead of knowing this element gets this rule with this color, it has to do so many function calls just to find out what elements a rule styles, then it has to do all the math to compute all the colors needed just to get to where they're starting right now. Instead of the publisher doing the compilation once as part of its build step, this offloads that compilation to every single visitor.
  • wrs 3y ago
    This will eliminate the need for CSS preprocessors about as much as each annual edition of JavaScript eliminates the need for JS preprocessors.
    • deleted 3y ago
      [deleted]
    • SahAssar 3y ago
      There is only one major JS feature that is missing from modern browsers IMO: type annotations (like https://github.com/tc39/proposal-type-annotations/ https://github.com/tc39/proposal-type-annotations/ or similar) since most people don't want to use JSDoc-based ones. Some people will want JSX too. After those the major use-case for JS preprocessors will for most use-cases only be bundling and minification.
      • wrs 3y ago
        Good to know we have completely run out of ideas and TC39 can disband as soon as they get through with that proposal! /s
• assimpleaspossi 3y ago
  Agreed. This is what javascript is for.
  • deleted 3y ago
    [deleted]
• dimal 3y ago
  I've been hoping for something like this. One of the remaining problems with CSS is that the only native way to reuse any complex functionality is with a class. Classes are applied in the DOM. This is how we end up with utility classes, but utility classes don't mesh well with component based styling, where all your styles for a component live in a file alongside the JS. So I use mixins for style reuse so that I can always look at the component CSS (and follow any explicit imports) to see what styles are applied. If you have some styles from utility classes and some from component-level styles, there's always increased cognitive load because when you're looking at the component CSS you often don't realize that the utility class is there. I get the sense that this is one of the reasons why people like Tailwind. Then there's no confusion - everything is in utility classes, in one place. But I can't read that mess. I need line breaks and separation of concerns. That's just me. This proposal kind of scratches my itch, but from what I can tell, these functions and mixins are still globally defined, so while they're better than utility classes, they still leave a bit to be desired for me. I'd like CSS to behave like any reasonable language and use explicit imports. But I'm sure that getting imports right and avoiding blocking is not an easy problem.