1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

CSS has supported native mixins for over a decade?!?

Discussion in 'CSS' started by deathshadow, Dec 25, 2022.

  1. #1
    deathshadow, Dec 25, 2022 IP
  2. qwikad.com

    qwikad.com Illustrious Member Affiliate Manager

    Messages:
    7,151
    Likes Received:
    1,656
    Best Answers:
    29
    Trophy Points:
    475
    #2
    Since I've never heard about mixins and what they do, looking at the codepen example, what am I supposed to see they do?
     
    qwikad.com, Dec 25, 2022 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #3
    They let you declare entire sets of reusable properties. In LESS/SASS/SCSS they usually look something like:

    
    @mixin maxWidth {
      width:100%;
      max-width:64em;
      margin:0 auto;
    }
    
    main > section,
    main > div {
      @include maxWidth;
    }
    
    Code (markup):
    Which seems pointless since behavior-wise that's identical to:
    
    main > section,
    main > div {
      width:100%;
      max-width:64em;
      margin:0 auto;
    }
    
    Code (markup):
    For a long time I thought they were completely useless on those grounds... but let's use the example of how you might have a modal driven site where the main menu is normally in the header, but when the screen gets too narrow for that it becomes a modal like others on the page. Because the main menu is only a modal below a certain width, you only want to apply its values -- identical to normal ones -- inside a media query.

    Thus you end up with a repetitive mess like:

    
    .modal {
      position:fixed;
      top:0;
      left:-100vw;
      width:100%;
      height:100%;
      overflow:auto;
      background:rgba(240,240,240,0.8);
      opacity:0;
      transition:left 0s 0.5s, opacity:0.5s;
    }
    
    .modal:target {
      left:0;
      opacity:1;
      transition:opacity 0.5s;
    }
    
    @media (max-width:32rem) {
    
     #mainMenu {
         position:fixed;
         top:0;
         left:-100vw;
         width:100%;
         height:100%;
         overflow:auto;
         background:rgba(240,240,240,0.8);
         opacity:0;
         transition:left 0s 0.5s, opacity:0.5s;
      }
    
      #mainMenu:target {
         left:0;
         opacity:1;
         transition:opacity 0.5s;
      }
    }
    
    Code (markup):
    SUCKS!!! And without mixins that's really the only way to do it... is to write the same code twice with different selectors.

    This is actually about the only place I'd really ever "want" mixins.

    With SCSS style code providing mixins, that gets reduced to:

    
    @mixin modal {
      position:fixed;
      top:0;
      left:-100vw;
      width:100%;
      height:100%;
      overflow:auto;
      background:rgba(240,240,240,0.8);
      opacity:0;
      transition:left 0s 0.5s, opacity:0.5s;
    }
    
    @mixin modalOpen {
      left:0;
      opacity:1;
      transition:opacity 0.5s;
    }
    
    .modal { @include modal; }
    .modal:target { @include modalOpen; }
    
    @media (max-width:32rem) {
    
      #mainMenu { @include modal; }
      #mainMenu:target { @include modalOpen; }
    
    }
    
    Code (markup):
    WAY better since you don't have to repeat the same code twice in your source. The problem with that though is:

    1) It's not native, you have to use a preprocessor like LESS or SASS to do it.

    2) The code deployed is not the code you wrote, so the tool and build chain for debugging and working with it is deeper.

    3) Once the preprocessor is done with it, you're actually deploying basically the same code client-side as you'd write without the preprocessor. In terms of writing the code you gain the advantage, but in terms of what the user gets in their browser, it's zero gain.

    Thus if we can simply:

    
    @keyframes modal {
    	from {
    		position:fixed;
    		top:0;
    		left:-100vw;
    		width:100%;
    		height:100%;
    		overflow:auto;
    		background:rgba(240,240,240,0.8);
    		opacity:0;
    		transition:left 0s 0.5s, opacity:0.5s;
    	}
    }
    
    @keyframes modalOpen {
    	from {
    		left:0;
    		opacity:1;
    		transition:opacity 0.5s;
    	}
    }
    
    .modal { animation:1s paused modal; }
    .modal:target { animation:1s paused modalOpen; }
    
    @media (max-width:32rem) {
    
    	#mainMenu { animation:1s paused modal; }
    	#mainMenu:target { animation:1s paused modalOpen; }
    
    }
    Code (markup):
    We get all the functionality of a mixin, without the extra tools, in a native implementation so our build stack is shorter and the code reduction and redundancy is removed client-side as well.

    There are three major pieces of functionality -- nesting (which I hate), mixins, and variables -- that LESS/SASS provide that are of any real "utility". Between "custom properties" and "abusing keyframes" that's two of them we can do native now!

    I have yet to find a situation where I would find CSS "nesting" of use or to be an improvement, simply because you end up scrolling up and down too much to figure out just exactly what's even being "selected" by only having selectors and not the full selector/combinator strings.

    Side note, this is why the users of frameworks, preprocessors, and so forth oft get their panties in a knot when I badmouth their beloved. I actually know how and when to use their tools, so I know exactly where to stick the knife in and twist.
     
    deathshadow, Dec 25, 2022 IP