LESS Hat 3.0

LESS Hat 2.0 Analytics


Download latest (or Prefixed - great with Bootstrap) | Get Started | Contribute | Documentation |


Current version: v3.0.2 (2014-06-26)

What's new?

Intro

Why LESS Hat? In August 2012, while we were developing and extending CSS Hat for LESS we needed universal mixins. Unfortunately, none of available were good enough that would satisfy our needs and that’s why we created new custom ones on our own, which have become the most popular mixin library for the whole LESS CSS.

After a year, there is a new, completely rewritten 3.0 version that brings 86 great mixins, robust workflow for editing, testing and creating new mixins.

Meet the best mixins library in the world. Thanks to the LESS Hat 3.0 is LESS CSS finally usable.

If you would like to use CSS Hat for working with LESS Hat and you still don't have one, we have a suprise for you at lesshat.com - Check it out!

Features

Get started

The structure of this repo is:

Structure of LESS Hat mixins

  1. Typical LESS Hat mixin:

    .supermixin(...) {
        @process: ~`(function(){})()`;
    
        -webkit-border-radius: @process;
        border-radius: @process;
    }
    

    In @process variable is all magic. Please don't edit javascrpt directly in .less file. Instead use lesshat-devstack.

  2. Use (almost) every property without interpolation!

    Correct mixin calling:

    .background-image(linear-gradient(to bottom, #fb83fa 0%,#e93cec 100%))
    

    Incorrect calling:

    .background-image(~'linear-gradient(to bottom, #fb83fa 0%,#e93cec 100%)')
    

    Unfortunately, there are exceptions:

    .keyframes(~'');
    .calc(~'');
    .selection(~'');
    
    // in some cases you have to interpolate border-radius or LESS CSS begins to play on calculator
    .border-radius(~'20px / 40px');
    

Contribute:

  1. Download this repo.
  2. NPM install.
  3. Now you have LESS Hat devstack (see documentation.)
  4. If you create new mixin, use grunt generate command!
  5. If it's possible (almost always) test the coverage for new mixins, and never break existing tests.
  6. Commits should represent one logical change each. If a mixin goes through multiple iterations, squash your commits down to one.
  7. Finally, commit some code and open a pull request.

Big Thanks to: