In Angular, a component’s CSS style is encapsulated in its own view without affecting the rest of the application.

You can control the encapsulation mode of each component individually by setting the view encapsulation mode on the component’s metadata. There are several optional encapsulation modes as follows:

  • ShadowDOM pattern: Using the browser’s native Shadow DOM implementation, you can refer to the Shadow DOM document on the MDN to attach a Shadow DOM to the component’s host element.

The component’s view is attached to the Shadow DOM, and the component’s style is contained in the Shadow DOM.

Memory: no style can come in, no component style can go out.

  • The Emulated view (the default) emulates the behavior of the Shadow DOM by preprocessing (and renaming) the CSS code in order to restrict the CSS style to the component view.

Global styles can come in, component styles can’t go out.

You can work with Shadow DOM in the same way you would with regular DOM — for example, add child nodes, set properties, and add your own styles to the nodes (for example through the property). Or add styles to the entire Shadow DOM (for example, within the Style element). The difference is that elements inside the Shadow DOM never affect elements outside it (except :focus-within), which makes encapsulation easier:

Note that Shadow DOM is not new in any way — it has been used by browsers to encapsulate the internal structure of elements for a long time. Take a <video> element that has a default playback control. All you see is a <video> tag, which actually contains a series of buttons and other controllers in its Shadow DOM. The Shadow DOM standard allows you to maintain a set of Shadow DOMs for your own custom elements.

So, does SAP Spartacus use any of the Shadow DOM mechanisms mentioned so far in this article?

Start by learning how SAP Spartacus CSS is designed.

Spartacus is provided as a set of standard components distributed within the NPM library. These libraries help ensure that Spartacus remains both extensible and scalable.

To provide as much style flexibility as possible, all CSS rules are provided in a separate @spartacus/styles library. This makes the style fully optional, configurable, and extensible. You can extend or replace standard styles, or you can implement your own style rules.

In addition, existing UI frameworks (such as Bootstrap) can be used in Spartacus without making it a hard-coded dependency.

SAP Spartacus Style version mechanism

The Spartacus library supports semantic versioning, which means that no major changes are allowed during the life cycle of a major release. The same is true for style libraries. New style rules or tweaked rules that make a difference in the UI experience are considered significant changes. The Spartacus library is released on the assumption that the customer relies on a semantic versioning scheme, so that no major changes, such as implicit changes to the style library, are made during the life cycle of the major release.

In the meantime, Spartacus is likely to evolve from one small version to the next. To allow progressive changes in the style layer, new or adjusted style rules are added for a particular version, but these changes are not added to the style building process unless you explicitly choose to receive them. You need to set a variable to take advantage of the latest breakthrough style changes. Note that non-destructive changes are added anyway.

The following example illustrates the additional styles in version 2.2:

Cx-mini-cart {@include forVersion(2.1) {background: blue; } @include forVersion(2.2) {background: deepskyblue; }}

SAP Spartacus CSS technology

Spartacus was developed in combination with the following CSS technologies:

  • Sass, used as a pre-processing language, as in most UI frameworks today.
  • CSS custom properties for the global theme.
  • CSS POST handling, which is intended to populate any syntax needed by older browsers.

SAP Spartacus does not use any of the Shadom DOM implementation techniques described earlier in this article. Angular emulation encapsulation is not available because component styles are provided by the style library. BEM is considered old-fashioned and sophisticated. In addition, well-defined, fine-grained component architectures do not require BEM to encapsulate styles.

Global theme

Global topics are organized with variables, so the topics are not hard-coded. For variables, you can use two common methods:

  • SASS variable
  • CSS custom properties (in other words, CSS variables).

Spartacus uses CSS variables for theming. CSS variables have the advantage of being configurable at run time. Furthermore, they can penetrate the shadow DOM (the Web component). In addition, CSS variables are inherited and provide more flexibility than SASS variables.

Subject variables contribute to the so-called “contracts” Spartacus offers to its customers. The contract is intended to be stable and should change infrequently. Only in a major release can Spartacus introduce a new set of variables, but this is not considered a best practice.

To provide a stable set of variables, the CSS variables in Spartacus are primarily used for color schemes and font definitions. These can be thought of as a set of global topic definitions.

Here’s an example of a CSS variable:

:root {
  --cx-color-primary: red;

cx-link {
  color: var(--cx-color-primary);

CSS variables can be customized at the root of the document or at a specific selector.

Component Styles

Spartacus contains a number of components that you can use to build a storefront experience. While commerce may be a commodity, styling is essentially a subjective subject. Not only the choice of colors and fonts, but also the space for components, backgrounds, lines, and so on.

Whatever Spartacus offers, it does not represent your brand or corporate image. For this reason, Spartacus is highly flexible, so you can extend the component styles or skip them altogether.

Because Spartacus components are built and distributed in libraries, Component styles cannot be used because the definitions of Component and Style are separate in Spartacus. These styles will be preprocessed and baked into the component library. This means that CSS rules are not optional, nor can they be easily customized.

Instead, you can optionally provide component styles in the style library. You can use these styles, extend them, or skip them entirely and build CSS rules from scratch. The contract between the style library and the component library is done through the (unique) component selector.

Placeholder Selectors

To make the CSS rules provided in the style library completely optional, the styles are wrapped in a placeholder selector. A placeholder selector is a SASS technique that starts with a percentage, such as % CX-Mini-Cart. The placeholder selector is not added to the final CSS. Instead, they need to be explicitly extended to appear in the final CSS.

Here is an example of a component style that uses a placeholder selector:

%cx-link { a { display: inline; padding: 0; margin: 0; color: currentColor; display: block; }}

While it is safe to import a placeholder selector, it does not affect the final CSS until it is explicitly used.

These placeholder selectors will only appear in the final CSS if they are actually extended.

Therefore, the style can be extended as follows:

cx-link {
  @extend %cx-link !optional;
  a {
    color: red;

! 5. Optional meaning:

Optional flags ensure that the code does not break during build, as long as the particular import is not part of the import style.

Spartacus generates components by iterating over a configured component selector.

Skipping Specific Component Styles

Component styles are optional because they are extracted from the style library. Therefore, you may want to completely disable some standard component styles. To disable standard component styles, you can add a component selector to the $skipComponentStyles list. Here is an example that demonstrates skipping two standard components from the style library:

$skipComponentStyles: (cx-product-carousel, cx-searchbox);

If you need to create styles from scratch and don’t want to override specific style rules from the Spartacus style library, it may be helpful to skip specific component styles.

Page Layout Styles

Global themes and component styles are most important for rendering components on a page. However, orchestrating the overall layout of components on the page is another important style layer. For more information about this layer, see Page Layout.

More of Jerry’s original articles can be found on “Wang Zixi “: