Using CSS in Responsive UI

Responsive UI applications are built using HTML, CSS, TypeScript, and components.

When we look at the CSS used in Responsive UI, we see 2 different categories:

1. Enterprise CSS that’s logically internal to the enterprise UI components (components built by Jack Henry and third parties). This CSS is distributed as part of each Responsive UI release and manages all of the themed colors, fonts, sizes, geometries, opacities, internal spacing… everything that gives a consistent look and feel for these components across different Jack Henry products and different devices.

2. Product-level CSS that’s external to the Responsive UI components. This CSS is used within your product to manage the layout of the elements in your UI. Much of this CSS is applied to divs that are used for layout, but can also manage layout (such as margins) for the enterprise components themselves.

In any complex software system, it’s important to separate out the parts that are public from the parts that are private. This isn’t possible with CSS; all CSS is technically “public” in the sense that you can reference and override the CSS classes in your application. Whether the CSS is logically internal or external to the components, in the end it’s all CSS. There’s no way to “black box” the internal CSS like we were able to do with WPF. Unfortunately this means that product teams can override the enterprise CSS that’s internal to the components, whether intentionally or accidentally.

An important goal of Jack Henry’s “one look, one feel, one company” philosophy is to maximize consistency across Jack Henry products that our customers use. A high level of consistency across our applications helps our users more quickly and easily understand and use our products. For this reason, it’s important that product teams not override the enterprise CSS to reflect their own individual preferences as that decreases consistency across products and overall usability. The enterprise CSS is subject to change from release to release without notice; overriding the enterprise CSS is a brittle practice that can break your product UI when you move to newer releases.

Since all CSS is public, and since the responsive components are built from the same native elements as the rest of the UI — div, span, ul, li, button, input, etc — it can be all too easy for a product-level CSS selector to accidentally overreach and affect enterprise components that you didn’t intend to affect.

Investing some time into honing your team’s CSS skills is a great way to make sure that your CSS selectors are selecting only the elements you intend to select. In particular, we highly recommend learning more about CSS specificity, since that’s the part of CSS that is often the most confusing and hard to predict. You can learn more about CSS specificity at https://www.w3schools.com/css/css_specificity.asp and https://css-tricks.com/specifics-on-css-specificity/.

So using CSS to control your app’s layout is both supported and important. Here are some additional thoughts on doing this:

• You should never override any of the enterprise CSS: any CSS class that begins with “.jha-” or “.xj-”. At a minimum, this creates product one-offs that break consistency across products, which reduces overall usability for our customers. At its worst, it can make a component unusable. If you’re running into any problem with the existing internal CSS, please contact us and let us work with you to enhance the existing CSS instead of making product-level tweaks.

• You’ll want to be as specific as possible with your CSS selectors. This helps avoid CSS selector overreach, which can accidentally break both enterprise components and your own product UI.

• You should never hard code any fonts or colors. All of the enterprise CSS is styled to support the 10 enterprise themes. If you hard code a font or color, that may look good in one theme, but may completely break down in another.

• Feel free to set the margins around enterprise components as part of your layout. Our suggestion is to create product-level CSS classes for this and apply these to enterprise components as needed, rather than blanket selecting the enterprise components in your CSS selectors. That should help minimize CSS selector overreach.