Contents:
A practical guide to CSS hierarchy, supported style hooks and coherent Panintelligence theming
A dashboard theme has more than one job
A Panintelligence theme does more than apply brand colours. It must keep dashboards, tables, filters, settings, login and mobile layouts readable and coherent. The Theme editor provides the supported controls, while CSS hierarchy determines which value ultimately appears on screen.
WORKING PRINCIPLE Start with the shared foundation, then specialise only where a component, state or product context requires a different decision.
The four areas of a Panintelligence theme
- Style. Supported selector groups for dashboards, components, specialist screens and mobile.
- Colours. The ordered chart series palette, with Colour 1 carrying primary emphasis in many views.
- Configuration. Assets and behaviour such as logos, fonts, chart options, table dimensions and login imagery.
- Icons. The place to replace default icon mappings when different symbols are required. Their appearance and interaction states are styled under Style.
Figure 1. The Theme editor separates CSS hooks from palettes, configuration and icons.
Why apparently finished themes still drift
A body rule can establish the right font and colour while a button, table cell or chart-rendered label sets its own value. Normal styling may look correct while hover or disabled states retain unsuitable defaults. These are hierarchy gaps, not random defects.
Why that matters
Those gaps can hide controls, weaken chart legibility and make supporting screens feel detached from the dashboard. Patching each symptom also raises specificity and maintenance cost. The durable fix is to place each visual decision at the correct level of the hierarchy.
DESIGN CONSEQUENCE Once users must learn which surfaces obey the theme and which do not, a visual inconsistency has become a usability issue.
How Panintelligence decides which style wins
There are two hierarchies to keep in mind. The first is the element tree: a chart panel sits inside the page body, and chart text sits inside the chart panel. The second is the CSS cascade: the browser resolves every property by considering importance, runtime or inline styling, selector specificity, source order and inheritance.
Body is the foundation, not the final authority
The body rule is the right place for the dashboard canvas and global typography. Text-related properties can flow into descendants when those descendants do not set their own value. A direct value on a chart title, button or input will take precedence for that property.
.pi-style__body {
background: #f3f5f8;
color: #122435;
font-family: "Google Sans", sans-serif;
font-size: 14px;
}
Property inheritance at a glance
| Often inherited | Usually not inherited |
|---|---|
| color, font-family, font-size, font-weight | background, border, border-radius, box-shadow |
| line-height and text alignment, unless a child sets its own value | margin, padding, width and height |
Specificity answers the 'why did that win?' question
Within normal author styles, a more specific selector wins over a less specific one. If specificity is equal, the later declaration wins. This is why a global link rule can work across the body while a navigation-specific hover rule safely refines the header.
a /* broad */
.pi-style__page-top-nav a /* scoped */
.pi-style__page-top-nav .pi-style__nav-menu a:hover /* scoped state */
USE !IMPORTANT SPARINGLY It is a last resort for a documented product-CSS conflict, not a normal method of building hierarchy. A theme full of !important rules becomes difficult to reason about.
Build in the same order the interface is experienced
A reliable implementation sequence keeps the cascade understandable and prevents local exceptions from becoming the design system. Each step should establish a stable layer for the one that follows.
- Set the foundation. Define the body background, base text colour, typeface and base size.
- Create application surfaces. Style the top navigation, page content, drawers, dialogs and the dashboard canvas.
- Define the panel system. Use a consistent background, border, radius, shadow, gap and internal padding.
- Style components. Work through buttons, category objects, chart panels, charts, tables and cards.
- Complete interaction states. Check normal, hover, focus, active, disabled and disabled-hover behaviour.
- Handle specialist contexts. Treat Login, Config Screens, PDF, Mobile and AI surfaces as deliberate contexts.
- Set palette and configuration. Order chart colours, attach assets and validate font delivery and dimensions.
- Preview, test and save. Validate representative dashboards before committing the theme.
Chart Panel and Chart solve different problems
The Chart Panel group controls the frame around a visualisation: panel surface, spacing, title, subtitle, menu and chart-tool controls. It is also where scoped button states can be made consistent without changing every button in the application.
anging every button in the application.
.pi-style__chart-panel {
background: #ffffff;
color: #122435;
border: 0 solid #e2e8f0;
border-radius: 16px;
margin: 8px;
padding: 12px;
}
Figure 2. Chart Panel rules style the surface and its scoped controls.
The Chart group controls chart-rendered content
Axes, legends, data labels and specialised chart values are rendered inside the chart. Some labels use vector text, so setting only CSS color may not change what appears on screen. The corresponding visual property is often fill.
.pi-style__chart__pie-and-donut__data-value {
color: inherit;
fill: currentColor;
}
The same principle applies to funnel labels and other text drawn inside coloured areas. Use the most specific supported chart hook available, then test the label against both the lightest and darkest colours in the palette.
Figure 3. The Chart group exposes axis, legend and specialist data-label hooks.
Use colour to create priority, not competition
A palette can be technically accessible and still feel exhausting. If every control, series and status uses a saturated colour, the dashboard has no quiet layer and the user has to work harder to find the important signal.
- Keep surfaces neutral. Let the dashboard background, panels and tables establish structure without competing with data.
- Choose one interaction accent. Use it for selected tabs, primary actions and focused controls rather than every icon.
- Order chart colours intentionally. Colour 1 should carry the strongest visual emphasis; later colours should remain distinct without all shouting at the same volume.
- Reserve semantic colours. Red, amber and green should communicate status or risk when possible, not act as generic decoration.
Figure 4. Chart series colours are ordered independently from ordinary CSS rules.
Configuration completes the delivery contract
A theme can look complete while still depending on missing assets or browser-specific font behaviour. Configuration is where dashboard and PDF logos, loading assets, font URLs, chart options, table dimensions and login imagery are connected to the visual system.
Figure 5. Configuration connects assets and behaviour to the theme.
DELIVERY CHECK If a font depends on a remote URL, test the deployed Content Security Policy and the fallback stack. A font that works in a local preview is not automatically production-safe.
Icons replace symbols; Style controls their appearance
The Icons tab is the theme's icon-management area. It is where a default Panintelligence icon can be replaced with another supported mapping when the symbol itself needs to change. If the default symbol is suitable, its mapping can remain unchanged.
This is separate from visual styling. Colour, fill, hover and focus behaviour belong to the relevant selectors under Style. Keeping that distinction clear prevents a common mistake: changing an icon mapping when the actual problem is contrast, or changing global icon colour when only the header or chart context needs an adjustment.
Validate states and contexts, not just the happy path
The fastest way to miss a defect is to approve a theme from a single dashboard at rest. A production review should include interactive states, data density and specialist screens.
- Navigation and icons. Check normal and hover contrast in both the header and chart panels.
- Buttons and filters. Test primary, secondary, chart-scoped, disabled and reset controls.
- Charts. Inspect legends, axis labels, tooltips and labels inside pie, doughnut and funnel areas.
- Tables. Review header, body, totals, row states, font choice, row height and numeric alignment.
- Platform surfaces. Open configuration screens, drawers, AI dialogs, login, PDF and mobile views.
- Accessibility. Verify text and non-text contrast, visible focus, keyboard states and high-contrast use.
Troubleshoot one property, one element, one winner
When a value does not appear, avoid changing several selectors at once. Inspect the element in browser developer tools, select the failing property and find the winning declaration in Computed Styles.
- Confirm the element. Is the visible text HTML, SVG or a child element with its own class?
- Confirm the state. Is the defect only present on hover, focus, active or disabled?
- Compare specificity. Is a scoped selector outranking a global rule?
- Check runtime styling. Has the chart or application written an inline value?
- Check source order. If selectors tie, is a later declaration winning?
PREVIEW CAVEAT The Theme editor's dashboard preview is useful for style changes, but it does not save the edit and does not preview the Colours palette. Save and validate on a representative dashboard before sign-off.
Turn the method into a reusable standard
The payoff comes when the same hierarchy and validation method can be applied to more than one dashboard. A useful first standard is not a giant selector inventory; it is a small set of agreed decisions for foundations, surfaces, components, states and specialist contexts, supported by a representative test dashboard.
A practical evaluation exercise
For a first evaluation, choose one real dashboard with a chart, table, filters and at least one drawer. Build three standards - light, dark and high contrast - and run the same review against each. The exercise reveals whether your decisions are a reusable theme system or a collection of one-screen fixes.
- Can a user identify primary actions without every element using the accent colour?
- Are chart labels readable across the complete palette?
- Do tables remain dense enough for analysis without becoming cramped?
- Do settings, login and drawers feel like the same product as the dashboard?
- Can another team understand, validate and maintain the theme without relying on undocumented one-off fixes?
The result: a theme that behaves like a design system
Panintelligence theming is most effective when CSS hierarchy, product context and visual priority are treated as one problem. The body establishes the foundation. Surface and component hooks create structure. State selectors make interaction predictable. Chart hooks carry the design into chart-rendered text and shapes. Configuration completes the contract with assets and behaviour, while Icons provides the deliberate place to replace default symbols.
The outcome is not simply a branded dashboard. It is a coherent, testable and transferable experience across Panintelligence: quieter where users need to read, emphatic where they need to act, and predictable when teams need to extend it.
RECOMMENDED NEXT STEP Select one production dashboard, agree the foundation and panel system first, then validate component states and specialist contexts before expanding the theme across the organisation.
