MWPW-194632: Add hub-hero-modal c2 block

[sirivuri]

Summary

• Adds a new hub-hero-modal c2 block under libs/c2/blocks/hub-hero-modal/
• The block renders a slide carousel inside the Hub Hero modal shell, with prev/next navigation, slide counter, keyboard support (←/→), and analytics attributes
• Registered in C2_BLOCKS in libs/utils/utils.js
• Supports data-start-slide (1-based) for Hub Hero deep-link to a specific slide
• Accessible: ARIA carousel/slide roles, live counter region, focus management on nav
• 13 unit tests covering slide rendering, navigation, wrap-around, data-start-slide, and ARIA attributes

JIRA

MWPW-194632

Test page

https://main--da-dc--adobecom.aem.page/drafts/sirivuri/mwpw-194632-hub-hero-modal?milolibs=MWPW-194632--milo--sirivuri&mep=%2Fdc-shared%2Ffragments%2Ftests%2F2026%2Fq2%2Face1205%2Fdc1205-template-sekhar.json--all#tour

Test plan

• Open the test page URL above and verify the carousel renders with dark background
• Verify slide counter shows "1 / 3"
• Click → to advance through all 3 slides and confirm counter updates
• Click ← to go back; confirm wrap-around from slide 1 → slide 3
• Verify keyboard ← / → arrow navigation works when carousel is focused
• Verify CTA button in each slide is reachable and links correctly
• Check desktop layout (≥900px): text panel left, media panel right
• Check mobile layout (<900px): stacked content then media

🤖 Generated with Claude Code

[rgclayton]

@sirivuri What do I need to do to see the modal on your test page?

[sirivuri]

@sirivuri What do I need to do to see the modal on your test page?

@rgclayton you not able to open this ? https://main--da-dc--adobecom.aem.page/drafts/sirivuri/mwpw-194632-hub-hero-modal?milolibs=MWPW-194632--milo--sirivuri#hub-hero-modal

[rgclayton]

I think this needs some clean up. We don't want this in the regular (c1) folder, which this has this update added in both c1 and c2 blocks.
https://github.com/adobecom/milo/pull/5907/changes#diff-1bed5c54647404884b47071a73738c299ec55360d6badf1bd557c123caf2f9ab.

[overmyheadandbody]

Some initial notes on this:

• let's keep the code in the MEP folder for now,
• S2A vars shouldn't need fallback variables, those will cause maintenance issues in the long run, the tokens alone should handle everything
• the code essentially switches all modal UI, has this been vetted with Design? Georouting and other functionality will be impacted, we need to ensure this is desired. I also see some RTL styles that have been removed, has that been tested with this update?
• styles.css can't live in the MEP folder, it needs to be in libs/c2/styles/styles.css
• we prefer a mobile-first approach. max-width in media queries is an indicator that styles need to be flipped, so we have the mobile ones as the default and the higher viewport ones in min-width
• we now use a particular way to author and initialize blocks. Some context is available in #5827. We allow per-viewport content variation, which decorateViewportContent handles automatically. It also handles text overrides

I have more particular comments on the code, but let's clean the PR a bit for now and then we can go into details.

[sirivuri]

Addressing review feedback — here's the status on each item:

(a) MEP folder — Done. Block code is in libs/mep/ace1205/tour/ and libs/mep/ace1205/modal/. Only styles.css changes go directly to libs/c2/ per Jan Ivan's guidance (no manifest entry needed for styles).

(b) S2A fallbacks — Done. Removed 23 unnecessary fallbacks where tokens are defined in styles.css. Kept fallbacks only for 3 tokens not in the system: --s2a-font-family-label, --font-family-adobe-clean-display, --body-font-family.

(c) Modal scope — Kyle confirmed the close button spec is universal for all C2 modals, not just tour. Ryan is in alignment. (Slack thread: C09C8DLTNJZ/p1778684416598359)

(d) styles.css in c2 — Done per Jan Ivan's guidance.

(e) Mobile-first — Done. Flipped from @media (max-width: 768px) to @media (min-width: 769px). Mobile styles are the default, desktop Z-pattern/sizing is in the media query.

(f) decorateViewportContent — Investigated. The tour block has a multi-section structure (N numbered sections with Z-pattern layout, CTA extraction, transition elements, separate header row) that doesn't fit the decorateViewportContent pattern. That utility is designed for blocks with a single content area that varies per viewport (base-card, rich-content, explore-card). Our manual decorateBlockText per-section approach is necessary because each section row needs individual text decoration, heading removal, and CTA extraction — operations that happen inside the section loop, not at the block level. Forcing decorateViewportContent would add complexity without benefit for this structure.

[sirivuri]

Note on duplicate block files (libs/c2/blocks/tour/ + libs/mep/ace1205/tour/):

The tour block loads inside a modal fragment. MEP useBlockCode does not redirect block paths for blocks loaded inside fragments — the manifest is on the parent page but the fragment doesn't inherit the MEP context. So libs/c2/blocks/tour/tour.js 404s even when the manifest has useBlockCode | /libs/mep/ace1205/tour.

The c2 copies exist solely to make ?milolibs= preview work for PR review. The ace1205 copies are the source of truth.

