Mama’s Little Function — S.P.A.R.K. Chat Log

The original used Bootstrap 5.0.2 released in 2021. Bootstrap 5.3.3 is the current stable release. Unlike the Bootstrap 4 → 5 upgrade on the Drag & Drop Circles app (which required renaming every data-toggle attribute and removing jQuery), this upgrade was purely cosmetic: update the CDN links and SRI hashes. No API changes affected this app between 5.0.2 and 5.3.3 — the only data-bs-* attribute in the song is on the navbar toggler, which was already correctly formed.

<link href="bootstrap@5.0.2/..."
      integrity="sha384-EVSTQN3...">
...
<script src="bootstrap@5.0.2/..."
        integrity="sha384-MrcW6...">

<link href="bootstrap@5.3.3/..."
      integrity="sha384-QWTKZy...">
...
<script src="bootstrap@5.3.3/..."
        integrity="sha384-YvpcrY...">

The original navbar was an app island: it pointed back to the app’s own root, listed three app-specific links, and had no relationship to the TNT site structure. The replacement is the standard TNT sticky dark navbar (identical to every other 2026 TNT app), with JS Apps marked active — the same classification as the Drag & Drop Circles app, since Mama’s Little Function is powered entirely by JavaScript.

The SPARK bar sits below the navbar and carries a single link: this chatlog. It also carries the classification label “JS App” and the date. This is the standard mini-navbar pattern established in the TNT 2026 ecosystem.

The original #jumbotron used Bootstrap’s primary blue background with the easyBakeOvenDark.jpg background image applied via CSS, a display-4 heading in Dancing Script, and no TNT structure. The replacement hero section uses the same easyBakeOvenDark.jpg — the image was already in the app’s local images/ folder — with a dark overlay gradient, a Font Awesome blender icon (amber, matching TNT accent color), and the Boogaloo hero title font.

The blender icon in the hero is fas fa-blender (Font Awesome 6.5 built-in). The original app used the custom blender SVG from the root images/ folder only in the old navbar. The Font Awesome version serves the hero cleanly without any additional asset dependency. The user noted the custom SVG exists in the root images folder — it remains available for use in future upgrades.

All page-specific CSS was moved to styles/mamasFunctionStyles.css. The old stylesheet also had a separate styles/mamasFunction-styles.css with jumbotron background rules, mastheadIcon sizing, an old footer pattern, and media-query breakpoint-indicator borders (colored nav borders at each Bootstrap breakpoint — a teaching demonstration of responsive design). In the new version:

• The jumbotron and mastheadIcon rules were removed (those elements no longer exist).
• The breakpoint-indicator nav borders were removed (the TNT navbar does not use this pattern).
• The old footer CSS was removed (replaced by the shared TNT footer from tnt-base-styles.css).
• The lyrics-specific rules (#lyrics, #chorusDiv, p.left, p.right, h4 clear) were preserved exactly and moved into the new external file, with the h4 rule scoped to #lyrics h4 to avoid affecting headings elsewhere.
• The strong rule (uppercase, italic, brown) was scoped to #appSection strong for the same reason.
• The moroccan-flower background was dropped; a white #appSection background replaces it per the user’s preference.

The custom color classes (.text-custom-color1, .bg-custom-color1) and the font aliases (.googleFont1 for Dancing Script, .googleFont2 for Dosis) were preserved unchanged in the new external stylesheet, since the HTML still uses them.

The original init() function handled copyright/update spans, the validate link, and called setup(). It referenced a validateLi element that existed in the old footer but does not exist in the TNT standard footer. Calling getElementById("validateLi") in the new version would return null, causing a TypeError when classList.add("d-none") was called on it.

The fix: init() now handles only the copyright/update spans and calls setup(). The validate link is handled by the standard TNT IIFE pattern at the bottom of the body (same as all other 2026 TNT apps), which checks for the validateLink element and gracefully does nothing if it is absent. The song logic — setup(), showNextVerse(), all array operations — was preserved byte-for-byte including the //dwr! comment.

The original noscript block hides div#primaryContent, footer when JavaScript is disabled. In the new structure, the primary content wrapper is section#appSection, not div#primaryContent. The noscript’s inline style was updated to target div#appSection, footer.

Everything else in the noscript block is unchanged: the “enable JavaScript” message, the Keep Calm image, the link to the legacy noscript demo, and the intentionally non-validating <style>-inside-<noscript> pattern (which has a comment explaining the compromise). The link to the legacy app was updated to the correct path from the new folder location: ../_LegacyTNT/MamasFunctionNoScript-JSBS52022-10-21/index.html.

Adding display: flow-root to the div#lyrics rule creates a Block Formatting Context. The flow-root value was added to CSS specifically for this purpose: it generates a BFC just like a block container, with no side effects. Every floated child of #lyrics now stays inside the box.

div#lyrics {
    font-size: 1.3em;
    max-width: 700px;
    border-radius: 50px;
    margin: 0 auto;
    /* no BFC — floats escape */
}

div#lyrics {
    font-size: 1.3em;
    max-width: 700px;
    border-radius: 50px;
    margin: 0 auto;
    display: flow-root; /* BFC: floats stay inside */
}

Why display: flow-root rather than overflow: hidden? Both create a BFC. But overflow: hidden also clips content that visually extends beyond the element’s box edge — which can affect drop shadows, tooltips, or absolutely positioned children. display: flow-root creates a BFC only; it clips nothing. It is the modern, purpose-built solution.

Why not clearfix? The traditional clearfix (::after { content: ""; display: table; clear: both; }) works by inserting an invisible block after the floated content to force the container to stretch. display: flow-root is the current standard recommendation and achieves the same result with a single property declaration.

Inside #lyrics, after each stanza pair (p.left + p.right), a chorus heading appears. The existing CSS rule #lyrics h4 { clear: both; } ensured that the second and third chorus headings (id="c2" and id="c3", both <h4>) started below their preceding floats. However, the first chorus heading (id="c1") was changed to an <h3> element, so it was not covered by the #lyrics h4 rule. Without clear: both, c1 would try to start alongside the floated stanzas rather than below them, and the second stanza pair would stack incorrectly.

/* only h4 cleared — h3#c1 was missed */
#lyrics h4 {
    clear: both;
    text-align: center;
    margin-bottom: 0;
}

/* h3 = c1, h4 = c2/c3 — all chorus headings clear */
#lyrics h3,
#lyrics h4 {
    clear: both;
    text-align: center;
    margin-bottom: 0;
}

