feat: add conceptual explanations to Tailwind basics lessons
- Added 'concept' objects to all 5 Tailwind lessons explaining utility-first approach - Lesson 1 (Backgrounds): Explains pre-built utilities vs custom CSS, color scale system - Lesson 2 (Utility-First): Explains utility-first philosophy and problems it solves - Lesson 3 (Text Utilities): Explains naming patterns and color shade system - Lesson 4 (Spacing): Explains base-4 spacing scale and directional shorthands - Lesson 5 (Breakpoints): Explains mobile-first responsive utilities and media queries - All concepts include beginner-friendly explanations and detailed ASCII diagrams - Emphasizes how Tailwind differs from traditional CSS (no naming, no context-switching, no specificity wars) - Diagrams show workflow comparisons, naming patterns, spacing scales, and breakpoint cascades
This commit is contained in:
@@ -16,6 +16,10 @@
|
||||
"sandboxCSS": "",
|
||||
"initialCode": "",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "Tailwind replaces custom CSS classes with pre-built utility classes that apply single CSS properties. Instead of writing .my-box { background-color: #3b82f6; } in a CSS file, you apply bg-blue-500 directly in HTML. The class name bg-blue-500 maps to a specific hex color (#3b82f6) from Tailwind's design system, ensuring consistent colors across your project. This eliminates the need to name things and context-switch between HTML and CSS files.",
|
||||
"diagram": "Traditional CSS vs Tailwind\n\nTraditional CSS Approach:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nHTML: <div class=\"hero-box\">\nCSS: .hero-box { background-color: #3b82f6; }\n ↑ Custom name ↑ Custom color\n\nTailwind Approach:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nHTML: <div class=\"bg-blue-500\">\n ↑ Pre-built utility (no CSS file needed)\n\nColor Scale (50-950):\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nbg-blue-50 ░░░ Lightest\nbg-blue-500 ███ Medium (default)\nbg-blue-950 ███ Darkest\n\nBenefit: No naming, no context-switching"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "contains_class",
|
||||
@@ -34,6 +38,10 @@
|
||||
"sandboxCSS": "/* Traditional CSS approach:\n.card {\n background-color: white;\n padding: 1rem;\n border-radius: 0.25rem;\n}\n*/",
|
||||
"initialCode": "",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "Utility-first CSS inverts traditional workflow: instead of semantic class names (.card, .button) that group multiple properties in separate CSS files, you compose components by combining single-purpose utilities directly in markup. This eliminates three major CSS problems: (1) naming things (no more .primary-btn vs .btn-primary debates), (2) specificity wars (utilities have equal specificity), and (3) unused CSS (only utilities you use get included). The tradeoff is longer HTML class lists, but Tailwind argues this is outweighed by no context-switching and automatic consistency.",
|
||||
"diagram": "Traditional vs Utility-First Workflow\n\nTraditional Semantic CSS:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n1. Write HTML: <div class=\"card\">\n2. Switch to CSS: .card { ... }\n3. Name component: .card, .primary-card?\n4. Fight cascade: .card.special vs .special.card\n5. Dead CSS grows: Old .card variants pile up\n\nUtility-First Approach:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n1. Compose in HTML: <div class=\"bg-white p-4 rounded shadow-sm\">\n2. No CSS file needed (utilities pre-defined)\n3. No naming required (describe what it looks like)\n4. No specificity issues (all utilities = 0,0,1,0)\n5. PurgeCSS removes unused utilities automatically\n\nProblems Solved:\n✓ Naming: bg-white (descriptive, not semantic)\n✓ Specificity: All utilities equal weight\n✓ Dead CSS: Tree-shaking removes unused\n✓ Consistency: Design system baked in\n\nTradeoff:\n✗ Longer class lists in HTML\n✓ But: No CSS file, no context-switching"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "contains_class",
|
||||
@@ -67,6 +75,10 @@
|
||||
"sandboxCSS": "/* Traditional CSS would be:\nh1 {\n color: #2563eb;\n font-size: 1.5rem;\n font-weight: 700;\n}\n*/",
|
||||
"initialCode": "",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "Tailwind's text utilities follow a predictable naming convention that maps directly to CSS properties, making them easy to learn and remember. The pattern property-value (like text-blue-600 for color, text-2xl for size) creates a consistent mental model across all utilities. The color shade system (50-950) ensures accessible contrast ratios: lighter shades (50-300) for backgrounds, medium shades (400-600) for UI elements, darker shades (700-950) for text. This built-in design system prevents arbitrary color choices and maintains visual consistency across your entire application.",
|
||||
"diagram": "Text Utility Naming Patterns\n\nColor Pattern: text-{color}-{shade}\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\ntext-blue-600 → color: #2563eb\n ↑ ↑ ↑\n prop color shade\n\nShade Scale (contrast-optimized):\n50-300 ░░░ Light (backgrounds)\n400-600 ███ Medium (UI elements)\n700-950 ███ Dark (text, WCAG compliant)\n\nSize Pattern: text-{size}\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\ntext-sm → font-size: 0.875rem (14px)\ntext-base → font-size: 1rem (16px)\ntext-2xl → font-size: 1.5rem (24px)\ntext-9xl → font-size: 8rem (128px)\n\nWeight Pattern: font-{weight}\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nfont-normal → font-weight: 400\nfont-semibold → font-weight: 600\nfont-bold → font-weight: 700\n\nBenefit: Predictable, consistent system"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "contains_class",
|
||||
@@ -95,6 +107,10 @@
|
||||
"sandboxCSS": "/* Traditional CSS equivalent:\nbutton {\n padding-left: 1.5rem;\n padding-right: 1.5rem;\n padding-top: 0.75rem;\n padding-bottom: 0.75rem;\n margin-left: auto;\n margin-right: auto;\n}\n*/",
|
||||
"initialCode": "",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "Tailwind's spacing scale uses base-4 (0.25rem = 4px increments) because it creates harmonious visual rhythm and aligns with the 8pt grid system used by most design tools. The directional shorthands (px for horizontal, py for vertical) map to common CSS patterns but use intuitive abbreviations: p for padding, m for margin, x for horizontal axis, y for vertical axis. This system is more concise than CSS (px-6 vs padding-left: 1.5rem; padding-right: 1.5rem;) while being completely predictable: p-4 is always 1rem (4 × 0.25rem), regardless of context.",
|
||||
"diagram": "Spacing Scale & Directional Shorthands\n\nBase-4 Scale (n × 0.25rem):\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\np-1 0.25rem 4px ▏\np-2 0.5rem 8px ▎\np-4 1rem 16px ▌ ← Common default\np-6 1.5rem 24px ▊\np-8 2rem 32px █\np-12 3rem 48px ██\np-16 4rem 64px ████\n\nDirectional Shorthands:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n ┌─── pt-4 ───┐\n │ │\npl-4 ────►┤ p-4 / px-6├◄──── pr-4\n │ py-3 │\n │ │\n └─── pb-4 ───┘\n\np-4 All sides (shorthand)\npx-6 Horizontal (x-axis: left + right)\npy-3 Vertical (y-axis: top + bottom)\npt/pr/pb/pl Individual sides\n\nmx-auto Horizontal centering\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n←auto→ [element] ←auto→\n\nBenefit: Consistent rhythm, predictable values"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "contains_class",
|
||||
@@ -123,6 +139,10 @@
|
||||
"sandboxCSS": "/* Traditional CSS would require media queries:\n.responsive-box {\n width: 100%;\n font-size: 1.125rem;\n}\n@media (min-width: 768px) {\n .responsive-box {\n width: 50%;\n font-size: 1.25rem;\n }\n}\n@media (min-width: 1024px) {\n .responsive-box {\n width: 33.333333%;\n font-size: 1.5rem;\n }\n}\n*/",
|
||||
"initialCode": "",
|
||||
"previewContainer": "preview-area",
|
||||
"concept": {
|
||||
"explanation": "Tailwind's responsive utilities eliminate the need to write media queries by using breakpoint prefixes that compile to min-width media queries. The mobile-first approach means base utilities apply to all screen sizes, then prefixed utilities (md:, lg:) override them at larger breakpoints. This inverts traditional CSS where you write desktop styles first, then override for mobile. Writing w-full md:w-1/2 lg:w-1/3 in HTML is more maintainable than context-switching to a CSS file and writing three separate media query blocks, especially when each breakpoint change is visible right where the element is defined.",
|
||||
"diagram": "Responsive Breakpoint System\n\nMobile-First Cascade:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nw-full md:w-1/2 lg:w-1/3\n ↓ ↓ ↓\nBase @768px+ @1024px+\n\nBreakpoint Scale:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nsm: 640px Mobile landscape\nmd: 768px Tablet portrait\nlg: 1024px Tablet landscape / Desktop\nxl: 1280px Large desktop\n2xl: 1536px Extra large desktop\n\nCompiled CSS (Tailwind generates):\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n.w-full { width: 100%; }\n\n@media (min-width: 768px) {\n .md\\:w-1\\/2 { width: 50%; }\n}\n\n@media (min-width: 1024px) {\n .lg\\:w-1\\/3 { width: 33.333%; }\n}\n\nVisual Effect:\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\nMobile (<768px): [████████████] 100%\nTablet (768-1024): [██████] 50%\nDesktop (1024px+): [████] 33%\n\nBenefit: No media queries, inline responsive logic"
|
||||
},
|
||||
"validations": [
|
||||
{
|
||||
"type": "contains_class",
|
||||
|
||||
Reference in New Issue
Block a user