Summary
1 visible change In the dark and
black-friday themes, the blog article rating's empty
summary star changed from white (
#ffffff) to dark gray (
#474747). On the blog's dark background
(rgb(18,31,38)) contrast drops from 16.8:1 to
1.81:1, so the star nearly disappears. It now matches the
unselected "rate this" stars right above it, which were already
#474747 in both builds. That makes it more consistent:
the old white looked like a filled star. But it is below the
3:1 WCAG non-text contrast guideline. See 11 and 20 in the
high-res set (20 is the 5× magnified star), or 11–12 in the
original set, under the dark and black-friday themes. The high-res
pass confirmed it with a pixel diff. The only other pixel
differences were the page scrollbar and sub-pixel crop offsets
(section 5).
No change Everything else, in all three themes plus the default page: homepage, PDP, buttons, labels, rating stars on product cards, footer.
Requires attention
| # | Item | Why it matters | Suggested action |
|---|---|---|---|
| Decide |
Blog rating empty star is nearly invisible in dark and
black-friday. It changed from #ffffff to
#474747 on rgb(18,31,38).
Screenshots 11, 20.
|
Contrast drops from 16.8:1 to 1.81:1, below the 3:1 guideline. It's the only visible change in this PR. It may be intended: it now matches the unselected "rate this" stars, and the old white looked like a filled star. | Ask the design-system team whether it's intended. If it is, consider a lighter gray in dark themes for the empty star and the "rate this" stars, since both are below 3:1. Impact is low today: it only shows on unrated articles in dark-themed sections. |
| Confirm | Re-pointed component tokens produced no CSS change (secondary and disabled main-button, inverse label, irate). | Either they resolve to the same variables on Brastemp, or the storefront doesn't use these component tokens. If it's the latter, the change is silently not applied. | Confirm with the token or storefront owners that this is expected. |
| Gap | Not covered: hover, pressed and disabled states; pages other than the homepage, one PDP and one blog article; the new tokens (chip border, stepper, dropdown xlarge). | Low risk: the per-route CSS is byte-identical and the new tokens aren't used yet. | Re-check when a component adopts the new tokens. The automated Playwright capture planned for later would cover this. |
| FYI | Forced theming breaks some sections in both builds, so it isn't caused by this PR. In black-friday, the "Serviços Brastemp" title is white on a light background. In dark, some headings disappear. Product photos are dimmed. | Only relevant if sections can be themed independently in production. | Check theme combinations that are actually used in the CMS. |
Why these sections
Most of PR #2940 adds new tokens. New tokens can't change anything until a component starts using them, so they weren't a reason to pick any section. What can change existing UI is (a) component tokens that now point to a different semantic token and (b) changed brand values. The changed brand values are all for Whirlpool, Compra Certa and Maytag, none for Brastemp. That leaves the re-pointed component tokens. I picked the pages that show the components those tokens style.
1. Component tokens that now point somewhere else
(components/_variables.scss)
| Token | Before → after | Where it shows on Brastemp | Checked in |
|---|---|---|---|
obt-main-button-object-color-secondary |
object-color-secondary →
…-secondary-overwrite
|
Secondary button text/icon | 03, 06, 10 |
obt-main-button-surface-color-secondary |
surface-color-secondary →
…-secondary-alternative (new token,
var(--brand-default-color-secondary))
|
Secondary button background | 03, 06, 10 |
obt-main-button-surface-color-neutral-disabled
|
…-disabled-variant →
…-disabled-overwrite
|
Disabled buttons (e.g. buy box before a selection) | 10 |
obt-label-text-color-neutral-inverse |
text-color-aways-white →
text-color-inverse
|
Labels/badges on dark or brand backgrounds (coupon chips, discount badges) | 04, 09 |
obt-irate-obj-color-neutral-default |
…-neutral-variant-alternative →
…-neutral-variant-extended
|
Empty rating stars | 04, 09 |
2. The rules that actually changed in the compiled CSS
I diffed the CSS each build serves. The 12 per-route CSS chunks are byte-identical. In the global bundle only two rules changed. Both swap one CSS variable for another, so what matters is what each variable resolves to in each theme:
| Rule | Change | default / light | dark | black-friday | Checked in |
|---|---|---|---|---|---|
| Carousel progress bullet label |
neutral-color-aways-white-overwrite →
neutral-color-inverse-overwrite
|
white → white | white → white | white → white | 01, 03 |
| Blog article rating, empty star |
neutral-color-alternative →
neutral-color-300
|
#b8b8b8 → #b8b8b8 | white → #474747 | white → #474747 | 11, 12 (themed sets) |
3. Baseline checks
The header, nav, footer, category tiles and content cards (01, 02, 05,
07, 08) use neutral surface, text and shadow tokens. The PR added
tokens in that same family (neutral-default-*,
effect-*,
surface-color-secondary-alternative). I included these
sections to confirm nothing changed globally on the page, for example
a CSS variable going missing or a font fallback. The new Montserrat
font is only registered for the acros theme. Brastemp
still uses Gantari.
4. Themes (light / dark / black-friday)
Sections can carry data-theme. The
[data-theme=dark] and
[data-theme=black-friday] blocks redefine the whole
neutral palette. Two variables can be equal in the default theme and
different in another. A token swap that is a no-op in the default
theme can therefore show up under a theme. So I applied the same
logic per theme: resolve both changed rules in each theme block (table
in section 2), then capture every section in each forced theme on
both builds.
How the themes were forced: I injected the theme switcher you
provided, which sets data-theme on every
<section>. The themes used were
light, dark and
black-friday.
How the blog star was checked:
simulated Both preview articles are
rated 5.0, so the empty-star variant isn't rendered. I added the
blog-article-rating__summary-star--empty class to the
summary star in both builds so the changed rule applies. I also
confirmed the computed color with getComputedStyle: OLD
rgb(255,255,255), NEW rgb(71,71,71) in
dark and black-friday, and rgb(184,184,184) in both
builds for light.
Expected differences that are not regressions:
- The hero banner differs because the carousel rotates.
- A ~15px vertical offset in some pairs comes from the sticky header's collapse animation.
- Forcing a theme on every section produces odd results that are identical in both builds. Examples: some headings are white-on-white in dark, "Serviços Brastemp" text is unreadable in black-friday, and product photos are dimmed. These come from the forced theming, not from this PR.
- The themed sets were taken in a different Chrome window, at a 1710px CSS viewport. The default set was taken at 1456px.
5. High-resolution pass
The "High-res + magnified" set redoes every capture at full scale (about 1456px wide, 2.5× the pixels of the original set). It has all four themes, including the default, and the blog page in every theme. The cookie banner is hidden with CSS, not accepted, the same way on both builds.
How the magnified crops were made:
magnified The browser's own zoom can't
add detail, and this Chrome window couldn't be resized. Each
component is enlarged in the page with
transform: scale(2–5), which the browser re-renders
crisply. Unlike CSS zoom, it doesn't re-wrap or reflow
anything. The component gets the background color of its nearest
painted ancestor in the current theme. Later siblings are hidden so
nothing overlaps it. The crop box is the same for both builds.
Pixel diff of the magnified crops (OLD vs NEW):
| Crop | Result |
|---|---|
| 20 – blog empty summary star, dark & black-friday | 7,127 px changed, all inside the star. This is the real change. |
| 20 – same, default & light | Byte-identical |
| 13–18, 21 (product card, buttons, PDP title/price/voltage, rate stars), all themes | Byte-identical, except a 4px edge artifact on 16 (default). 13 and 15 in the default theme differ only by a fractional-pixel offset (anti-aliasing outlines, no solid areas). |
| 19 – add-to-cart, all themes | 16px at the far right edge: the page scrollbar thumb, which sits at a different spot because page heights differ. Not part of the button. |
Not checked visually
Not covered by these screenshots:
obt-chip-border-color-variant,
obt-stepper-object-color-neutral-variant and
obt-dropdown-height-xlarge. These are new tokens, and the
compiled CSS shows no rule using them yet. Hover and pressed states
weren't captured either; their compiled CSS is identical in both
builds.