5 ms·

:root { --laptop-content: ... Huh. Interesting that I never noticed that CSS supported variables like this. I haven't worked on a Web front-end for some

by jolmg 7y ago

:root { --laptop-content: ... Huh. Interesting that I never noticed that CSS supported variables like this. I haven't worked on a Web front-end for some time, but I see that this has been pretty portable since late 2017. I remember that one of the big points of using CSS preprocessors like Sass was being able to use variables. Now, it seems they're a little less useful.

nicoburns 7y ago
Sadly not portable enough if you need to support IE. Give it a few more years though.
- eitland 7y ago
  Does frontend developers care? It seems to me a lot of frontend developers has a hard time wrapping their head around the fact that there exist millions of users who prefer other browsers than Chrome :-/ Full disclosure: I sometimes work on frontend myself, I have talked to such developers.
  - jolmg 7y ago
    On average? No. It's easier for developers to target only one platform and switching browsers is easy enough for the average user that developers don't see much problem in putting the blame on the browser. Chrome also has greater marketing power backing it than other browsers, so it's the easy choice. That's what happens. Should you care? I think yes. I don't want the internet to be at the whims of a single entity. It's like authoritarianism vs democracy or having a monopolistic market vs a competitive one. What's best for the tech ecosystem isn't something the average developer thinks or cares about, though. When I show my co-workers how our front-end breaks when using Firefox, they often mistake my concern of portability to be favoritism towards Firefox. I'd use other browsers, but it would just make it harder to convince them to take the bugs seriously.
    - eitland 7y ago
      Sad thing is we fought so hard back in 2006-2009 to get to get past bosses and clients who wanted us to just make it work in IE, and here we are a decade later and those who should be building on our work are tearing it apart by carelessness. Edit: if any frontend/web developers today reads this, please do use Firefox for development. I'll tell you why: I can only remember a single time that I wrote something in Firefox that didn't also work in the latest IE, Chrome and Edge. Web developers I work with who use Chrome however seems to constantly have to go back and fix stuff that doesn't work anywhere but Chrome, exactly like web developers who developed in Frontpage and IE had to. If you don't want to spend time with regressions from QA and you don't want to look unprofessional, develop on Firefox. The happy feeling you get from doing something good for the web is a bonus.
      - jolmg 7y ago
        I'm full-stack, as they say, but have been working almost exclusively on the back-end for the last couple of years. I don't think I remember a time when I did something in the front-end that resulted in it working in Firefox but not on Chrome, so you might be right, but I may also simply not remember.
        eitland 7y ago
        I didn't intend it on you personally jolmg, but rather generally frontenders who read it :-) Will update to make it clear.
- deleted 7y ago
  [deleted]
- acdha 7y ago
  Or load a polyfill only for IE11 users so you can write modern code without orphaning them: https://github.com/jhildenbiddle/css-vars-ponyfill https://github.com/jhildenbiddle/css-vars-ponyfill
dmix 7y ago
Frontend developers have been using PostCSS for the transition period until this is fully adopted (which is a library set similar to Babel for adopting future JS, as well as experimenting with new CSS language level ideas): https://github.com/MadLittleMods/postcss-css-variables https://github.com/MadLittleMods/postcss-css-variables There’s also plugins for nesting and mixins if you want a more complete SASS replacement which seems to be the toolset the industry is moving towards. The most popular PostCSS library is autoprefixer which is also helping with the transition to future CSS without all of the browser baggage. https://github.com/postcss/autoprefixer https://github.com/postcss/autoprefixer
_bxg1 7y ago
And unlike preprocessor variables, they: 1) Cascade (follow inheritance through the DOM) 2) Can be changed at runtime for things like toggling a dark theme Preprocessors are still useful for other things, though. My #1 reason for using them is nested selectors, which for reasons I cannot understand haven't made it into native CSS yet.
- jolmg 7y ago
  > nested selectors, which for reasons I cannot understand haven't made it into native CSS yet. As I understand it, browsers don't look at a selector and navigate, but rather go node by node and see what selectors match. Having complex selectors that require looking at parents and siblings is worse, performance-wise, than having a simple selector. I imagine nested selectors don't make it into CSS, because people don't want to further encourage the use of complex selectors. Here, this is where I read about that: https://web.archive.org/web/20150304005354/https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS#How_the_Style_System_Matches_Rules https://web.archive.org/web/20150304005354/https://developer...
  - _bxg1 7y ago
    Except that nested selectors trivially convert to traditional selectors. i.e.: .container { .line { input { } button { } } } corresponds to: .container .line input { } .container .line button { } So there could just be a really simple internal translation step, if that's needed for performance reasons.
    - jolmg 7y ago
      No, I think you misunderstood. The concern is not for the translation, but rather that for every <input> node, it would have to check if it has an ancestor node that has the class "line", and then an ancestor node that has the class "container". It's more efficient, in the case of a complete selector like "#person_name", to simply see if a given node has that id. This makes simple selectors more favorable than complex selectors that depend on node hierarchical interrelationships, so it's best to have a syntax that favors having simple selectors, than a syntax that encourages bad, complex selectors.
