I Rebuilt 𝕏 From Memory  🔗 **Source:** [I Rebuilt 𝕏 From Memory](https://www.youtube.com/watch?v=Mytj4HHgv-g) > [!note]+ Document Notes > tags: [css-layout, frontend-challenge, css-grid, flexbox, developer-content, ui-recreation] > author: [MISSING] > source: YouTube > reference: https://www.youtube.com/watch?v=Mytj4HHgv-g > date created: 2026-09-05 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # Title: I rebuilt 𝕏 from memory > <!-- deep-read:sections start --> ## Summary - A developer-content YouTube video (channel/creator not identified by name in the transcript; two named participants, "CJ" and "Wes," appear) sets up a timed challenge: Wes, described as a heavy daily X/Twitter user, must recreate the X (Twitter) profile-page layout from memory in 20 minutes using a provided starter HTML/CSS file, with no AI assistance — a rule Wes immediately bends by using editor autocomplete. - CJ, who prepared the challenge, deliberately shuffled the order of the sidebar navigation icons so Wes has to recall the correct order separately from recalling the layout, and used deliberately messy starter markup (nested divs, a stray `<footer>` element, `<br>` tags) that Wes has to fight before styling anything. - Wes works through the build in a fairly disciplined order: overall grid layout (left sidebar, main column, dropping the right sidebar for the given screen size) first, then the individual post/tweet card (avatar + name/handle/timestamp row, then the stats row of icons using a `::before` pseudo-element trick to swap icon backgrounds per `<span>` without repeating markup), then profile bio/avatar polish, then sidebar icon spacing, running out of time before reordering the sidebar icons or coloring links blue. - CJ scores the result live: 4/5 on overall layout, 2/5 (with redemption points) on sidebar icon order (Wes recovers to 4/10 correct icon positions after a hint), and gives a final 3.5/5 stars overall, noting the honest gap between "looks like X in 20 minutes" and "production-quality, accessible, polished UI," which the video states takes closer to "3 more days." - One recurring meta-joke: CJ bans AI code generation but Wes's editor autocomplete still suggests (and briefly inserts) incorrect markup, which CJ calls out as "AI is very wrong here" — used as an explicit contrast between autocomplete-as-assistance versus autocomplete-as-generation. - Risk/tradeoff of using this as a teaching artifact: it's an entertainment-format speed challenge, not a tutorial; several technique choices are explicitly rushed ("I'm just pixel pushing here... normally I would make this stuff the most flexible thing in the world") and are called out by the participants themselves as compromises made for time, not best practice. - Bottom line: the video is a live demonstration of how much of a familiar UI a working developer can reconstruct from memory alone — strong on macro-layout (grid/flexbox structure), weaker on exact visual details (icon order, exact spacing, color of links) that are easy to overlook without a reference open. ## Main Content The challenge format: CJ (who set up the exercise, off-camera commentary implies technical familiarity with the build) gives Wes a starter `style.css` (colors and base variables predefined) and `index.html` (deliberately poor markup, an icon sprite/reference section, and out-of-order sidebar icons) and 20 minutes to recreate the X/Twitter profile page layout entirely from memory, no AI. Wes immediately jokes that editor autocomplete is "old school AI," previewing a running bit for the rest of the video. **Layout-first strategy.** Wes starts by identifying the macro-structure: a wrapper using CSS Grid with a left sidebar, a main column, and (initially) a right sidebar, which Wes quickly discards, reasoning correctly that at the given viewport/screen size the real X UI collapses that column anyway — a decision CJ validates on commentary as "valid" given the screen size, though it also means Wes skips a structural element CJ built into the challenge. Wes narrows the sidebar to a fixed width near 50px and moves the provided icon markup into it. **Fighting the provided markup.** CJ deliberately shipped bad HTML — nested divs, `<br>` tags for spacing, and a stray `<footer>` element — forcing Wes to spend time restructuring rather than just styling. Wes at one point makes the markup worse by accident while trying to fix it ("now they're nested forever inside of each other"), prompting CJ's on-air suggestion that flexbox alone (no extra wrapper element) would solve the same problem more simply — a real, generalizable CSS lesson embedded in the commentary: don't reach for a semantic wrapper element (`<footer>`) purely to get a layout behavior (side-by-side placement) that a flex or grid property already provides on the existing element. **The tweet/post card.** Wes builds the individual post card as a two-column grid (a fixed ~50px avatar column, and a second column for everything else), then places the name/handle/timestamp row using flexbox for the "info" line. For the stats row (reply/retweet/like/view icons), Wes's key technique: apply the same icon-via-background-image approach to a `::before` pseudo-element on each `<span>`, driven by `background-image` and `content` values per span, so each stat icon renders without needing extra markup per icon — CJ narrates this positively as a good move that avoids repeating HTML for every icon instance. Wes debugs a background-image sizing issue by temporarily setting a red background color to make the element's box visible, a standard and correct CSS debugging technique (isolate the box model visually before troubleshooting the content inside it). **Time management and self-assessed tradeoffs.** With time running out, Wes explicitly narrates the shift from "build it right" to "build it fast": "I'm just pixel pushing here... normally I would make this stuff the most flexible thing in the world," directly acknowledging (not hiding) the difference between a considered, maintainable implementation and a timed approximation using hardcoded pixel values and `!important` overrides. Wes also uses a negative `margin-top` to pull the profile avatar up over the banner image — a common real-world technique for exactly this kind of overlapping-avatar UI pattern, applied correctly even under time pressure. **What Wes deprioritized and why it cost points.** Wes never returns to reorder the sidebar icons (CJ shuffled them specifically to test icon-position recall, separate from layout recall) and never colors links blue, both flagged afterward as visible gaps. CJ's live scoring: 4/5 for overall layout (accurate structural recall, correctly dropping the right sidebar for the given screen size); on sidebar icon order, Wes initially forgets one icon ("the more icon") but recovers with a hint, ultimately getting roughly 4 of 10 icon positions right, worth 2/5 with a stated path to partial "redemption" points; final score 3.5/5 overall. CJ frames the gap explicitly as time, not correctness: "the real design is in the like 20 minutes to get there and like 3 more days to get it... very usable and beautiful and has really good UX" — i.e., the 20-minute build correctly captured the macro-shape of a familiar interface, and what's missing is the second-order detail work (exact spacing, icon order, link color, accessibility) that a real production build requires and that memory alone reliably loses first. ### Notes - **Autocomplete-vs-AI-generation distinction is made explicitly on air** and used as the video's recurring joke: Wes calls autocomplete "old school AI," and CJ later calls out a specific autocomplete suggestion as wrong ("AI is very wrong here... I don't know what model he's using"), which is itself a small, accurate point about editor autocomplete/AI suggestions needing verification rather than blind acceptance. - **Grid for macro-layout, flexbox for micro-layout** is the pattern Wes follows throughout without stating it as a rule: the outer wrapper (sidebar/main split) and the two-column post-card (avatar/content) use CSS Grid; the info row, stats row, and sidebar icon list use flexbox. This division (grid for two-dimensional page structure, flex for one-dimensional row/column groups) matches common CSS practice guidance. - **The `::before` pseudo-element icon technique** (one background-driven icon per stat `<span>`, no extra markup) is presented as the more elegant solution versus manually authoring a separate icon element per stat — CJ's commentary flags this as the smart move in the video. - **A real CSS mistake, caught and corrected on air:** wrapping content in a `<footer>` element purely to get side-by-side placement, when a flex/grid display value on the existing element would do the same job without an extra wrapper — CJ's suggested fix ("he doesn't need like a footer element... could just set it to have a flex box") is accurate and generalizable. - **Debugging technique used correctly:** setting a temporary background color on an element to visualize its box before troubleshooting why content inside isn't displaying (used when the icon background wasn't rendering). - **Negative margin for overlapping avatar-over-banner effect** — a standard technique (`margin-top: -50px` on the avatar image) applied correctly under time pressure, matching how this UI pattern is commonly implemented. - **Explicit acknowledgment that speed-run code is not production code**: "I'm just pixel pushing here... normally I would make this stuff the most flexible thing in the world" — Wes names the specific tradeoff (hardcoded values, `!important` use) rather than presenting the rushed result as a best-practice example. - **Scoring breakdown:** 4/5 layout, 2/5 sidebar (recoverable to partial credit via hint-assisted icon-order recall, ~4/10 icons correctly placed), 3.5/5 final — the numeric breakdown itself is a reasonable rubric for this kind of exercise (structure, detail-recall, and holistic polish scored somewhat separately). ## References - No external references, articles, or documentation are cited within the video itself; it is a live-coding challenge with no outside sources consulted on camera. - The real X (Twitter) profile page UI is the implicit reference/ground truth the challenge is scored against, though it is not shown until after the timed portion ends. - A code repository for the starter challenge file is mentioned as being linked "in the description," not reproduced in this transcript. ## Paraphrase CJ challenges Wes, a self-described heavy X user, to rebuild the X profile-page layout from a provided (deliberately messy, deliberately reordered) starter file in 20 minutes with no AI assistance. Wes builds the page in a logical order — overall grid layout first, then the post/tweet card structure, then the stats-icon row using a clever CSS pseudo-element trick, then the bio and avatar — while narrating tradeoffs made purely for time. Wes correctly recalls and reconstructs the big-picture layout but forgets the exact order of the sidebar's navigation icons and never gets to coloring links blue, both of which the person running the challenge specifically built in as separate, harder-to-recall details. The final score (3.5/5) reflects strong structural recall and weaker fine-detail recall, with both participants agreeing the gap between the 20-minute version and a truly finished UI is mostly about time for polish, not a lack of skill. ## Newsletter **A fun one for the CSS-nerds on the list.** In this speed-run challenge video, a developer rebuilds the X (Twitter) profile page from memory in 20 minutes, no AI — starting from deliberately bad starter markup and deliberately shuffled sidebar icons. Worth watching for the technique choices under time pressure: CSS Grid for the page-level layout, flexbox for the smaller rows, and a neat `::before`-pseudo-element trick to swap icon backgrounds per stat without writing repeated markup. Also a good real-world example of catching a live mistake — reaching for a `<footer>` element when a flex property on the existing element would have done the same job with less markup. Final score: 3.5/5, mostly lost on remembering the exact sidebar icon order rather than the layout itself. ## Action Items #### DevRel - Small-scale, low-cost content format worth noting for any developer-education or community content planning: a timed "rebuild this from memory" challenge is an accessible way to demonstrate CSS layout technique without requiring a full tutorial script. #### Documentation - The `::before`-pseudo-element icon-swap pattern and the "flex property instead of a wrapper element" correction are both good, small, self-contained examples for a CSS technique reference or examples-first documentation page. #### Community - Not applicable to this source beyond the DevRel note above — no plugin, WordPress, or governance content. ## Hypotheses 1. Developers recall macro-layout structure (grid regions, column counts) from memory more reliably than fine visual detail (icon order, exact spacing, color values), because macro-structure is encoded as a spatial/functional model while fine detail requires literal visual memory. Testable by running the same "rebuild from memory" challenge across multiple participants and multiple familiar UIs, scoring layout-structure accuracy separately from detail accuracy. 2. Deliberately messy starter markup (as CJ provided) measurably increases total build time compared to clean starter markup, independent of the participant's CSS skill level, because time is spent on markup remediation rather than styling. Testable with a controlled A/B version of the same challenge using clean vs. messy starter HTML. 3. A `::before`/`::after` pseudo-element pattern for repeated icon-per-item UI reduces total markup size and edit surface compared to one explicit icon element per item, without a meaningful accessibility cost, provided the icons are decorative and the semantic label (e.g., a count) is present in real text content. ## Methodology None — this is an entertainment/education-format live-coding challenge video with two participants, not a research study. Its "methodology," such as it is, consists of: a time limit (20 minutes), a starter file with intentionally reordered sidebar icons and intentionally poor markup, an explicit no-AI-tools rule (which the participants themselves note is imperfectly enforced by editor autocomplete), and a live, informal, single-rater (CJ) scoring rubric (three sub-scores summed to a final rating) applied to one participant's single attempt. No control condition, no repeated trials, and no independent scoring exist in this source. ## Questions 1. Would the layout-accuracy vs. detail-accuracy gap observed here (strong grid/flex recall, weak icon-order recall) replicate with a different familiar UI (e.g., a different social platform) and a different participant? 2. Does removing the "no AI" rule change build time or accuracy meaningfully, given that autocomplete already provided partially AI-assisted suggestions in this run? 3. How would the same build score against WCAG 2.2 AA if evaluated for accessibility specifically (the participants joke about "dots" and accessibility mid-build but do not return to address it)? 4. What is the actual real X/Twitter markup and CSS approach for the same components, and how closely does Wes's structural approach (grid page layout, flex rows, pseudo-element icons) match the platform's real implementation? ## Future Research - A structured study of "interface recall from memory" as a way to measure a developer's internalized mental model of a familiar UI, potentially useful as an interview or training exercise format, with a rigorous scoring rubric rather than one rater's live judgment. - A comparative study of pseudo-element-based icon techniques versus icon-font or SVG-sprite approaches for maintainability, bundle size, and accessibility across common patterns like this stats row. - An accessibility-focused follow-up build of the same challenge, scoring semantic HTML, keyboard navigation, and screen-reader labeling separately from visual layout accuracy. ## Implications - **For practice:** the video is a small but genuine demonstration that grid-for-macro/flex-for-micro is a durable, intuitive default that a working developer reaches for under time pressure without needing to consciously decide it a rule — useful as an informal case study when teaching that division to newer developers. - **For education:** the caught-and-corrected `<footer>`-vs-flexbox moment is a good, short, real example of the broader principle "reach for a CSS layout property before reaching for a new wrapper element," suitable for a documentation or teaching aside. - **For accessibility:** the participants' own joke about "dots" and accessibility, followed by no actual accessibility work in the remaining time, is itself a useful illustration of how accessibility considerations get deprioritized under time pressure even when explicitly named as a concern mid-build — worth citing as a realistic (not hypothetical) example in accessibility-advocacy material. - **For security/funding models:** not applicable to this source. ## Learning Styles Assessment Reading level: informal spoken developer banter, roughly grade 7-8 Flesch-Kincaid equivalent; technical vocabulary (grid, flexbox, pseudo-element, `background-image`) used without definition, assuming an audience already familiar with CSS. #### Visual learners - Present: screen-recorded live coding gives a visual learner the actual code and rendered result changing in real time. - Improve: a before/after side-by-side still image (starter file vs. finished build vs. real X page) would help a reader of the transcript alone, who cannot see the screen. #### Aural learners - Present: native format; the two-person commentary format adds explanation on top of the raw screen recording. - Improve: none needed. #### Verbal learners - Present: CJ's real-time narration of what Wes is doing ("he's putting all in the same line... name, handle, and time") gives verbal learners a running plain-language description alongside the code. - Improve: a short glossary of the CSS terms used (grid, flex, pseudo-element, `::before`) would help a verbal learner newer to CSS follow along without pausing to look terms up. #### Kinesthetic learners - Present: strongly served by design — the entire video is a hands-on build, and a viewer is explicitly invited at the end to attempt the same challenge using a linked starter file. - Improve: none needed; this is close to ideal for this learning style already. #### Logical learners - Present: Wes's stated build order (layout → post card → stats icons → bio → sidebar) is a clear, logical, and reusable sequence for approaching this kind of UI-recreation task. - Improve: an explicit numbered checklist version of that sequence would make the logical structure available independent of watching the video. #### Social learners - Present: the two-person, back-and-forth commentary format, plus the explicit invitation to comment "how you did" if a viewer attempts the challenge, both support a social learning style. - Improve: none needed for this format. #### Solitary learners - Present: the transcript, read alone, still conveys the technique choices and reasoning without needing the video itself. - Improve: none needed. #### Naturalistic learners - Not applicable to this source. ## Accessibility Assessment Assessed against WCAG 2.2 AA, treating the video/transcript and the described build artifact as the subject: 1. **1.1.1 Non-text Content (A):** the built stats-row icons are implemented as CSS `background-image` on pseudo-elements with no accompanying text alternative for the numeric counts described — the source itself briefly raises this ("do you care about accessibility at all?") as a joke about the starter file's markup, but the built solution is not shown being corrected for it. 2. **1.3.1 Info and Relationships (A):** the source explicitly notes uncertainty about semantic correctness ("why did you choose to use a heading here... semantically makes sense" — recalled from an unrelated past interview, referenced mid-video) — a real, relevant concern for this exact kind of card/heading markup that goes unresolved in the build itself. 3. **1.4.3 Contrast (Minimum) (AA):** not independently assessable from the transcript alone; the participants discuss gray-on-dark text values by feel ("that gray is too light") rather than by measured contrast ratio, which is a common but insufficient practice for meeting AA contrast requirements. 4. **2.4.7 Focus Visible (AA) / 2.1.1 Keyboard (A):** not addressed at any point in the build; the challenge is scored purely on visual layout fidelity, with no keyboard-navigation or focus-state consideration mentioned. 5. **Media and captions:** the video itself, as a screen-recorded coding session with commentary, would need accurate captions (not independently assessable here) for a Deaf or hard-of-hearing viewer to follow which specific CSS property is being discussed at each moment. ## DEIB Assessment - **Cultural breadth:** not applicable in a meaningful way to this source; a two-person CSS challenge video with no cultural or regional content dimension. - **Inclusive language:** informal, casual peer banter between two participants; no exclusionary or coded language present. - **Neurodiversity support:** the live, continuous, fast-paced narration with frequent topic-jumping (build one thing, comment on time remaining, joke about AI, return to building) could be harder to follow for a viewer who benefits from more structured, chunked content; a timestamped chapter list would help. - **Representation:** two participants, both apparently men based on the transcript's voice patterns and names used, with no other demographic dimension visible in this source; not a concern specific to this content given its narrow technical subject. - **Psychological safety:** low stakes, friendly competitive banter; no evident risk in this source. ## Logical Validity #### Strong reasoning - **Correct, evidence-based diagnosis of a real CSS anti-pattern.** CJ's on-air correction — that a `<footer>` element is unnecessary when a flex/grid display property on the existing element achieves the same side-by-side placement — is technically accurate and is offered with a specific, actionable alternative, not just a criticism. - **Wes's build-order reasoning** (tackle the highest-repetition element, the tweet/post card, early because "there's so many of these posts") is a sound prioritization heuristic: fix the component that appears most often first, since improvements there compound across the page. #### Fallacies - **Minor overclaim, self-aware and not load-bearing:** Wes's repeated "I'm so good at this... I might be the best [coder in the world]" is presented as an obvious, non-serious boast within a comedic format, not an argument requiring correction — noted here only because the section calls for identifying claims of this shape, not because it misleads anyone. - **No other identifiable fallacies**; the video makes few propositional claims beyond direct narration of what is being built and why, which limits the surface area for logical error. #### Tone of voice Casual, competitive, self-deprecating, and comedic throughout, with CJ alternating between encouragement, mock exasperation at Wes's slow pace or markup mistakes, and genuine technical praise for good moves (the pseudo-element icon trick, the negative-margin avatar overlap). ## DARVO Analysis Not applicable to this source. This is a friendly, low-stakes coding challenge between two participants with no accusation, no accused party, and no interpersonal conflict to analyze for deny/attack/reverse-victim-offender dynamics. ## Conclusion The video is a low-stakes but genuinely instructive demonstration of how much of a familiar interface a working developer can reconstruct from memory: strong on macro-structure (grid page layout, correctly dropping unnecessary columns for the given screen size, flexbox for row-level groupings) and weaker on the kind of fine visual detail (exact icon order, link color) that memory loses first without a reference open. The two clearest reusable takeaways are technical, not entertainment-specific: prefer a layout property on an existing element over adding a new wrapper element purely to get a layout behavior, and a `::before`-pseudo-element pattern can replace repeated per-item icon markup cleanly. The gap between the 20-minute result and a finished, accessible, production UI — which neither participant claims to have closed here — is honestly named by both participants as a matter of remaining time and polish, not disputed skill. ## 🔄 Refactor Appendix — I rebuilt 𝕏 from memory ### 📚 Literature Atoms (H3) #### [H1] Reach for a layout property before adding a wrapper element > [!quote] ID:rw_01m1pq5fq2v7r3x0bgdttkn9bv > "modify the HTML. He could just he could just set set it to have a flexbox. He doesn't need like a footer element. >> We are so past like nesting like fixing markup. Uh we have the tools, right? If there's any use for AI, I don't care how anti AI AI you are. There we go. Two unclosed media divs. Is that it? No, that's not right. >> No, AI is very wrong here. I don't know what model he's using. >> I'm bringing it back. >> Just command Z. Just command Z. Yeah, command Z it. Make it a flexbox." The strongest reusable technical lesson: get side-by-side placement from a layout property (flexbox) on the existing element rather than adding a new wrapper element to get the same behavior. Tags: `#atom/literature/h1` #### [H2] Pseudo-element background-images replace repeated per-item icon markup > [!quote] ID:rw_01m1pq5fq2v7r3x0bgdttkn9bv > "Background size contain. There we go. >> There we go. Nailed it. Nailed it. Nailed it. >> Yeah. So now all he has to do is select each span child and then select the right icon for each one. It's looking good. >> Oh, baby, baby, baby, baby. Okay. stats itself needs a little bit of margin. >> I don't know if he's going to get this right, but the icons are technically spread across the bottom. So, it should be like justify space between. >> You know what I need to do is put an" The technique landing in real time: one background-driven pseudo-element icon per stat span, instead of repeated markup for each icon. Tags: `#atom/literature/h2` #### [H3] The honest gap between a 20-minute build and a finished UI > [!quote] ID:rw_01m1pq5fq2v7r3x0bgdttkn9bv > "Twitter. Yeah, >> technically there. And like the real design is in the like 20 minutes to get there and like three more days to like get it like where it's very usable and beautiful and and has really good UX. >> Yeah. So overall on this challenge I give you a three out of five stars. >> Uh plus one bonus star >> or half half a star for the sidebar. So 3.5 stars. All right. If you enjoyed this, if you think you could have done better, let us know down in the comments. Uh also there'll be a link to" Both participants name the remaining gap to a finished, accessible, production UI as a matter of days of polish, not disputed skill — an honest closing tradeoff rather than an overclaim. Tags: `#atom/literature/h3` ### 🧠 Permanent Candidates (H4) #### [P1] Prefer a layout property on an existing element over a new wrapper element Adding a wrapper `<div>` or `<footer>` purely to get a side-by-side or stacked layout is a common but unnecessary markup habit; setting `display: flex` (or `grid`) directly on the element that already holds the children usually gets the same visual result with less DOM. This generalizes past this one video as a default first move whenever a layout goal seems to require new markup. *Candidate; a well-established CSS practice, not just this source's opinion.* Links: [[CSS Layout Patterns]] · [[Reduce DOM Nesting]] Tags: `#atom/zettel/z1` #### [P2] Pseudo-element icon-swapping keeps repeated UI elements markup-light Using `::before` (or `::after`) with a `background-image` set per selector, rather than an `<img>` or icon-font tag repeated for every instance, keeps a repeated small-icon pattern (stat rows, list markers, badges) out of the HTML entirely — at the cost of no built-in text alternative, which has to be added deliberately (e.g., via `aria-label` on the parent) if the icon carries meaning. *Candidate; solid technique, with the accessibility tradeoff worth carrying forward every time it's reused.* Links: [[CSS Pseudo-elements]] · [[Frontend Challenge Techniques]] · [[Accessible Icon Patterns]] Tags: `#atom/zettel/z2` ### ✏️ Fleeting Queue - The stats-row icons built here have no text alternative for the numeric counts they represent — worth flagging any time this pseudo-element technique gets reused in Courtney's own work. `#atom/fleeting/f1` - A semantic-heading question is raised mid-video and left unresolved ("does a heading semantically make sense here") — a recurring markup question worth its own note. `#atom/fleeting/f1` ### → Things 3 (max 2 actions) - [ ] Write a short reusable note pairing the two techniques here (layout-property-over-wrapper, pseudo-element icon swap) with the accessibility caveat, for the personal CSS notes. `#action/h1` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/I Rebuilt 𝕏 From Memory.md|I Rebuilt 𝕏 From Memory by YouTube]] ## Highlights - modify the HTML. He could just he could just set set it to have a flexbox. He doesn't need like a footer element. >> We are so past like nesting like fixing markup. Uh we have the tools, right? If there's any use for AI, I don't care how anti AI AI you are. There we go. Two unclosed media divs. Is that it? No, that's not right. >> No, AI is very wrong here. I don't know what model he's using. >> I'm bringing it back. >> Just command Z. Just command Z. Yeah, command Z it. Make it a flexbox. ([View Highlight](https://read.readwise.io/read/01m1sjh7b879awaw5qpqr9t69x)) - Note: H1 — the strongest reusable technical lesson: reach for a layout property (flexbox) on the existing element before adding a new wrapper element to get the same behavior. Also the AI-autocomplete-goes-wrong moment. #atom/literature/h1 - Tags: atom/literature/h1 - Background size contain. There we go. >> There we go. Nailed it. Nailed it. Nailed it. >> Yeah. So now all he has to do is select each span child and then select the right icon for each one. It's looking good. >> Oh, baby, baby, baby, baby. Okay. stats itself needs a little bit of margin. >> I don't know if he's going to get this right, but the icons are technically spread across the bottom. So, it should be like justify space between. >> You know what I need to do is put an ([View Highlight](https://read.readwise.io/read/01m1sjh9evpyh4a747k3fr8eg1)) - Note: H2 — the pseudo-element icon-swap technique lands: one background-driven icon per stat span, no repeated markup per icon. #atom/literature/h2 - Tags: atom/literature/h2 - Twitter. Yeah, >> technically there. And like the real design is in the like 20 minutes to get there and like three more days to like get it like where it's very usable and beautiful and and has really good UX. >> Yeah. So overall on this challenge I give you a three out of five stars. >> Uh plus one bonus star >> or half half a star for the sidebar. So 3.5 stars. All right. If you enjoyed this, if you think you could have done better, let us know down in the comments. Uh also there'll be a link to ([View Highlight](https://read.readwise.io/read/01m1sjhck1783bhshe2g2he7zf)) - Note: H3 — the honest closing tradeoff: 20 minutes gets the macro-shape right, the remaining gap to a finished, usable, accessible UI is named as days of polish, not disputed skill. #atom/literature/h3 - Tags: atom/literature/h3