Before merge: Once we confirm the MEP fragment behavior with @jviloria, we'll determine which copies to keep and remove the duplicates.

Preview URL: https://main--da-dc--adobecom.aem.page/drafts/sirivuri/mwpw-194632-hub-hero-modal?milolibs=MWPW-194632--milo--sirivuri#tour

[sirivuri]

✅ Fixed in commit aa99615 - Changed padding-bottom: 24px; to padding-block: 0 24px; to use the standard shorthand property.

Apologies for the incorrect previous response where I said "only bottom padding needed" — you're absolutely right that we should still use padding-block: 0 24px; rather than the single-direction property.

[Deva309]

@sirivuri
As discussed, since the CTA (.promo-cta) styling will now be part of the shared styles, I wanted to discuss a few design-related points:

1. The current hover state only changes the background color. However, if you refer to the offer-hub prototype, both the box background color and the arrow color change on hover. I think we should maintain the same interaction pattern everywhere this CTA is used to ensure a consistent experience.

2. I still noticed a few styling differences that may need adjustment for the CTA:

   • The current CTA height is 58px, whereas the design specifies 56px.
   • The arrow container size is currently 34px, but according to the design it should be 32px.
   • There are also hide/show animations associated with this CTA. I can handle those changes from my side since they are specific to my use case.

To better understand the expected behavior and styling, please refer to the offer-hub Figma and prototype links below:

Figma:
https://www.figma.com/design/q87sUm2fvForRQzxGum5wE/Offer-%E2%80%94-A.com?node-id=13572-2777&t=kCV1394MGWsesMk6-0
Prototype:
https://acom-offer.vercel.app/

I just want to ensure that the CTA maintains a consistent design and interaction experience across all implementations.

Please let me know if you had like to discuss any of these points further.

CC: @rgclayton @narcis-radu

[zagi25]

Also I would separate arrow cta and not style it as ::after , from what I understood X button should have the same styles as arrow button, also I am working on a play/pause button for side-2-side videos that looks the same just with different icon, so maybe we can consolidate all these in styles.css, applying one class will style the button and on block level it can be modified and different icons can be added.

[sirivuri]

@Deva309 Thanks for flagging the dimensions. After reviewing the Figma spec with design:

Height (58px vs 56px): Our current implementation uses S2A design tokens for all spacing/typography:

• padding-block: var(--s2a-spacing-sm) (16px total)
• line-height: var(--s2a-typography-line-height-eyebrow)
• Results in calculated height of 58px

To achieve exactly 56px would require hardcoding height: 56px and breaking the token-based system. This is a design system question: should promo-CTA use hardcoded dimensions, or should we adjust the S2A tokens themselves to produce 56px?

Arrow container (32×32): ✅ Already matches spec

For the hover behavior (background + arrow color change), should we align with the offer-hub interaction pattern? If so, could you share the specific hover state specs or point us to the relevant Figma frame?

cc: @rgclayton @kyletroutman for design system alignment

[Deva309]

@Deva309 Thanks for flagging the dimensions. After reviewing the Figma spec with design:

Height (58px vs 56px): Our current implementation uses S2A design tokens for all spacing/typography:

• padding-block: var(--s2a-spacing-sm) (16px total)
• line-height: var(--s2a-typography-line-height-eyebrow)
• Results in calculated height of 58px

To achieve exactly 56px would require hardcoding height: 56px and breaking the token-based system. This is a design system question: should promo-CTA use hardcoded dimensions, or should we adjust the S2A tokens themselves to produce 56px?

Arrow container (32×32): ✅ Already matches spec

For the hover behavior (background + arrow color change), should we align with the offer-hub interaction pattern? If so, could you share the specific hover state specs or point us to the relevant Figma frame?

cc: @rgclayton @kyletroutman for design system alignment

Hi @sirivuri
Thanks for resolving the styling issues mentioned above.
However, I still notice that the hover behavior is missing. The arrow container background changes to white only when the CTA is clicked, but not on hover.

[zagi25]

Do we need :not(:active) and !important it should work without it, right ?

Suggested change

	.promo-cta:hover:not(:active)::after {
	background-color: var(--s2a-color-transparent-white-24);
	background-image: url('../assets/img/promo-arrow-right.svg');
	}
	/* Active state - Figma 11390:25227 - white bg with black arrow */
	.promo-cta:active::after {
	background-color: var(--s2a-color-content-knockout) !important;
	background-image: url('../assets/img/promo-arrow-right-black.svg') !important;
	border-color: var(--s2a-color-content-knockout) !important;
	}
	.promo-cta:hover::after {
	background-color: var(--s2a-color-transparent-white-24);
	background-image: url('../assets/img/promo-arrow-right.svg');
	}
	/* Active state - Figma 11390:25227 - white bg with black arrow */
	.promo-cta:active::after {
	background-color: var(--s2a-color-content-knockout);
	background-image: url('../assets/img/promo-arrow-right-black.svg');
	border-color: var(--s2a-color-content-knockout);
	}

[zagi25]

This can be simplified by using :is
.tour-title :is(h1, h2, h3, h4, h5, h6)

[zagi25]

variable could be used here --s2a-font-weight-heading

[zagi25]

--s2a-font-weight-caption

[zagi25]

Suggested change

	actionArea.remove();
	actionArea?.remove();