Cyberdog 7y ago
That's new to me too. For others curious, here's the developer.mozilla.org page on it: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c... And the CanIUse table: https://caniuse.com/#feat=css-variables https://caniuse.com/#feat=css-variables I look forward to starting to use this in 2024.
- skinnymuch 7y ago
  The caniuse site itself doesn’t properly work on my modern updated iPhone. The modals won’t go away. If a modal appears and it’s hidden behind the footer, I can’t read the rest of it. Yet it seems to be a site widely used and referenced. Along with the 90%+ prevalence of it working on browsers, isn’t the joke mostly moot? Besides Chinese browsers and old IE/Edge, support seems to be fine. I don’t know exactly what Microsoft is doing with Edge Chromium on Windows 7/8, but if that’s pushed through more, the support is essentially universal if you’re not targeting the two Chinese focused browsers.
  - acdha 7y ago
    This is a problem specific to your iPhone — perhaps an over-zealous content blocker? If you can figure out what's different from a clean install, report it at https://github.com/Fyrd/caniuse/issues https://github.com/Fyrd/caniuse/issues.

by jolmg 7y ago

nicoburns 7y ago

Sadly not portable enough if you need to support IE. Give it a few more years though.

eitland 7y ago
Does frontend developers care? It seems to me a lot of frontend developers has a hard time wrapping their head around the fact that there exist millions of users who prefer other browsers than Chrome :-/ Full disclosure: I sometimes work on frontend myself, I have talked to such developers.
- jolmg 7y ago
  On average? No. It's easier for developers to target only one platform and switching browsers is easy enough for the average user that developers don't see much problem in putting the blame on the browser. Chrome also has greater marketing power backing it than other browsers, so it's the easy choice. That's what happens. Should you care? I think yes. I don't want the internet to be at the whims of a single entity. It's like authoritarianism vs democracy or having a monopolistic market vs a competitive one. What's best for the tech ecosystem isn't something the average developer thinks or cares about, though. When I show my co-workers how our front-end breaks when using Firefox, they often mistake my concern of portability to be favoritism towards Firefox. I'd use other browsers, but it would just make it harder to convince them to take the bugs seriously.
  - eitland 7y ago
    Sad thing is we fought so hard back in 2006-2009 to get to get past bosses and clients who wanted us to just make it work in IE, and here we are a decade later and those who should be building on our work are tearing it apart by carelessness. Edit: if any frontend/web developers today reads this, please do use Firefox for development. I'll tell you why: I can only remember a single time that I wrote something in Firefox that didn't also work in the latest IE, Chrome and Edge. Web developers I work with who use Chrome however seems to constantly have to go back and fix stuff that doesn't work anywhere but Chrome, exactly like web developers who developed in Frontpage and IE had to. If you don't want to spend time with regressions from QA and you don't want to look unprofessional, develop on Firefox. The happy feeling you get from doing something good for the web is a bonus.
    - jolmg 7y ago
      I'm full-stack, as they say, but have been working almost exclusively on the back-end for the last couple of years. I don't think I remember a time when I did something in the front-end that resulted in it working in Firefox but not on Chrome, so you might be right, but I may also simply not remember.
      - eitland 7y ago
        I didn't intend it on you personally jolmg, but rather generally frontenders who read it :-) Will update to make it clear.
