Exercise 1: What CSS-in-JS Is, and the Real Problems It Genuinely Solved — Possible Solution
====================================================================

WHAT CSS-IN-JS ACTUALLY IS
------------------------------
Per this chapter, "CSS-in-JS means writing actual CSS rules directly
inside JavaScript or component files (styled-components, Emotion) — a
component's own styling lives literally alongside its own logic in the
same file, generated at runtime by a library that dynamically creates
and injects real <style> rules into the page as components render."
Per the chapter's own example (const Button = styled.button`
background: blue; padding: 1rem; `;), what looks like ordinary CSS
syntax is actually a JavaScript template literal, processed by a
library that generates and inserts genuine CSS rules into the page
dynamically, at the moment the component actually renders.

THE REAL PROBLEM IT SOLVED: TRUE COMPONENT-SCOPED STYLES
------------------------------
Per this chapter, it provided "true component-scoped styles with no
risk of global CSS collision at all — a genuinely stronger guarantee
than BEM's own naming-convention-based scoping, since it's enforced by
the tooling itself, not just developer discipline." BEM (per
css_intermediate_11) relies on developers CONSISTENTLY following a
naming convention to avoid class-name collisions — a real but
discipline-dependent guarantee that a mistake or inconsistency could
still break. CSS-in-JS libraries instead generate genuinely unique,
collision-proof class names automatically, as a structural property of
the tooling itself — a strictly stronger guarantee that doesn't depend
on every developer following a convention correctly every time.

THE REAL PROBLEM IT SOLVED: NATURAL DYNAMIC STYLING
------------------------------
Per this chapter, "dynamic styling based on component props or state
felt genuinely natural... since styles and logic already lived in the
same file and language." Because a component's own styling was written
in the SAME language (JavaScript) as its own logic, directly
referencing that component's own props or state to conditionally style
something felt like a natural, unified way to write code — no need to
manually toggle separate CSS classes based on state from outside the
styling itself.

WHY THIS WAS A LEGITIMATE, SOPHISTICATED APPROACH, NOT A MISTAKE
------------------------------
Per this chapter, "for a real period, this was considered a genuinely
leading-edge, sophisticated approach — not a mistake." Both of the
above were REAL, GENUINE improvements over the CSS-organization
problems that existed at the time (the mid-to-late 2010s) — a
stronger scoping guarantee than BEM's own convention-based approach,
and a genuinely more unified way to express state-dependent styling.
The later decline (covered in cssfw1-8's own later sections) came from
a DIFFERENT, initially less-obvious cost (runtime performance), not
from these original motivations turning out to be wrong or unfounded.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines CSS-in-JS precisely using the chapter's own example, and
explains both of the chapter's own named real motivations (stronger
scoping, natural dynamic styling) individually, explicitly stating why
these were genuine advantages at the time rather than treating the
whole approach as a mistake in hindsight.