Together, Fix 1 (BFC on #lyrics) and Fix 2 (clear on both h3 and h4) ensure that: (1) the container always grows to contain all floated stanza content, and (2) each new stanza pair starts below the previous one rather than alongside it. The footer is pushed down correctly by the natural block flow of the now-contained lyrics section.

The blender <i> element was wrapped in a <button> with Bootstrap’s data-bs-toggle="modal" and data-bs-target="#functionModal". The button carries zero visual chrome (btn p-0 border-0 bg-transparent) so it renders identically to the plain icon; a custom class blender-egg applies the hover/focus animation via CSS. The aria-label ensures screen-reader users know it opens a function evaluator.

<i class="fas fa-blender me-2"
   style="color: var(--tnt-amber); ..."
   aria-hidden="true"></i>

<button type="button"
        class="btn p-0 border-0 bg-transparent blender-egg"
        data-bs-toggle="modal"
        data-bs-target="#functionModal"
        title="Click me!"
        aria-label="Open function evaluator">
    <i class="fas fa-blender me-2"
       style="color: var(--tnt-amber); ..."
       aria-hidden="true"></i>
</button>

The title="Click me!" attribute delivers the tooltip via the browser’s native implementation: no Bootstrap tooltip JavaScript initialization required, works across all browsers, and can never be blocked by a Content Security Policy. Bootstrap’s tooltip component was considered but rejected for this reason — a native title attribute is simpler, more reliable, and sufficient for a single element.

The modal header (“Feed the Function!”) echoes the song: Mama’s little function eats xs. The three inputs are a Bootstrap 3-column row, each labelled in purple. Default values are deliberately set to match the first verse — m = 3, b = 2, x = 2 — so the first thing a student sees after clicking Run is exactly the arithmetic the song describes: f(2) = 2 + 3·2 = 8. The default state is itself a teaching moment.

The footer has two buttons: Clear (resets all three inputs to their defaults and hides the output) and Run (executes the calculation). The clear button uses Bootstrap’s outline-secondary style; the run button matches the modal header’s purple for visual coherence. Neither closes the modal, so students can experiment with multiple values in a single session without re-opening it.

The output chain shows every step of what a function actually does, in the order the song describes them. Each step is a distinct color: the input x is purple (the app’s dominant color), the function application f(x) is purple italic, the expanded expression is green, the output y is red, and the ordered pair is purple bold. The arrows between steps are gray so they recede visually and the values stand forward.

/* Example with defaults: m = 3, b = 2, x = 2 */
2 → f(2) → 2 + 3·2 → 8 → (2, 8)

The fmtNum() helper handles number display: integers show without a decimal point; non-integers are capped at four decimal places and trailing zeros are trimmed. This means f(1/3) displays as 0.3333 rather than 0.33333333. Negative slope values are wrapped in parentheses ((−3)·2 rather than −3·2) to prevent the display from reading ambiguously as subtraction.

The output <div> starts hidden (d-none), and runFunction() removes that class on first run. A validation guard checks all three fields for NaN and shows a red error message rather than displaying NaN in the chain — important because parseFloat("") returns NaN and students who clear a field would otherwise see meaningless output.

Adding font-size: inherit to the .blender-egg CSS rule restores the inheritance chain. inherit forces a CSS property to take the computed value of its parent instead of any default or browser/framework value. The button now inherits the h1’s large font-size, and the icon’s 0.8em is once again relative to the h1.

.blender-egg {
    cursor: pointer;
    transition: transform 0.2s, filter 0.2s;
    line-height: 1;
    /* Bootstrap .btn set font-size: 1rem here */
    /* icon 0.8em → 0.8 × 1rem = 0.8rem        */
}

.blender-egg {
    cursor: pointer;
    transition: transform 0.2s, filter 0.2s;
    line-height: 1;
    font-size: inherit; /* pass h1 size through */
    /* icon 0.8em → 0.8 × h1-size ≈ 3rem        */
}

Why not just remove font-size: 0.8em from the icon and use the h1 size directly? The 20% reduction was intentional in the original design — the icon is slightly smaller than the title text so it reads as an accent rather than competing for visual weight. Keeping the 0.8em on the icon and using inherit on the button preserves both the relative sizing and the inheritance fix.

Why wasn’t this caught in Stage 3? The button was added and the icon appeared in the same hero, at the same position, with the same amber color. The size difference is obvious on a large screen side-by-side but easy to miss when only looking at the result of a single round of changes. This is exactly the kind of regression that a structured review — or a user who knows what “before” looked like — catches.

Bootstrap 5 exposes all button states as CSS custom properties on the .btn element. Setting them on a custom class creates a fully-behaved outline button variant with no specificity fights:

<!-- HTML -->
class="btn bg-custom-color1 text-light"

/* CSS — bg-custom-color1 loses to btn:hover */
.bg-custom-color1 {
    background-color: var(--mlf-purple);
    /* no !important = overridden on hover */
}

<!-- HTML -->
class="btn btn-outline-mlf"

/* CSS — BS5 variables own every state */
.btn-outline-mlf {
    --bs-btn-color:              var(--mlf-purple);
    --bs-btn-border-color:       var(--mlf-purple);
    --bs-btn-hover-color:        #fff;
    --bs-btn-hover-bg:           var(--mlf-purple);
    --bs-btn-hover-border-color: var(--mlf-purple);
    --bs-btn-active-color:       #fff;
    --bs-btn-active-bg:          var(--mlf-purple);
    ...
}

The result: normal state shows a purple border with purple text and no fill — the outline style the user requested. On hover, the fill appears (purple background, white text), which is the standard Bootstrap outline-button inversion. Bootstrap reads all the hover/active states directly from the CSS variables, so there is no cascade conflict.

This is also the correct pattern for any future custom button variants in the TNT ecosystem: define a .btn-outline-* or .btn-* class using the Bootstrap CSS variable set rather than stacking background/text utilities on top of .btn.