deleted 7y ago
[deleted]
acdha 7y ago
Or load a polyfill only for IE11 users so you can write modern code without orphaning them: https://github.com/jhildenbiddle/css-vars-ponyfill https://github.com/jhildenbiddle/css-vars-ponyfill

dmix 7y ago

Frontend developers have been using PostCSS for the transition period until this is fully adopted (which is a library set similar to Babel for adopting future JS, as well as experimenting with new CSS language level ideas): https://github.com/MadLittleMods/postcss-css-variables https://github.com/MadLittleMods/postcss-css-variables There’s also plugins for nesting and mixins if you want a more complete SASS replacement which seems to be the toolset the industry is moving towards. The most popular PostCSS library is autoprefixer which is also helping with the transition to future CSS without all of the browser baggage. https://github.com/postcss/autoprefixer https://github.com/postcss/autoprefixer

_bxg1 7y ago

And unlike preprocessor variables, they: 1) Cascade (follow inheritance through the DOM) 2) Can be changed at runtime for things like toggling a dark theme Preprocessors are still useful for other things, though. My #1 reason for using them is nested selectors, which for reasons I cannot understand haven't made it into native CSS yet.

jolmg 7y ago
> nested selectors, which for reasons I cannot understand haven't made it into native CSS yet. As I understand it, browsers don't look at a selector and navigate, but rather go node by node and see what selectors match. Having complex selectors that require looking at parents and siblings is worse, performance-wise, than having a simple selector. I imagine nested selectors don't make it into CSS, because people don't want to further encourage the use of complex selectors. Here, this is where I read about that: https://web.archive.org/web/20150304005354/https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS#How_the_Style_System_Matches_Rules https://web.archive.org/web/20150304005354/https://developer...
- _bxg1 7y ago
  Except that nested selectors trivially convert to traditional selectors. i.e.: .container { .line { input { } button { } } } corresponds to: .container .line input { } .container .line button { } So there could just be a really simple internal translation step, if that's needed for performance reasons.
  - jolmg 7y ago
    No, I think you misunderstood. The concern is not for the translation, but rather that for every <input> node, it would have to check if it has an ancestor node that has the class "line", and then an ancestor node that has the class "container". It's more efficient, in the case of a complete selector like "#person_name", to simply see if a given node has that id. This makes simple selectors more favorable than complex selectors that depend on node hierarchical interrelationships, so it's best to have a syntax that favors having simple selectors, than a syntax that encourages bad, complex selectors.

Cyberdog 7y ago

That's new to me too. For others curious, here's the developer.mozilla.org page on it: https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c... And the CanIUse table: https://caniuse.com/#feat=css-variables https://caniuse.com/#feat=css-variables I look forward to starting to use this in 2024.

skinnymuch 7y ago
The caniuse site itself doesn’t properly work on my modern updated iPhone. The modals won’t go away. If a modal appears and it’s hidden behind the footer, I can’t read the rest of it. Yet it seems to be a site widely used and referenced. Along with the 90%+ prevalence of it working on browsers, isn’t the joke mostly moot? Besides Chinese browsers and old IE/Edge, support seems to be fine. I don’t know exactly what Microsoft is doing with Edge Chromium on Windows 7/8, but if that’s pushed through more, the support is essentially universal if you’re not targeting the two Chinese focused browsers.
- acdha 7y ago
  This is a problem specific to your iPhone — perhaps an over-zealous content blocker? If you can figure out what's different from a clean install, report it at https://github.com/Fyrd/caniuse/issues https://github.com/Fyrd/caniuse/issues.