0 comment

How to handle typography in SPFx projects with spfx-uifabric-themes

The first version was only planned to give people a more comfortable use for theming tokens in SPFx projects. Today I released a new version that improves the typography in a way that Office UI Fabric currently not provides.

This new release is mainly targeted for accessibility and gives the ability to define custom classes based on the outlined typography.

What’s new?

The new version is labelled as 0.2.0 and contains various SASS mixin around font size and weight definitions based on Office UI Fabric font definitions.

Font Definition – uiFont(fontDefintion)

This mixin allows you to get a combination of font size and font weight to your custom class. In case you need the font definition defined by .ms-font-xl you only need to pass xxl to the mixin.

   @include uiFont(xl);

The code above returns the following definition as the appropriate CSS.

Office UI Fabric font definition for `.ms-font-xl`

Additional values that you can use are:
su, xxl, xl, l, m-plus, m, s, s-plus, xs, mi

Mainly use just the last part of the class definitions.

Font Size – uiFontSize(fontSizeDefinition)

Unlike the uiFont mixin this works the exact same way you simply pass one of these parameters: su, xxl, xl, l, m-plus, m, s, s-plus, xs, mi
What you get is the corresponding font size definition.

   @include uiFontSize(xl);

The resulting class in SPFx will look like this:

  font-size: 28px;

Font weight – uiFontWeight(fontWeightDefinition)

web part showing the default font weights

I case you only like to get the font weight value definied by Office UI Fabric all that needs to be done is to pass one of the following values:

  • light – will return font-weight: 100
  • semilight – will return font-weight: 300

  • regular – will return font-weight: 400

  • bold – will return font-weight: 700

So, in case you like to define semilight somewhere in your web part, you don’t need to remember the value 300. Instead, you do the following thing:

    @include uiFontWight(semilight)

The resulting CSS in SPFx will then be:

    font-weight: 300;

Why not use Office UI Fabric classes?

There is nothing that is to say against Office UI Fabric defined classes, but there are some drawbacks.


In the “Web Content Accessibility Guidelines – C14” state that you should use em instead of pixel definition for font sizes. Office UI Fabric only implements fixed pixel values.
To achieve this goal I converted all font size values dynamically to em and rem based values. When you like to have a font size of 42px, it returns the correct value converted to em or rem.
Most browser these days can zoom the content. Sadly that is not enough for WCAG 2.0 because the text should be resize-able without the use of assistive technologies. Not so with pixel definitions.
Another example might be that I configured my device to view fonts larger in the browser. With em units the browser can resize but maybe not with pixel based.

Convert ‘px’ to ’em’ and ‘rem’

A tricky task because I just found out that Office UI fabric changes the font size of the body to 14 pixels. Again an issue in case of accessibility because the text size shouldn’t be lower than the browser default. This default value is 16 pixels. This size is also the base of :root┬áselector. So to get the correct em value the following calculation needs to be applied assuming the target font size should be 42px.

42px / 14px = 3em

The font size defined at the root of an HTML document remains 16px. To get the correct value I had to do the different math.

42px / 16px = 2.625rem

To switch from em units to rem units simply call another mixin.

// turn rem return values ON.
@include uiUseRem(true);

// output font size in REM
    @include uiFont(su); // get the correct value of 42px in rem

// turn rem return values OFF.
@include uiUseRem(false);

// font size will now returned in EM
    @include uiFont(su); // get the correct value of 42px in em

That’s all for this release

To be honest, I’m not a framework user at all. Never used Bootstrap or something similar to that. Most of the findings and issues I documented and found there was just by digging into the SASS sources of Office UI Fabric over the past weeks.
The goal with these additions just was to make the styles defined by Office UI Fabric easier to consumable for casual web developers, that don’t like to use frameworks at all.

More informations: