MARQUEE / TICKER / SCROLLER GENERATION RULES
═══════════════════════════════════════════════════════════════════════════════

TRIGGER KEYWORDS:
When the user mentions any of these keywords, generate a full marquee/ticker/scroller component, writing complete original CSS and HTML for it:
- "ticker"
- "scroller" or "scrolling"
- "marquee"
- "proof bar" or "proof-bar"
- "logo strip" or "logo carousel"
- "testimonial ticker"
- "announcement strip"
- "trust strip"
- "brand strip"
- "sliding text"
- "infinite scroll"
- "continuous loop"
- "carousel" (e.g. "testimonial carousel", "image carousel" — not just "logo carousel")
- "rotating banner" or "rotating strip"
- "moving banner"
- "auto-scroll" or "autoscroll"
- "conveyor"

NEVER ITS OWN <SECTION> — NON-NEGOTIABLE:
A marquee/ticker/scroller must never be wrapped in its own `<section>` element. It is not a page section and must never be treated as one — it must NOT receive a section-divider above or below it, and it must NOT participate in the same-background-adjacent-section-padding logic, because it is not a section at all. Use a plain `<div>` instead of `<section>`. Place this div as a direct child INSIDE an adjacent content section (e.g., appended at the bottom of the hero section, or at the top/bottom of the section immediately before or after it) — never as a sibling `<section>` of its own between two other sections. If the marquee needs visual separation from the section it lives inside, use spacing/padding/a contrasting background color declared directly on the marquee's own outer div — never a section-divider, since dividers only ever belong between two real `<section>` elements.

OUTER CONTAINER MUST SPAN FULL WIDTH — NON-NEGOTIABLE:
The marquee's outermost div must explicitly span the full width of whatever it's nested inside. Since the marquee now lives inside another section's container — which may itself be a flex or grid layout (e.g. a centered hero with items centered rather than stretched) — the outer div needs its own explicit full-width sizing; it cannot rely on inheriting width from its parent's layout behavior. Without this, the marquee can shrink to a narrow intrinsic width instead of spanning the available space, causing the ticker to render in a tiny, cramped viewport where only one item is ever visible at a time and the seamless loop becomes imperceptible — it will look like the content scrolls away and never comes back, rather than looping smoothly. If the marquee's parent uses flexbox, the marquee's outer div should also be told not to shrink and to stretch to fill the cross-axis, regardless of how its siblings are aligned.

POSITION WITHIN HOST SECTION — NON-NEGOTIABLE:
The marquee div must be placed at the very top or very bottom of its host section — as either the first child or the last child of that section — never inserted between other content blocks in the middle of the section's flow. A marquee dropped mid-section breaks the reading flow of whatever text or content surrounds it and visually fractures the section into disconnected pieces. If the user's request doesn't specify which edge, default to placing it at the bottom of the section, after all other content.

DEFAULT HOST SECTION WHEN UNSPECIFIED — NON-NEGOTIABLE: If the user's request doesn't name which section should host the marquee/ticker/scroller (e.g. "add a trust strip" or "add a proof bar," with no section named), the default host is the hero — attached as the hero's last child, following the WHEN THE HOST SECTION IS THE HERO rule immediately below in full (flush bottom edge, zero gap, zero margin/padding on the marquee's own outermost div). Do not default to creating a new standalone section for it, and do not default to placing it inside the second section instead — the hero is the default host whenever placement is genuinely unspecified. This default only applies when the request is silent on placement; if the user names a specific section or position (e.g. "put a logo strip at the bottom of the FAQ section," or "add a scroller between the pricing and FAQ sections"), that explicit instruction wins and overrides this default entirely.

WHEN THE HOST SECTION IS THE HERO — FLUSH TO THE VERY BOTTOM EDGE, ZERO GAP — NON-NEGOTIABLE: This applies both when a marquee/ticker/scroller is explicitly requested for the hero, and by default whenever the user's request doesn't specify a host section at all (per DEFAULT HOST SECTION WHEN UNSPECIFIED above). In either case, it must sit flush against the hero's bottom edge with no visible gap of any kind between the hero's other content and the scroller, and none between the scroller and the section immediately following the hero. This requires getting both sides of that boundary right:
  - The marquee must be the LAST child of the hero, after all other hero content (headline, subhead, CTA, trust row, etc.) — never placed at the top of the hero in this case, regardless of the general "top or bottom" choice above.
  - The marquee's own outermost div must have `margin: 0; padding-top: 0; padding-bottom: 0;` — any vertical spacing the marquee needs internally (e.g. padding around the scrolling track itself) must be applied to an inner wrapper, never to the outermost div that defines where the marquee begins and ends vertically.
  - The hero section itself must have `padding-bottom: 0` — this is already required unconditionally per HERO PADDING AND DIVIDERS in hero.md regardless of whether a marquee is present, so this requirement is automatically satisfied as long as that rule is being followed; do not add hero padding-bottom back in specifically because a marquee is present.
  - Do NOT add margin-top on the marquee to create breathing room from the content above it, and do NOT add margin-bottom to create breathing room from the section below it — the marquee should read as touching both the content above it and the section below it directly, with its own background color (if any) providing visual separation instead of empty space.
  A confirmed-failure pattern to watch for: a marquee placed correctly as the hero's last child, but with a leftover `margin-top` or `padding-top` carried over from treating it like a standalone component rather than a flush-fitted final element of the hero — even a small value here breaks the flush, zero-gap requirement.

DEFAULT TOTAL COUNT — NEVER MORE THAN ONE MARQUEE UNLESS SPECIFICALLY REQUESTED — NON-NEGOTIABLE: Unless the user's request specifically asks for more than one marquee/ticker/scroller (e.g. naming two distinct ones, or explicitly asking for a scroller in more than one place), generate exactly one for the entire page. Never default to adding a second one on your own initiative — not because the page happens to have multiple sections that could plausibly host one, and not because more than one trigger keyword from the list above appears in the page's requested content or copy. A trigger keyword appearing more than once in the request is not the same thing as the user asking for more than one marquee — treat it as still one marquee unless the request is unambiguous that multiple are wanted. The rule immediately below (ONLY ONE SCROLLER/MARQUEE PER SECTION) governs how to distribute scrollers across sections in the case where the user HAS explicitly requested more than one — it is not permission to proactively add additional scrollers beyond what was actually requested.

ONLY ONE SCROLLER/MARQUEE PER SECTION — NON-NEGOTIABLE: Never place more than one marquee/ticker/scroller component inside the same host section, regardless of whether they show different content (e.g. a text benefits ticker and a separate image scroller). A confirmed real-world failure: a section contained both a benefits text ticker and an image results scroller stacked directly on top of each other with no real content separating them, producing a visually cluttered block of nothing but scrolling rows and no actual section content in between. If the user's request calls for multiple scrollers (e.g. one for text benefits and one for image results), each one must be placed in its own separate section — never combined into a single section together. When deciding where to place a second or third requested scroller, either add a new section specifically to host it, or attach it to a different existing section than the one already hosting a scroller — but never let two scrollers share a single section.

SECOND (OR LATER) SCROLLER, IN A NON-HERO SECTION — KEEP THAT SECTION'S NORMAL PADDING, DO NOT FLUSH IT — NON-NEGOTIABLE: When a second scroller's host section is a regular content section (not the hero), place it at the end of that section's content as usual, but do NOT apply the hero's flush-to-the-edge, zero-gap treatment from WHEN THE HOST SECTION IS THE HERO above. That section keeps its own normal padding-bottom completely intact — the platform's standard per-section vertical padding (100px desktop/tablet, 75px mobile) must still apply at the bottom of that section, with the scroller sitting inside that padded space like any other piece of content, not breaking through it to sit flush against the section's outer edge. The hero is a special, one-time exception specifically because of the hero-to-next-section color-match and zero-gap requirements elsewhere in this document — that exception does not generalize to any other section. Do not remove or zero out a non-hero section's padding-bottom just because it happens to host a scroller as its last element.

BREAKING OUT OF THE SECTION'S INNER CONTAINER — NON-NEGOTIABLE:
Most sections wrap their content in a centered, padded inner container (e.g. a `.container` div with `max-width` and `margin: 0 auto`) so that text and cards don't stretch edge-to-edge. A marquee, however, must visually bleed all the way to the true edges of the browser viewport, not just to the edge of that inner container — a marquee that stops at the inner container's max-width, or that stops just short of the true screen edge with a visible gap on either side, looks like a broken, clipped row (exactly like a content grid overflowing its own box) rather than an intentional full-bleed ticker. A confirmed real-world failure: a marquee rendered noticeably narrower than the full screen width, with visible dark gaps remaining on both the left and right edges — the breakout technique was applied but did not fully reach the true viewport edge. To break out of the inner container regardless of how deeply nested the marquee is, apply this on the marquee's outermost div:
  width: 102vw;
  position: relative;
  left: 50%;
  right: 50%;
  margin-left: -51vw;
  margin-right: -51vw;
USE SLIGHTLY MORE THAN 100% — NOT EXACTLY 100%: Notice the values above are 102vw and -51vw, not the more "intuitive" 100vw/-50vw. This is intentional and required, not a typo. Browsers on desktop reserve space for the vertical scrollbar, which means 100vw is often a few pixels WIDER than the actual visible viewport — this is a well-known browser quirk, not a bug in your code. Depending on how that extra width interacts with overflow rules elsewhere on the page, the practical result can be a marquee that falls short of true full-bleed and leaves a visible gap at one or both edges, exactly like the failure described above. Using 102vw width with -51vw margins intentionally overshoots by a small margin on each side, guaranteeing the marquee fully covers the viewport edge-to-edge with a pixel or two to spare, rather than risking falling just short. This slight overshoot is invisible to the user (it just means the marquee's background extends a hair past what's visible) and is the safer choice — always prefer overshooting slightly over a precise 100vw that risks visibly failing to reach the edge.
This centers the marquee on the viewport's horizontal midpoint and forces it to span fully across the viewport, intentionally overshooting both edges very slightly per the explanation above. THIS TECHNIQUE WILL FAIL SILENTLY WITHOUT overflow-x:hidden ON html AND body — CONFIRM THIS BEFORE ASSUMING THE 102VW VALUES ALONE ARE ENOUGH: The negative margins (-51vw) push the marquee's edges outside the normal page boundary on both sides. If `overflow-x: hidden` is not present on `html` and `body` (it is written by you as part of the GLOBAL RESET block — see MOBILE OPTIMIZATION in non_negotiable_rules.md — it is easy to write that block once early in your CSS and then lose track of whether it's actually there by the time you build a marquee later in the same generation), the browser introduces an actual horizontal scrollbar for the whole page to accommodate the overflowing marquee edges. Once that scrollbar exists, the viewport's available width changes, and the marquee's 102vw calculation resolves against a different effective width than intended — the visible symptom is a marquee that appears to start and end inside the screen rather than reaching the true edges, looking exactly like the marquee never broke out of its container at all, even though the 102vw/-51vw values are written correctly. A confirmed real-world failure matching this exact symptom: a stats/metrics marquee rendered visibly indented from the left edge of the screen on desktop, not full-bleed, despite using the correct breakout CSS values. Before finalizing any page with a marquee, explicitly verify `overflow-x: hidden` exists on both `html` and `body` in your actual generated CSS — do not assume it's there because you wrote it once somewhere in the GLOBAL RESET block; re-check it specifically. Do not attempt to achieve full-bleed width by setting `width: 100%` alone; 100% resolves against the immediate parent (the padded inner container), not the viewport, and will simply reproduce the clipped/overflowing look this rule exists to prevent.

PLATFORM RULE CONFLICT — NON-NEGOTIABLE, READ BEFORE WRITING ANY MARQUEE CSS:
Your own required GLOBAL RESET rule (`*, *::before, *::after { ...; max-width: 100%; ... }`, written in your css field per non_negotiable_rules.md) applies to every element on the page that you create — including the marquee track itself. This isn't something imposed on you from outside; it's a rule you write yourself, and it directly conflicts with how a marquee's moving track must behave. The track needs to size itself to the full natural width of all its items combined (which is normally much wider than its visible container — that's what makes it scroll), but your own global reset's max-width:100% caps the track back down to its container's width instead. When that happens, since the items can't all fit at their natural size within a track that's been capped to one container-width, the browser will compress every item to try to make them fit — producing severely squashed, overlapping, illegible text rather than a smoothly scrolling row. To avoid this, you must explicitly override the cap specifically on the track element (set its own max-width to none, not 100%), and explicitly prevent each item from being allowed to shrink below its natural content size. Skipping either of these two overrides will produce the squashed-text failure described above, even if every other part of the marquee is built correctly.
A CONFIRMED REAL-WORLD FAILURE OF EXACTLY THIS: a generated `.benefits-ticker-track` was written as `display:flex; flex-wrap:nowrap; width:max-content;` with no `max-width:none` override, and its items (`.benefits-ticker-item`) had no `flex-shrink:0`. `width:max-content` alone does NOT defeat your own GLOBAL RESET's `*{max-width:100%}` rule — `max-width` always wins over `width` when both are present on the same element, regardless of which one looks more specific or more recently declared, and regardless of the fact that you wrote both rules yourself in the same stylesheet. With 18 items needing roughly 4-5x the available viewport width, the track got capped down to one viewport-width and every item compressed into an unreadable, overlapping smear of text — exactly the failure this section warns about. The fix needed both missing pieces at once: `max-width:none` on the track (not just `width:max-content`), AND `flex-shrink:0` on the items — writing only one of the two still produces broken output. Before finalizing any marquee, check both properties are present on both the track and the items, every time, even when the track also has its own `width` declaration.

CORE STRUCTURE — THREE LEVELS:
A working marquee needs exactly three structural levels, each with a distinct job:
1. An outer container that defines the visible viewport — fixed to the available width, with horizontal overflow hidden so content outside the viewport isn't shown, but vertical overflow visible so nothing gets unexpectedly clipped top or bottom.
2. A single moving track inside that viewport — one continuous horizontal row containing all the items, animated to continuously translate from its starting position to a point exactly halfway through its own total width, then loop back to the start. The items inside this track must never wrap to multiple lines and must never shrink below their natural content width, or the seamless-loop math breaks.
3. Individual items inside the track — each one a single piece of content (an icon plus a short phrase, a stat, a logo mention, etc.), never an interactive element like a button or link, and never allowed to shrink below its own natural width.

SEAMLESS LOOP REQUIREMENT — NON-NEGOTIABLE:
For the loop to be visually seamless (no jump, no flicker, no visible gap at the seam), the full set of items must be duplicated exactly once — write out the complete list of items, then repeat the exact same list immediately after it, character for character, inside the same track. The animation must move the track from its starting position to exactly half of its own total rendered width, then restart instantly. Because the second half of the track is an exact duplicate of the first half, the moment the animation completes its halfway journey and restarts, the visual content at that instant is indistinguishable from the starting frame — this is what makes the loop invisible to the eye. If the two halves are not exact duplicates, or if the animation's end point is not precisely half of the track's actual rendered width, the seam will be visible as a stutter or jump.

HOVER BEHAVIOR:
The animation should pause when the user hovers their cursor over the marquee, and resume when they move away — this gives users a way to actually read content that would otherwise be scrolling past too quickly to read in full.

DIRECTION AND SPEED:
Choose a scroll direction (typically right-to-left) and a duration that allows each item to be comfortably read as it passes — too fast feels like a glitch, too slow feels static. A reasonable desktop pace reads as a slow, steady drift rather than a fast scroll. On mobile, a slightly faster pace is usually appropriate since the viewport is narrower and items pass through view more quickly relative to their reading time; reduce padding around items proportionally as well so spacing doesn't feel excessive on a smaller screen.

CONTENT RULES:
- Keep each item to one short phrase or a single stat/claim — never more than a sentence.
- An icon before the text is welcome if it fits the theme, but isn't required.
- Never use lorem ipsum or placeholder text — every item must be realistic and specific to the niche/offer at hand.
- If items are trust claims or stats, include numbers, timeframes, or quantifiable results where possible (e.g. a specific count, dollar figure, or percentage) rather than vague claims.
- If items are testimonial snippets, keep them to a short quote plus a name/initial, not a full review.
- If items are announcements, keep the tone urgent and benefit-focused.
- If items are brand/logo mentions, use text only — no actual logo images unless the user has supplied real brand assets for this purpose.
- Items must never be clickable, interactive, or styled as buttons or links.

ACCESSIBILITY AND PERFORMANCE:
- The animation should be implemented with pure CSS, not JavaScript — no script is needed to drive a continuously looping horizontal scroll.
- Respect the pause-on-hover behavior above as a baseline accessibility courtesy, since constantly-moving text can be difficult for some users to read.
- Avoid making the track wider than necessary — exactly two full copies of the item list, no more, no less, keeps the animation efficient and the loop point correct.

WHEN SOMETHING ISN'T WORKING — DIAGNOSTIC GUIDANCE:
- If items appear severely compressed, overlapping, or illegible (text crammed on top of itself rather than flowing in a clean row): check that the track's width cap has been explicitly overridden to none rather than left at your own GLOBAL RESET's 100% cap, and that items are explicitly prevented from shrinking — see PLATFORM RULE CONFLICT above. This is the most common cause of garbled-looking marquee text.
- If only one item appears to be visible at a time, with the rest scrolling away and never seeming to loop back: check that the outer container actually spans the full available width (see OUTER CONTAINER section above) — a too-narrow viewport makes the loop technically correct but visually imperceptible.
- If there's a visible jump, stutter, or flicker at the loop point: check that the duplicated item list is an exact, character-for-character match of the original list, and that the animation's endpoint is precisely half of the track's own rendered width, not a fixed pixel value.
- If items are stacking vertically instead of flowing horizontally: check that the track is set up to lay its children out in a single horizontal row that doesn't wrap, and that items are prevented from shrinking below their natural width.
- If the marquee appears clipped on one side, stops short of the browser edge, or looks like it's overflowing a box rather than spanning the full screen: FIRST check that `overflow-x: hidden` actually exists on both `html` and `body` in your generated CSS — its absence is a confirmed real-world cause of this exact symptom (the breakout's negative margins introduce a page-level horizontal scrollbar, which changes the effective viewport width the 102vw calculation resolves against, making the marquee appear indented from the true edge even though its own CSS values are correct). Only after confirming that, check that the outer div uses the 102vw + -51vw negative-margin breakout technique (not exactly 100vw/-50vw, and not `width: 100%`) — see BREAKING OUT OF THE SECTION'S INNER CONTAINER above. `width: 100%` only fills the padded inner container, not the true viewport, and an exact 100vw/-50vw can still fall short of the true edge due to scrollbar-width differences — the slight 102vw/-51vw overshoot exists specifically to prevent this.
- If a divider or curved shape unexpectedly appears directly above or below the marquee: check that the marquee was built as a plain `<div>` nested inside an existing section, not as its own standalone `<section>` element (see NEVER ITS OWN SECTION above) — dividers only apply between two real sections.




═══════════════════════════════════════════════════════════════════════════════
DESKTOP FULL-WIDTH ENFORCEMENT — NON-NEGOTIABLE
═══════════════════════════════════════════════════════════════════════════════

The marquee viewport must ALWAYS occupy the full available desktop width regardless of
whether its parent section uses flexbox, grid, container queries, alignment utilities,
or centered layouts.

Apply ALL of the following to the marquee's OUTERMOST DIV:

width: 102vw;
min-width: 102vw;
max-width: none;

position: relative;
left: 50%;
right: 50%;
margin-left: -51vw;
margin-right: -51vw;

display: block;
flex: 0 0 auto;
align-self: stretch;

If the parent section uses display:flex, the marquee must never be allowed to shrink,
collapse, or inherit the width of sibling content.

If the parent section uses display:grid, the marquee must explicitly span all grid columns:

grid-column: 1 / -1;

A confirmed failure mode occurs when a marquee is inserted into a centered hero layout.
The hero content may only be 600–1200px wide, causing the marquee to inherit that width
instead of the viewport width. When this happens only a small portion of the ticker is
visible and the loop appears broken. The rules above override that behavior.

═══════════════════════════════════════════════════════════════════════════════
DESKTOP EDGE COVERAGE VERIFICATION — NON-NEGOTIABLE
═══════════════════════════════════════════════════════════════════════════════

Before finalizing any marquee:

✓ Left edge background must touch the browser edge.
✓ Right edge background must touch the browser edge.
✓ No visible gutter may exist on either side.
✓ No parent max-width may constrain the marquee.
✓ No parent overflow:hidden may clip the breakout.

If any gutter remains visible on desktop, increase the breakout width rather than
reducing it. Slight oversizing is preferred over any visible gap.

Allowed values:

width: 102vw;
margin-left: -51vw;
margin-right: -51vw;

or

width: 104vw;
margin-left: -52vw;
margin-right: -52vw;

Never revert to width:100%.

═══════════════════════════════════════════════════════════════════════════════
PARENT CONTAINER OVERRIDE — NON-NEGOTIABLE
═══════════════════════════════════════════════════════════════════════════════

The marquee must ignore any inherited constraints from:

.container
.container-fluid
.content-wrapper
.inner-container
.section-inner
.max-width wrappers
.page-builder wrappers

The marquee's outer viewport must always break out of these containers and align
to the browser viewport itself.

No parent max-width may determine marquee width.
The viewport width alone determines marquee width.
