Giter VIP home page Giter VIP logo

fluidms's Introduction

FluidMS

FluidMS offers a font-size system that enables you to use Modular Scale in combination with the Fluid Typography technique. It also ensures that all your typography always sits on a baseline grid which size you can define.

Requirements

FluidMS is built on Dart Sass.

Getting Started

Installing

In order to use FluidMS, first install the package:

$ npm install fluidms --save

Next, you need to import the Sass files into your project:

// Your `main.scss` file.

@use "<path-to-fluidms-node-package>/src/fluidms.scss";

If you are following an ITCSS approach in your project, you might want to import the individual partials of FluidMS instead:

// Your `main.scss` file.

// Settings
@use "<path-to-fluidms-node-package>/src/settings/settings.config";

// Tools
@use "<path-to-fluidms-node-package>/src/tools/tools.utils";
@use "<path-to-fluidms-node-package>/src/tools/tools.ms";
@use "<path-to-fluidms-node-package>/src/tools/tools.font-size";
@use "<path-to-fluidms-node-package>/src/tools/tools.line-height";

// Generic
@use "<path-to-fluidms-node-package>/src/generic/generic.ms-custom-properties";

// Elements
@use "<path-to-fluidms-node-package>/src/elements/elements.page";

// Objects
...

// Components
...

// Utilities
...

Usage

To use FluidMS, you only need to apply the fluidms-font-size() mixin to the elements you want to assign font-sizes to:

.foo {
    @include fluidms-font-size();
}

Just calling the mixin without any arguments assigns the base font-size to the element along with a line-height that is calculated to automatically fit into the defined baseline grid.

Let’s see how we can affect the generated font-size of an element:

.larger-text {
    @include fluidms-font-size(
        $font-size: ms(1)
    );
}

Here we are calling the mixin with altering the $font-size parameter. For that, we are using the ms() function (ms stands for “Modular Scale”). What we are doing here is to say: “Assign a font-size here, but set the font-size to the next bigger scale entity than our base font-size (hence 1).” We could also set the font-size to the next bigger scale entity by passing $font-size: ms(2) and so on.

Negative entites are also possible:

.smaller-text {
    @include fluidms-font-size(
        $font-size: ms(-2)
    );
}

Read more about Modular Scale here.

Custom font-size

Instead of relying on the modular scale for a specific font-size and using the ms() function for the $font-size parameter, you can also pass a custom font-size:

.custom-font-size {
    @include fluidms-font-size(
        $font-size: 38px
    );
}

Any value that is valid for the native CSS font-size property is also valid here.

Changing the line-height

By default, the line height is automatically calculated so that it fits onto the defined baseline grid. However, if you need to manually assign a custom line-height to an element, you can do so with an additional argument:

.custom-line-height {
    @include fluidms-font-size(
        $font-size: ms(3),
        $line-height: 50px
    );
}

Possible values for the $line-height parameter are:

  • A number with any unit that’s valid for line-height declarations (or unit-less)
  • The keyword inherit
  • The keyword normal

You can also completely omit the output of a line-height declaration by setting its value to false:

.no-line-height {
    @include fluidms-font-size(
        $font-size: ms(3),
        $line-height: false
    );
}

($line-height: none also works for omitting the output)

Increasing/Decreasing the line-height

There may be situations where the generated line-height is not quite what you need, but you still want to benefit from the automatic baseline grid adaptation. So instead of assigning a custom line-height and risking loosing the anchoring to the baseline grid, you can tweak the line-height upwards or downwards and still be on the baseline grid:

.slightly-smaller-line-height {
    @include fluims-font-size(
        $line-height-modifier: -1
    );
}

.slightly-bigger-line-height {
    @include fluims-font-size(
        $line-height-modifier: 1
    );
}

As you can see, we can deviate from the default line-height in integer increments (positive and negative). In theory, every integer is possible here (e.g. 1.000.000), but mostly you will only tweak the line-height a little bit.

Note that $line-height-modifier only has affect when the $line-height parameter is set to auto (default).

!important

You will not find any CSS jokes about the usage of !important here. The fact is, it may well be that you need an !important here and there and actually, it sometimes can be a pretty good idea, too.

Anyhow, FluidMS has got you covered for these situations:

.i-need-important {
    @include fluidms-font-size(
        $font-size: ms(1),
        $important: true
    );
}

This outputs the font-size as well as the line-height with a trailing !important in the declaration.

Adjusting

FluidMS comes with predefined configuration settings that you can fit to your needs. You’ll find all the config in the provided _settings.config.scss file.

Changing the baseline grid

FluidMS provides a baseline grid out of the box. That means that every line-height that is automatically generated by FluidMS sits on this vertical grid. You can change the size of that grid by altering the $GLOBAL-BASELINE variable:

$GLOBAL-BASELINE: 0.25rem !default;

$GLOBAL-BASELINE needs to be defined with a rem unit. It has been proven to be a good idea to define a value between 0.1rem0.333rem.

If your design doesn’t require a global baseline grid, you can also disable it:

$GLOBAL-BASELINE: false !default;

Changing the global line-height

You can define an ideal line-height that is taken into account when calculating the actual line-height. The value you define here is more just a rough direction of what the resulting line-height will be.

$GLOBAL-LINE-HEIGHT: 1.5 !default;

Changing the global line-height ratio

The bigger font-sizes get, the lesser the line-height needs to be in relation to its font-size. Hence, we provide an option to decrease the line-height in proportion to the font-size, the bigger the font-size gets.

$GLOBAL-LINE-HEIGHT-RATIO: 1 !default;

Don’t get crazy with this variable’s value! Only nudge the ratio slightly and always test all the possible font-sizes with multiline text.

Configure the Fluid Typography values

With Fluid Typography, you basically define a viewport range in which all the font-sizes are fluid, i.e. the font-sizes are sized according to the viewport size — if the viewport size is small, the font-size is too. If the viewport size is large, so is the font-size.

Defining the viewport range

You can define the range in which the typography is fluid with the min-viewport and max-viewport entries in the $CONFIG Sass map:

$CONFIG: (
    min-viewport: 480px,
    max-viewport: 1280px,
) !default;

Defining the base font-size

This means that on every viewport that’s between 480px and 1280px wide, the typography will be fluid. How big the font-size is below and above this range can be defined with the min-font-size and max-font-size entries in $CONFIG:

$CONFIG: (
    min-font-size: 16px,
    max-font-size: 24px,
    min-viewport: 480px,
    max-viewport: 1280px,
) !default;

Below a viewport of 480px, the font-size will be 16px and not smaller. Above a viewport of 1280px the font-size will be 24px and not larger. Between these two viewport sizes, the font-size will evenly scale between 16px and 24px. However these are just the base values when the default font-size is used. If we assign a larger font-size for an element like this:

.larger-text {
    @include fluidms-font-size(
        $font-size: ms(1)
    );
}

then the minimum and maximum font-size should of course be bigger. How much bigger it is can be defined via the ratio entry in the $CONFIG Sass map:

Defining a font-size ratio

$CONFIG: (
    min-font-size: 16px,
    max-font-size: 24px,
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: 1.1,
) !default;

With a ratio of 1.1, the font-size of the example above will be 17.6px (16px * 1.1) on screens smaller than 480px. On screens larger than 1280px, the font-size will be 26.4px (24px * 1.1).

If we use the mixin with $font-size: ms(2), this font-size will be again 1.1x bigger than that one and so on.

Changing the ratio at different breakpoints

What seems like a good ratio on small screens might not be suited on larger screens as the different font-sizes are too similar to each other related to the viewport size. In this case you can optionally change the ratio for different breakpoints:

$CONFIG: (
    min-font-size: 16px,
    max-font-size: 24px,
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: 1.1,
    1024px: (
        ratio: 1.3,
    ),
) !default;

Our default ratio is still 1.1, but above screens of 1024px, our ratio is increased to 1.3. This means that our different font-sizes are more diverging in their sizes.

Defining a set of scales

In order to even be able to use different font-sizes, we need to define a set of different font-size entities. For that, we add a scales list to the $CONFIG map.

$CONFIG: (
    min-font-size: 16px,
    max-font-size: 24px,
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: 1.1,
    1024px: (
        ratio: 1.3,
    ),
    scales: (
        6,
        5,
        4,
        3,
        2,
        1,
        0,
        -1,
        -2,
        -3,
    ),
) !default;

Positive and negative integers are valid here. The numbers we add here basically result in the values we can use in the ms() function.

Browser Support

As FluidMS uses the clamp() math function, the browser support is limited accordingly. A non-supporting browser will simply ignore the fluid base font-size and will not show any fluid typography.

fluidms's People

Contributors

csshugs avatar dependabot[bot] avatar fuhlig avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar

fluidms's Issues

feat: Opt out of modular scale

As the name of FluidMS suggests, it serves as a combination of fluid typography and Modular Scale. However, there might be projects that just don’t need/want the Modular Scale approach but still want fluid typography. So instead of deciding for one ratio value that determines the scale, maybe each entity of the scale needs to be determined individually.

I could imagine that the FluidMS settings will then look something like this:

$FLUIDMS-CONFIG: (
    min-font-size: 16px, // Still define a base font-size for small screen...
    max-font-size: 24px, // ...and for large screen.
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: false, // Disable the ratio.
    // Alter the default Sass list to a map, so we can assign
    // (rem-)values to the individual scale entities.
    scales: (
        6: 3rem,
        5: 2.5rem,
        4: 2rem,
        3: 1.7rem,
        2: 1.4rem,
        1: 1.2rem
        -1: 0.8rem,
        -2: 0.65rem,
        -3: 0.55rem,
    ),
) !default;

This way, we’d still have fluid typography, but we can define the font-sizes of the individual font-size scale entities individually (i.e. breaking the Modular Scale).

