Theme UI-Kit - Skin: overview and best practices

From PegaWiki
Theme UI-Kit - Skin: Overview and Best Practices / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Theme UI-Kit - Skin: overview and best practices

Description Description of the skin rule and related best practices
Version as of 8.5
Application Pega Platform
Capability/Industry Area User Experience

This content is being retired in the next few months. Please use our documentation site to find information you may need.


A skin is a centralized rule that defines all the styling of an application. It provides presentation, styling, and branding to the application. Styles can be defined for all the components in your application. You can style all presentation elements of the interface in the skin, including typography, borders, backgrounds, layouts, as well as UI placement and alignment. The skin can be defined at the portal and application levels.

Skin components

Component Styles Styles that can be defined for specific UI components.
Mixins Reusable style patterns that can be used among different components.
Base Settings Basic settings of the skin that include font face, heading styles, and background colors.
Included Styles Custom styles that can be created and added to the skin.
Skin inheritance
Sample CLM skin inherits from EndUserFSIF and pyEndUser skins.

Mixins and component styles are the building blocks of skin rules. They are used to construct incremental styling changes with a natural cascading sequence. These increments provide consistency and reduce maintenance efforts. They also promote reuse.

For more information, see Component style formats and Mixins.

Skin inheritance

Skin inheritance allows the formats and mixins of a parent skin to be inherited by a dependent skin. The formats inherited by the dependent skin do not have to be explicitly defined in the dependent skin but they are defined by the formats in the parent skin. When a format in the parent skin is modified, the dependent skin will automatically inherit the changes unless the format is overridden in the dependent skin. Style sheets included in parent skins are also inherited, with the dependent skin's style sheet taking priority.

For example, in CLM, the skin inherits from the foundation layer's (FSIF) EndUserFSIF, which in turn inherits from pyEndUser. In this scenario, the parent skin is EndUserFSIF and the dependent skin is CLM. However, both skins inherit from the underlying pyEndUser skin.

format overrides
Sample inheritance pattern from parent to child (overriding existing settings).

With inheritance, the formats that are available in pyEndUser are available for EndUserPFFS. And CLM contains all the formats from both pyEndUser and EndUserPFFS (see the inheritance pattern image). If any formats are overridden in the EndUserPFFS skin, CLM will inherit the overridden format from the EndUserPFFS layer.

For more information, see Skin inheritance.


Pega Platform™ provides a set of out-of-the-box icons so that you can add images to controls. The UI Kit ruleset includes icon fonts in the py-icons CSS file. For more information, see Icon fonts.

CSS Helper classes

Helper classes are readily available CSS code snippets, which can be added to sections and controls to customize your UI. Pega Platform provides a wide variety of helper classes for styling layouts, spacing, fonts, colors, and more. They are included in the py-common-helper-classes.css file, which is part of the pyEndUser skin.

helper classes
Using helper classes for label

For example, if you want a label to be bold, then instead of creating a new format for the bold option, you can use the standard format with the text-bold helper class (see the helper class image).

Note: Usage of helper classes is a highly recommended approach for styling an application. It reduces the number of unnecessary components. For more information, see CSS Helper classes

Best Practices

  • Defining UI branding with inline styles requires rule (code) adjustments across the application whenever the branding changes, which significantly increases the time it takes to react to changes. Instead, use the skin. The centralized location of all styles in the skin rule helps quickly adapt to any changes in the organization’s branding or to new UI design paradigms.
  • Create mixins whenever possible to reduce maintenance efforts. For example, if multiple formats share background color and fonts, then instead of configuring the colors and fonts at the format level, create a mixin for all the similar formats. With this approach, future changes to styling are less complex.
  • Use helper classes instead of creating new formats, if possible. This approach helps to reduce the skin size and simplifies format management. For example, to retain the default format but remove padding, apply the padding-0 helper class to the default container format.
  • Use the out-of-the-box icons. Before adding new images, check the available icons and images.
  • Use optimized dynamic layouts instead of smart or free form layouts.

Reference links