The Primary Colour Change That Left One Button Teal
A retail group runs four ODC apps that share a visual language. After a rebrand, the primary colour changes from #1F7A8C to #0A5C36. A developer updates the primary colour in the Theme Editor and publishes app A. Most buttons turn green, but the checkout 'Place Order' button stays teal. That button has Style Classes btn btn-primary cta-checkout, and the app's global style sheet contains .cta-checkout { background-color: #1F7A8C !important; }. The order-confirmation screen uses a custom web block with an inline style attribute background:#1F7A8C. Apps B and C still show the old teal because each has a copied style sheet from the old brand. App D is correct. The design team wants one source of truth for colour, radius, and spacing.
1. Diagnose why the button ignores the Theme Editor change. Cover specificity, cascade order, and the role of `!important`.
Read the worked answer
The Theme Editor changes the theme's primary token and the generated .btn-primary rule, but it does not rewrite every literal hex value in the app. The checkout button still matches .cta-checkout, which sets background-color to the old hex and adds !important. That declaration beats the theme's .btn-primary background regardless of source order, because an important declaration wins over normal declarations in the author origin. The inline style on the confirmation block is even stronger for that element: an inline declaration beats normal author rules and can only be overridden by an important author rule.
So there are three separate causes: a hardcoded hex in a class, an unnecessary !important, and an inline style. The Theme Editor is working; it is being overridden. Apps B and C are a different problem: their copied style sheets contain the old literal value, so they never received the new token at all.
2. Propose a concrete fix for app A and a governance model for the four apps. What should be a token, what should be a class, and what should be removed?
Read the worked answer
For app A, delete the background-color and !important from .cta-checkout. If the checkout button needs a different emphasis, express it through an approved variant class that reads the token, for example background-color: var(--color-primary); or the theme's button variant, not a literal hex. Replace the inline style on the confirmation block with a class. Keep .cta-checkout only for layout or non-colour concerns such as width or icon spacing.
Governance: colour, radius and spacing are tokens owned by the theme or a shared style sheet. Component variants are classes that consume tokens. Screen-specific CSS is limited to layout. Remove literal hex values and !important from app style sheets; make both fail code review. For apps B and C, replace the copied style sheet with the shared source rather than editing each copy by hand. If a shared module is not available, keep a single documented token file and diff it during release.
3. How would you verify the rebrand across all screens without manually clicking every button?
Read the worked answer
Use three layers. First, search the codebase for the old hex, for !important, and for style= in web blocks; those are the exact patterns that caused this bug. Second, inspect computed styles on one representative instance of each component variant in the browser devtools, not the source CSS, because computed styles reveal what actually won the cascade. Third, add visual regression tests on a small set of high-value screens, such as checkout, order confirmation and the home page, at desktop and phone widths. A screenshot diff will catch a teal button even when nobody remembered to check that screen.
For the four apps, run the same checks in each app's pipeline. Do not rely on a manual sign-off spreadsheet; the copied style sheets in apps B and C show that manual propagation fails.