[Bug] Local webserver not serving on baseUrl (windows)

Describe the bug
The webserver for local testing does not serve index.html on the baseUrl (localhost:port) but does when appending /index.html on windows. This is a known issue of http-server (see related issue).

To Reproduce
Windows:

  • npm run server
  • http://localhost:8080 (not served)
  • http://localhost:8080/index.html (served)

Expected behaviour
Same behaviour cross-platform to serve index.html on baseUrl (e.g. localhost:port)

Additional context
Related issue

[Improvement] Allow custom font-sizes

There may be situations, where you explicitly need a custom font-size that is not part of the modular scale (e.g. a specific px value). In this case, it would be cool to still be able to use the fluidms-font-size() mixin and pass the custom font-size as argument.

Dart Sass 2.0.0 support: "Using / for division is deprecated and will be removed in Dart Sass 2.0.0."

Hey there,

We have moved over to Dart Sass, away from Node Sass.
Dart Sass is throwing some deprecation warnings for the / division operator:

DEPRECATION WARNING: Using / for division is deprecated and will be removed in Dart Sass 2.0.0.
Recommendation: math.div($px, $base-font-size)
More info and automated migrator: https://sass-lang.com/d/slash-div

See breaking changes:
https://sass-lang.com/documentation/breaking-changes/slash-div

feat: Adjustable config and sensible defaults

Currently, the user has to completely override the $FLUIDMS-CONFIG map in order to adjust individual attributes of the Sass map. The current default of $FLUIDMS-CONFIG is this:

$FLUIDMS-CONFIG: (
    min-font-size: 16px,
    max-font-size: 24px,
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: 1.1,
    768px: (
        ratio: 1.2,
    ),
    1280px: (
        ratio: 1.3,
    ),
    scales: (
        6,
        5,
        4,
        3,
        2,
        1,
        0,
        -1,
        -2,
        -3,
    ),
) !default;

Let’s say, the user only wants to adjust the min-font-size to 18px. What they need to do is to override the map with this:

$FLUIDMS-CONFIG: (
    min-font-size: 18px,
    max-font-size: 24px,
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: 1.1,
    768px: (
        ratio: 1.2,
    ),
    1280px: (
        ratio: 1.3,
    ),
    scales: (
        6,
        5,
        4,
        3,
        2,
        1,
        0,
        -1,
        -2,
        -3,
    ),
) !default;

It would be way easier for the user to just adjust the map entry they actually want to change from the default without the need to manually copy all the contents from the original Sass map:

$FLUIDMS-CONFIG: (
    min-font-size: 18px
) !default;

If we do this, we need to overthink our current defaults of the $FLUIDMS-CONFIG Sass map, as we couldn’t remove e.g. custom breakpoint ratios. The following seems like a more sensible default config, as in it is usable right off the bat in any project with only slight adjustments (i.e. less opinionated):

$FLUIDMS-CONFIG: (
    min-font-size: 15px,
    max-font-size: 20px,
    min-viewport: 480px,
    max-viewport: 1280px,
    ratio: 1.15,
    scales: (
        6,
        5,
        4,
        3,
        2,
        1,
        0,
        -1,
        -2,
    ),
) !default;

[Feature] Add feature flag for opting out of baseline grid

Currently, the baseline grid is without any alternative. By default, each time a font-size is declared via the fluidms-font-size() mixin, a line-height is also generated accordingly. However this could potentially lead to many line-height declarations in the compiled CSS. The advantage is that everything sits on the baseline grid. However, a baseline grid might not be needed in every project and could be considered as needless and unnecessary feature.

So the idea is to en-/disable the baseline grid via a Sass feature flag, so the user can decide if they need it or not. In case they don’t need it, a global unit-less line-height is set and the fluidms-font-size() mixin does not output any line-height declarations. However, an optional line-height can still be defined in the mixin to override the globally defined line-height.

feat: Fallback for older browsers

Browsers that don’t support custom properties are completely locked out. The generated font-size and line-height declarations are simply ignored and the browser default styles are inherited. This can lead to very inappropriate font-sizes for certain elements.

We should try to find a sensible fallback solution that can be enabled via a Sass feature flag, that provides at least some sort of reasonable font-size declaration for older browsers.

[Feature] Calculate line-height relatively depending on the font-size

It’s good design practice to decrease the line-leight in relation to its font-size, the bigger the font-size gets. E.g., 1.5 might be a good line-height value for the base body copy text, but for a big, multiline headline, that value might be way too much and something like 1.2 would be much better suited.

By introducing a line-height ratio that can be defined via a Sass variable, this could be automated.

[Feature] Linting commits

This feature is derived from #7 and will now be approached as individual feature.

Tools like commitlint can lint commit messages according to contributing guidelines
#7

As an MVP, having a static npm script to lint new commits should suffice. An additional step (separate feature?) could be to automatically lint commit messages via a pre-commit hook.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.