Responsive Design — Mobile First, לא Mobile Afterthought

10.1 למה מובייל הוא לא "גרסה משנית" — הסטטיסטיקה הישראלית

תפתחו את Google Analytics של כל אתר ישראלי ותסתכלו על "Device Category". המספר שיחזור כמעט תמיד: 60-70% מהגולשים על מובייל, 25-35% על desktop, 3-5% על טאבלט. באתרי ecommerce ישראליים, במיוחד כאלה שמבקרים דרך Instagram או TikTok, אחוז המובייל מגיע ל-75-85%. באתרי B2B וכלי פרודוקטיביות (SaaS) — נהפוך הוא: 55-65% desktop כי אנשים עובדים מול מחשב. אבל גם שם, ה-mobile traffic הוא הקנייה-הראשונית: אנשים גולשים לאתר ב-LinkedIn בנייד, ואז חוזרים ב-desktop להחליט.

המסקנה: לבנות אתר שנראה נהדר ב-1920px ולא בודק מה קורה ב-375px — זה לבנות אתר שלא יוצג נכון לרוב המשתמשים. זה לא דעה, זה מתמטיקה של Analytics.

מה זה אומר כשמפתח/AI מתייחס למובייל כ-afterthought

"Mobile afterthought" הוא השם המדויק לבעיה: בונים ל-desktop, ואז "מתאימים" את המובייל כתוספת. הסימנים המובהקים של אתר עם mobile afterthought:

• טקסט גדול מדי או קטן מדי במובייל (hero שעובד ב-desktop נראה כמו קיר טקסט ב-375px)
• כפתורים קטנים מדי — פחות מ-44×44px, ואז משתמש מקיש ולוחץ על כפתור שכן
• Horizontal scroll בלתי רצוי — משהו גולש מעבר ל-viewport ומופיע פס גלילה אופקי
• תמונות ענקיות שנטענות גם כשהמשתמש על 4G (תמונה של 2MB בשביל hero שמוצג ב-375×250px)
• Navigation דסקטופי דחוס (7 קישורים אופקיים) שמתכווץ למובייל ונראה כמו ערימה
• Forms עם type="text" במקום type="email"/type="tel" — keyboard לא נכון במובייל
• Modals ו-popups שלא נסגרים במובייל, או שה-X שלהם קטן מדי

10.2 למה AI בונה desktop-first ולמה זה נשבר במובייל

כשאתם כותבים "build me a landing page for a SaaS product" לכל כלי AI (Bolt, Lovable, v0, Claude, Cursor), סביר ב-80%+ שתקבלו קוד כזה:

.hero {
    padding: 120px 80px;
    display: grid;
    grid-template-columns: 1fr 1fr;
    gap: 64px;
    font-size: 64px;
}

@media (max-width: 768px) {
    .hero {
        grid-template-columns: 1fr;
        padding: 60px 20px;
        font-size: 36px;
    }
}

שימו לב ל-3 דברים בקוד הזה — כל אחד מהם תסמין של desktop-first:

1. ה-base styles (מחוץ ל-@media) הם desktop. 120px padding, 64px font-size, grid של 2 עמודות — כל זה מיועד ל-1440px ולמעלה. המובייל מקבל "תיקון" שמבטל את ה-base.
2. שימוש ב-max-width במקום min-width. זה הסימן הכי מובהק ל-desktop-first. max-width: 768px אומר "בגודל מסך קטן מ-768 — החליפי את ה-default". min-width: 768px אומר "בגודל מסך גדול מ-768 — שדרגי מה-mobile base".
3. ה-mobile נראה כמו גרסה מוקטנת של ה-desktop. אותן 2 עמודות שהפכו ל-1, אותו padding שהתכווץ. לא נחשב מה האמת היא צריכה להיות במובייל — למשל, מיקום שונה של ה-CTA, הסרת תמונה דקורטיבית, או תצוגת headline אחרת.

למה AI עושה את זה

שתי סיבות מבניות:

• Training data: רוב הקוד ש-AI ראה במאגרי GitHub הוא desktop-first מתקופת 2012-2020. ה-convention הזה השתנתה בענף ב-2018-2020, אבל training data ישן עדיין משפיע על ברירת המחדל.
• Default device של AI-generated UI: כשמבקשים "landing page", ה-AI מדמיין דף בגדול — כי זו הצורה שהוא ראה הכי הרבה בצילומי מסך ב-training. מובייל הוא adaptation, לא default.

המסקנה: אם לא אומרים ל-AI "mobile-first" מפורשות בפרומפט, בברירת-מחדל תקבלו desktop-first. "make it responsive" לא מספיק — זה רק גורם ל-AI להוסיף @media (max-width: 768px) בסוף. כדי לקבל mobile-first אמיתי, צריך פרומפט ספציפי. לזה נגיע ב-section 10.14.

10.3 Mobile-First — הפילוסופיה והקוד

Mobile-first זו לא דוגמה של "איך לכתוב CSS". זו גישה. המשמעות: ה-default של האתר הוא מובייל, וכל שאר הגדלים הם "שכבות שיפור" (progressive enhancement) שמתווספות לבסיס הזה. בקוד, זה מתורגם לשלושה כללים:

1. Base styles = mobile styles. כל CSS שכתוב מחוץ ל-@media צריך לעבוד ב-320px.
2. רק @media (min-width: ...), לעולם לא max-width. זה מאלץ אתכם לחשוב "מה מתווסף בגודל הזה ומעלה", במקום "מה אני צריך לבטל".
3. Progressive enhancement. בכל breakpoint מוסיפים או משפרים — לא מבטלים או מכסים. אם אתם מוצאים את עצמכם כותבים display: none בתוך media query גדול כדי "להסתיר" משהו ש-mobile לא צריך — זה סימן שה-default שלכם כבר לא mobile-first.

הקוד השיקולי — לפני ואחרי

/* ======== Desktop-First (שגוי) ======== */
.hero {
    padding: 120px 80px;
    grid-template-columns: 1fr 1fr;
    font-size: 64px;
}
@media (max-width: 768px) {
    .hero {
        padding: 40px 16px;
        grid-template-columns: 1fr;
        font-size: 36px;
    }
}

/* ======== Mobile-First (נכון) ======== */
.hero {
    padding: 40px 16px;
    display: grid;
    grid-template-columns: 1fr;
    font-size: 36px;
}
@media (min-width: 640px) {
    .hero {
        padding: 64px 32px;
        font-size: 44px;
    }
}
@media (min-width: 1024px) {
    .hero {
        padding: 120px 80px;
        grid-template-columns: 1fr 1fr;
        font-size: 64px;
    }
}

שימו לב לסדר: base → 640 → 1024. המובייל הוא הבסיס, כל breakpoint נוסף מרחיב את מה שהיה. זו הגישה של Tailwind CSS (ש-AI מכיר היטב), ולכן אם תגידו ל-AI "use Tailwind mobile-first conventions" — זה יתרגם ישירות לסגנון הזה.

למה mobile-first הוא גם טוב ל-performance

• CSS Bundle קטן יותר במובייל: בצורה לוגית — ה-default כבר עושה את העבודה, וכל ה-@media (min-width) נשארים "רדומים" ב-parse במובייל. בפועל ההבדל לא ענק (CSS parsing מהיר), אבל קונספטואלית זה נכון.
• Render קריטי מהיר יותר: ה-browser לא מחשב rules שעכשיו מבוטלות — הוא מחשב את הנכונים מההתחלה.
• חשיבה "minimum viable" של מובייל: כשמתחילים מה-mobile view, אתם מכריחים את עצמכם להחליט מה באמת חשוב. אתר desktop-first ממשיך להעמיס אלמנטים כי "יש מקום". אתר mobile-first מאלץ priority.

10.4 Breakpoint System — 640, 768, 1024, 1280, 1536

Breakpoints הם הרוחבים שבהם ה-layout שלכם "מחליט" לעשות משהו שונה. השאלה הגדולה: מאיפה להביא את המספרים? יש שתי גישות:

1. לעקוב אחרי סטנדרט תעשייתי (Tailwind, Bootstrap) — פחות חשיבה, יותר עקביות, AI מכיר את המספרים.
2. לקבוע לפי ה-content breaks שלכם — יותר מדויק, יותר עבודה, תלוי בעיצוב ספציפי.

המלצה: השתמשו ב-Tailwind defaults כ-baseline, והוסיפו breakpoints custom רק אם ה-content שלכם "נשבר" במקום ספציפי.

Tailwind Breakpoints — הסטנדרט של 2026

CSS Custom Properties ל-breakpoints

CSS לא תומך ב-var(--bp-md) בתוך @media — זה מגבלה של ה-spec. אבל אפשר להגדיר breakpoints כ-custom properties כ-documentation ולשימוש עם PostCSS/Tailwind config, או לשימוש ב-JS/React. הערך הפרקטי: יש לכם מקום אחד ששולט על המספרים.

:root {
    --bp-sm: 640px;
    --bp-md: 768px;
    --bp-lg: 1024px;
    --bp-xl: 1280px;
    --bp-2xl: 1536px;

    /* Container max-widths — שימוש אמיתי ב-CSS */
    --container-sm: 640px;
    --container-md: 768px;
    --container-lg: 1024px;
    --container-xl: 1280px;
}

.container {
    width: 100%;
    max-width: var(--container-lg);
    margin-inline: auto;
    padding-inline: 16px;
}

@media (min-width: 768px) {
    .container {
        padding-inline: 32px;
    }
}

@media (min-width: 1024px) {
    .container {
        padding-inline: 48px;
    }
}

Custom breakpoints — מתי לשבור מהסטנדרט

הכלל הזהב: לא לבחור breakpoint לפי מכשיר, לבחור לפי content break. אם ה-hero שלכם מפסיק להיראות טוב ב-840px (בין md ל-lg של Tailwind), אל תגבילו את עצמכם — תוסיפו breakpoint שם.

תהליך מעשי לבחירת custom breakpoint:

1. פתחו DevTools במצב responsive.
2. גררו את ה-viewport לאט-לאט מ-320 עד 1920.
3. שימו לב לרגעים שבהם משהו "נראה רע" — טקסט נחתך, כפתור מתכווץ מדי, תמונה נשברת.
4. בכל רגע כזה, רשמו את ה-width. זה breakpoint מועמד.
5. אם ה-width קרוב (±20px) ל-breakpoint של Tailwind — השתמשו ב-Tailwind one. אם לא — הוסיפו custom.

10.5 Media Queries vs Container Queries — התשובה של 2026

Media Queries קיימים מ-2012. Container Queries קיבלו full browser support ב-2023. מה ההבדל, ומתי להשתמש בכל אחד?

הכלל המעשי

שלד האתר ← Media Queries. רכיבים לשימוש חוזר ← Container Queries.

למה? כי ה-hero, ה-navigation, וה-footer קשורים ל-viewport (הם חלק מה-frame של הדף). לעומת זאת, כרטיס מוצר יכול להיות גם ב-sidebar של 300px, גם ב-main של 800px, גם ב-modal של 500px. הוא לא צריך לדעת מה גודל ה-viewport — הוא צריך לדעת מה גודל ה-slot שבו הוא יושב.

דוגמת קוד מלאה — אותו card, שני הקשרים

<!-- Layout עם sidebar ו-main -->
<div class="layout">
    <aside class="sidebar">
        <article class="product-card">...</article>
    </aside>
    <main class="main">
        <article class="product-card">...</article>
    </main>
</div>

/* Layout ב-media queries (מגיב ל-viewport) */
.layout {
    display: grid;
    grid-template-columns: 1fr;
    gap: 24px;
}
@media (min-width: 1024px) {
    .layout {
        grid-template-columns: 300px 1fr;
    }
}

/* Product Card — container queries (מגיב ל-slot) */
.sidebar,
.main {
    container-type: inline-size;
    container-name: card-slot;
}

.product-card {
    /* Base — stacked layout, תמיד מתחיל מה-narrow */
    display: grid;
    gap: 12px;
}

.product-card img {
    width: 100%;
    aspect-ratio: 1/1;
}

/* כשהקונטיינר רחב מ-400px — horizontal layout */
@container card-slot (min-width: 400px) {
    .product-card {
        grid-template-columns: 120px 1fr;
        align-items: center;
    }

    .product-card img {
        aspect-ratio: 1/1;
        width: 120px;
    }
}

מה שקורה כאן: ב-sidebar (רוחב 300px) — ה-card יהיה stacked. ב-main (רוחב 800px+) — ה-card יהיה horizontal. הכל אותו קומפוננט, אותו HTML, אותו CSS. פשוט הוא מגיב לקונטיינר שלו במקום למסך.

10.6 Responsive Images — srcset, sizes, picture, WebP, AVIF

התמונות הן בדרך כלל 60-80% ממשקל האתר. תמונה לא מותאמת למובייל היא הסיבה #1 לטעינה איטית, ל-LCP גבוה, ול-bounce rate של 60%+ במובייל. הכלי המרכזי לפתרון: responsive images עם 4 רכיבים: srcset, sizes, <picture>, ופורמטים מודרניים (WebP, AVIF).

srcset + sizes — הפתרון הבסיסי

srcset זו רשימה של אותה תמונה בגדלים שונים. sizes זה רמז לדפדפן כמה רחבה התמונה תהיה ב-layout. הדפדפן שולף את הקטנה ביותר שעדיין מספיקה.

<img
    src="hero-800.jpg"
    srcset="hero-400.jpg 400w,
            hero-800.jpg 800w,
            hero-1200.jpg 1200w,
            hero-1600.jpg 1600w"
    sizes="(min-width: 1024px) 1200px,
           (min-width: 640px) 800px,
           100vw"
    alt="תיאור אמיתי של התמונה"
    width="1200"
    height="800"
/>

הסבר על השדות:

• src — fallback לדפדפנים ישנים שלא תומכים ב-srcset. תמונה בגודל "סביר".
• srcset — רשימת ("url", "רוחב בפיקסלים"). ה-400w אומר "התמונה הזו רחבה 400 פיקסלים אמיתיים".
• sizes — לכל viewport breakpoint, מה יהיה הרוחב של התמונה ב-layout. הדפדפן משתמש בזה לחשב איזו תמונה מ-srcset הכי מתאימה.
• width ו-height — חובה! בלעדיהם יש CLS (Layout Shift) כשהתמונה נטענת. הערכים הם aspect ratio, לא גודל תצוגה.

<picture> — art direction + format fallback

<picture> הוא לשני use cases:

1. Art direction: crop שונה למובייל ול-desktop (למשל, במובייל מקרבים את הפנים של האדם בתמונה, ב-desktop מראים את כל הסצנה).
2. Format fallback chain: AVIF → WebP → JPEG. הדפדפן בוחר את הראשון שהוא תומך.

הקוד המלא המומלץ (העתק-הדבק ל-hero image):

<picture>
    <!-- AVIF — הקטן ביותר (80% חיסכון), נתמך ב-2026 ב-90%+ דפדפנים -->
    <source
        type="image/avif"
        srcset="hero-400.avif 400w,
                hero-800.avif 800w,
                hero-1200.avif 1200w"
        sizes="(min-width: 1024px) 1200px,
               (min-width: 640px) 800px,
               100vw"
    />

    <!-- WebP — חיסכון של 50%, נתמך ב-97%+ דפדפנים -->
    <source
        type="image/webp"
        srcset="hero-400.webp 400w,
                hero-800.webp 800w,
                hero-1200.webp 1200w"
        sizes="(min-width: 1024px) 1200px,
               (min-width: 640px) 800px,
               100vw"
    />

    <!-- JPEG — fallback אוניברסלי -->
    <img
        src="hero-800.jpg"
        srcset="hero-400.jpg 400w,
                hero-800.jpg 800w,
                hero-1200.jpg 1200w"
        sizes="(min-width: 1024px) 1200px,
               (min-width: 640px) 800px,
               100vw"
        alt="תיאור שימושי לקורא מסך"
        width="1200"
        height="800"
        loading="eager"
        fetchpriority="high"
    />
</picture>

פורמטים מודרניים — כמה חוסכים באמת

איך ממירים תמונות: Squoosh.app (חינם, מבית Google) או cwebp/avifenc command line. ב-workflow תקני: העלו תמונה JPEG, הריצו ב-Squoosh, ייצאו 3 רזולוציות (400, 800, 1200) ב-3 פורמטים (AVIF, WebP, JPEG) = 9 קבצים לתמונה.

loading="lazy" — מתי כן ומתי לא

loading="lazy" אומר לדפדפן "אל תטען את התמונה עד שהמשתמש ייגלל קרוב אליה". חוסך bandwidth ו-LCP. אבל יש מקום אחד שאסור להשתמש בו: תמונת ה-hero / LCP.

• ✓ Lazy loading: כל תמונה מתחת ל-fold, תמונות ב-articles ארוכים, thumbnails ברשימות.
• ✗ אסור lazy: hero image, כל תמונה ב-"above the fold" (נראית מיד בטעינה). השתמשו ב-loading="eager" + fetchpriority="high".

10.7 Touch Targets — 44×44px, ו-hit-area expansion

כפתור של 30×30px נראה בסדר ב-DevTools, אבל במובייל אמיתי המשתמש מקיש עליו ולחוץ על הכפתור השכן. זו הסיבה הראשונה לנטישה במובייל — יותר מעומס או עיצוב מכוער. Apple HIG ו-Material Design הגיעו לאותו מסקנה משתי דרכים שונות: אזור אינטראקטיבי חייב להיות לפחות 44×44pt (Apple) / 48×48dp (Material).

איפה זה חשוב במיוחד

• כפתורי CTA (Add to Cart, Submit, Send)
• אייקונים בניווט (close, menu, back)
• form inputs — checkbox, radio, toggle
• Links בתוך paragraphs — קל לפספס עם אצבע
• pagination arrows

Hit-area expansion — כשעיצוב דורש אייקון קטן

לפעמים אתם צריכים אייקון 16×16 מטעמי עיצוב (למשל, Close X בפינת modal). אל תגדילו את האייקון — הרחיבו את אזור הלחיצה באמצעות pseudo-element:

.small-icon-button {
    width: 16px;
    height: 16px;
    position: relative;
    cursor: pointer;
}

/* אזור לחיצה של 44×44, לא נראה, אבל קליק */
.small-icon-button::before {
    content: "";
    position: absolute;
    inset: -14px;  /* מרחיב 14px לכל כיוון = 44×44 */
    /* הערה: אפשר גם להוסיף padding גדול ו-negative margin */
}

התוצאה: אייקון ויזואלי של 16×16, אבל המשתמש יכול להקיש על שטח של 44×44 סביבו. זה הטריק שמציל אתרים עם עיצוב מינימליסטי.

Spacing בין touch targets

שני כפתורים של 44×44 שצמודים — עדיין יקשו על אצבע גדולה. ההמלצה: לפחות 8px spacing בין אזורי לחיצה. זה gap: 8px ב-flex/grid, או margin על הכפתור.

.button-group {
    display: flex;
    gap: 8px;  /* spacing מינימלי בין touch targets */
    flex-wrap: wrap;
}

.button {
    min-width: 44px;
    min-height: 44px;
    padding: 12px 20px;
    /* הערה: padding-based sizing נותן גמישות */
}

10.8 Hamburger Menu — 3 patterns ומתי כל אחד

ה-"Hamburger Menu" (האייקון של 3 קווים שפותח ניווט) הוא הסטנדרט הדה-פקטו של ניווט במובייל. אבל יש 3 patterns עיקריים של איך הוא מתנהג כשלוחצים — ולכל אחד יש use case שונה.

Pattern 1: Slide-in Drawer

המקובל ביותר. התפריט מחליק מהצד (ימין ב-LTR, שמאל ב-RTL) ומכסה כ-70-80% מהרוחב. שאר המסך נהיה overlay חצי-שקוף.

• מתי: אתרי תוכן רגילים, ecommerce, רוב ה-SaaS landing pages.
• יתרון: המשתמש עדיין "רואה" את הדף מאחורי ה-drawer, תחושה של context.
• חיסרון: מקום מוגבל ל-navigation — אם יש לכם 15 קישורים זה צפוף.

Pattern 2: Full-Screen Overlay

התפריט מכסה 100% מהמסך. רקע מלא (לרוב dark ומאותגר עיצובית), type גדול, נתונים נוספים (תמונות, micro-copy).

• מתי: אתרי פרימיום, agency portfolios, Luxury brands — כשהניווט הוא חלק מהחוויה.
• יתרון: המון מקום לעיצוב, מרגיש "יוקרתי", מכריח את המשתמש לפוקוס.
• חיסרון: מנתק מהדף — אם המשתמש "הלך לאיבוד" בתפריט הוא איבד את ההקשר של איפה הוא היה.

Pattern 3: Bottom Tab Bar

לא hamburger במלוא המובן — יש 4-5 אייקונים בתחתית המסך, קבועים, נגישים תמיד. כמו אפליקציה native.

• מתי: אתרי תוכן דינמיים שמשתמשים חוזרים אליהם הרבה (social, news, music apps), או PWAs שרוצים תחושה של אפליקציה.
• יתרון: ניווט תמיד נגיש, האצבע בתחתית המסך (thumb zone), תחושה native.
• חיסרון: רק 4-5 פריטים מקסימום. לא מתאים לאתרים עם navigation מורכב.

מתי לשמור על navigation רגיל גם במובייל

לפעמים hamburger הוא over-engineering. אם יש לכם 3 קישורים בלבד (Home, Services, Contact), שמרו אותם גלויים גם במובייל — רק הקטינו את הגודל. לחוויה טובה יותר: אל תחביאו ניווט פשוט מאחורי hamburger.

10.9 טבלאות Responsive — horizontal scroll, stack-as-cards

טבלאות הן הבעיה הקלאסית של responsive. טבלה של 6 עמודות בת 10 שורות נראית מושלמת ב-desktop, ובמובייל זה או horizontal scroll מעצבן, או squeeze שהופך את הטקסט ללא קריא. יש 3 patterns:

Pattern 1: Horizontal Scroll — פשוט, לפעמים מספיק

עוטפים את הטבלה ב-<div> עם overflow-x: auto. הטבלה נשארת רגילה אבל המשתמש מגלל אופקית.

<div class="table-wrap">
    <table>...</table>
</div>

.table-wrap {
    overflow-x: auto;
    -webkit-overflow-scrolling: touch;
    /* visual hint שאפשר לגלול */
    background:
        linear-gradient(to left, rgba(0,0,0,0.1), transparent) right / 20px 100% no-repeat;
}

• מתי: Data tables לניתוח (spreadsheet-like). המשתמש רוצה לראות את כל העמודות.
• לא טוב ל: pricing tables, comparison tables — המשתמש לא רוצה לגלול, הוא רוצה לקרוא.

Pattern 2: Stack-as-Cards — הפתרון הנקי ביותר

במובייל, הטבלה "מתפרקת" — כל שורה הופכת לכרטיס שבו כל תא הוא label:value. זה דורש קצת יותר CSS אבל נותן חוויה מצוינת.

<table class="responsive-table">
    <thead>
        <tr><th>חבילה</th><th>מחיר</th><th>משתמשים</th><th>תמיכה</th></tr>
    </thead>
    <tbody>
        <tr>
            <td data-label="חבילה">Basic</td>
            <td data-label="מחיר">₪99</td>
            <td data-label="משתמשים">עד 5</td>
            <td data-label="תמיכה">אימייל</td>
        </tr>
        <tr>
            <td data-label="חבילה">Pro</td>
            <td data-label="מחיר">₪299</td>
            <td data-label="משתמשים">עד 20</td>
            <td data-label="תמיכה">צ'אט + אימייל</td>
        </tr>
    </tbody>
</table>

/* Base — מובייל: stack-as-cards */
.responsive-table thead {
    display: none;  /* ב-mobile ה-headers מוחבאים, משתמשים ב-data-label */
}

.responsive-table tr {
    display: block;
    margin-bottom: 16px;
    border: 1px solid var(--border);
    border-radius: 12px;
    padding: 16px;
    background: var(--card-bg);
}

.responsive-table td {
    display: flex;
    justify-content: space-between;
    padding: 8px 0;
    border-bottom: 1px solid var(--border-subtle);
}

.responsive-table td:last-child {
    border-bottom: none;
}

.responsive-table td::before {
    content: attr(data-label);
    font-weight: 600;
    color: var(--text-secondary);
}

/* Desktop — טבלה רגילה */
@media (min-width: 768px) {
    .responsive-table thead {
        display: table-header-group;
    }

    .responsive-table tr {
        display: table-row;
        margin: 0;
        border-radius: 0;
        padding: 0;
    }

    .responsive-table td {
        display: table-cell;
        padding: 12px 16px;
    }

    .responsive-table td::before {
        display: none;
    }
}

התוצאה: ב-desktop נראה כמו טבלה רגילה, במובייל כל שורה היא כרטיס שקריא מצוין עם label+value לכל עמודה. זו חוויית ה-mobile הכי טובה ל-pricing/comparison tables.

Pattern 3: Hide Columns Progressively

מסתירים עמודות פחות חשובות בגדלים קטנים יותר. אפשר לעשות זאת עם CSS:

/* במובייל — רק עמודות 1 ו-2 */
@media (max-width: 767px) {
    table th:nth-child(n+3),
    table td:nth-child(n+3) {
        display: none;
    }
}

/* בטאבלט — 1, 2, 3 */
@media (min-width: 768px) and (max-width: 1023px) {
    table th:nth-child(n+4),
    table td:nth-child(n+4) {
        display: none;
    }
}

• מתי: טבלאות עם מידע hierarchy ברור — עמודה 1 היא זיהוי, שאר הן פרטים נוספים.
• חיסרון: המשתמש לא יודע שיש מידע נוסף. דורש UI כמו "See more columns" או accordion.

10.10 Responsive Spacing Scale — clamp(), ולמה spacing צריך לגדול

טעות שחוזרת בכל אתר AI: spacing זהה בכל המסכים. 48px padding בין sections ב-desktop — 48px גם במובייל. זה קטסטרופה. ב-desktop זה נראה "אוויר", במובייל זה 48px מתוך 667 (iPhone SE) = 7% מהגובה שבוזבז. Spacing חייב להיות responsive — גדל עם המסך.

הסולם המומלץ

שיטה 1: breakpoints מפורשים

.section {
    padding-block: 48px;
    padding-inline: 16px;
}

@media (min-width: 640px) {
    .section {
        padding-block: 64px;
        padding-inline: 24px;
    }
}

@media (min-width: 1024px) {
    .section {
        padding-block: 96px;
        padding-inline: 48px;
    }
}

שיטה 2: clamp() — fluid spacing בלי breakpoints

זו השיטה המודרנית. clamp(min, preferred, max) מאפשר spacing שגדל ביחס לרוחב המסך, בין min ל-max:

:root {
    /* fluid spacing — גדל חלק עם המסך */
    --pad-section-y: clamp(48px, 8vw, 160px);
    --pad-section-x: clamp(16px, 4vw, 80px);
    --pad-card: clamp(16px, 2.5vw, 32px);
    --gap-grid: clamp(16px, 3vw, 48px);
}

.section {
    padding-block: var(--pad-section-y);
    padding-inline: var(--pad-section-x);
}

.card {
    padding: var(--pad-card);
}

.grid {
    display: grid;
    gap: var(--gap-grid);
}

היופי של clamp: ב-320px רוחב, 8vw = 25.6px, אבל ה-min הוא 48px — אז זה 48. ב-1920px, 8vw = 153.6px, אבל ה-max הוא 160px — אז זה 153. בין לבין, זה נע באופן חלק. לא צריך breakpoints.

היתרון: spacing נראה טבעי בכל גודל מסך, ללא "קפיצות" ב-breakpoints. החיסרון: פחות שליטה מדויקת, ודורש הבנה של vw units.

10.11 Content Max-Width — 640/960/1600 ומה מתאים למה

ה-max-width של תוכן היא אחת ההחלטות הכי חשובות בעיצוב responsive. יותר מדי רחב — אי אפשר לקרוא. צר מדי — מרגיש לא יעיל. הכלל: 45-75 תווים לשורה אופטימלי לקריאות (זו Research ישנה של Baymard Institute).

הסולם המומלץ

הקוד המעשי

:root {
    --width-prose: 40rem;      /* 640px — טקסט ארוך */
    --width-content: 64rem;    /* 1024px — landing content */
    --width-wide: 80rem;       /* 1280px — dashboards, wide layouts */
    --width-container: 90rem;  /* 1440px — מכסה max של container */
}

.prose {
    max-width: var(--width-prose);
    margin-inline: auto;
}

.content {
    max-width: var(--width-content);
    margin-inline: auto;
    padding-inline: var(--pad-section-x);
}

10.12 RTL Responsive — אתגרים ייחודיים לעברית

בניית אתר responsive בעברית מוסיפה שכבה של מורכבות. הנה 5 אתגרים ש-AI לא מטפל בהם בברירת-מחדל, וה-CSS ששובר אותם.

1. dir="rtl" + Flexbox — סדר מתהפך טבעית

כשה-HTML יש לו dir="rtl", flexbox מתהפך אוטומטית: justify-content: flex-start = ימין בעברית, שמאל באנגלית. זה עובד מצוין עם flex-direction: row. אבל: אם יש לכם אלמנט שחייב להיות תמיד משמאל (כמו logo חברה לועזית), השתמשו ב-flex-direction: row-reverse או ב-logical properties.

2. CSS Logical Properties — margin-inline-start במקום margin-left

זה השינוי הכי חשוב ל-RTL. במקום margin-left: 24px, השתמשו ב-margin-inline-start: 24px. ב-LTR זה שמאל, ב-RTL זה ימין — הכל אוטומטי.

Browser support ב-2026: 96%+ לכל ה-logical properties. אין סיבה לכתוב margin-left בפרויקט חדש.

3. Hebrew text overflow — אין hyphenation

באנגלית, כשטקסט ארוך, הדפדפן יכול לחלק מילה באמצע עם מקף (hyphens: auto). בעברית — זה לא עובד. אין hyphenation רשמי בעברית. מה זה אומר: מילה ארוכה כמו "הפגנה-ראווה-משותפת" יכולה לגלוש מחוץ לקונטיינר ב-narrow screens.

הפתרון: word-break: break-word + overflow-wrap: anywhere.

.prose,
.card-title {
    word-break: break-word;
    overflow-wrap: anywhere;
    hyphens: none;  /* מפורשות לעברית */
}

4. Layout flip issues — אייקונים ו-gradients

בעיה: חץ שמצביע ימינה (→) ב-LTR צריך להצביע שמאלה (←) ב-RTL. במקום 2 SVGs, השתמשו ב-transform: scaleX(-1) או ב-CSS rotate.

[dir="rtl"] .arrow-icon {
    transform: scaleX(-1);
}

דוגמאות נוספות: gradients שנעים משמאל לימין (linear-gradient(to right, ...)), drop-shadows עם offset ימני (box-shadow: 8px 0 ...). כל זה צריך להתהפך ב-RTL.

5. Mixed content: עברית + אנגלית + מספרים

ב-landing page עברי, יש טקסט כמו "הכירו את ChatGPT-4 ב-$20 לחודש". המספרים והשמות הלועזיים צריכים להישאר LTR בתוך טקסט RTL. הדפדפן בדרך כלל עושה את זה אוטומטית עם Unicode bidi algorithm, אבל לפעמים צריך לעזור לו:

/* בכוח LTR לקטעים ספציפיים */
.ltr-text {
    direction: ltr;
    unicode-bidi: embed;
}

/* או ב-inline — <span dir="ltr">$20</span> */

10.13 Testing Workflow — DevTools, BrowserStack, מכשיר אמיתי

בדיקת responsive היא תהליך של 3 שכבות, לא חד-פעמי. כל שכבה תופסת baggage שונים.

שכבה 1: Chrome/Edge/Firefox DevTools Responsive Mode

הכי מהיר, הכי נגיש. Ctrl+Shift+M (Windows) / Cmd+Option+M (Mac) פותח את ה-responsive mode.

• מה שהוא תופס: שבירות layout, text overflow, breakpoints שלא עובדים, גדלים כלליים.
• מה שלא תופס: touch latency, scroll jank, thermal throttling, real network conditions, צבעים אמיתיים, battery drain.
• tip: השתמשו ב-Device Mode עם throttling של 4G, לא Wi-Fi. זה מדמה תנאי מובייל אמיתיים.

שכבה 2: BrowserStack / LambdaTest / Real Device Cloud

שירותים שנותנים לכם גישה ל-2000+ מכשירים אמיתיים בענן. BrowserStack לא חינם (מ-$29/חודש), אבל יש 14 יום trial, ולפני launch זה שווה את זה.

• מה שהוא תופס: באגים ספציפיים ל-iOS Safari vs Chrome Android vs Samsung Internet. בעיות של touch events, WebKit quirks.
• מה שלא תופס: תחושה אמיתית של אצבע על מסך, איך scroll מרגיש במכשיר שיש בו פחות RAM, thermal.

שכבה 3: מכשיר אמיתי בידיים

הדרך היחידה לתפוס חווית משתמש אמיתית. אין תחליף.

• מה שרק הוא תופס: scroll performance (FPS), touch latency (האם הכפתור מרגיש "לא מגיב"?), thermal throttling (האחרי 5 דקות שימוש CPU מאט), חיי סוללה (אנימציות כבדות שורפות אנרגיה), באגים של keyboard (iOS keyboard פותח מעל הדף ומסתיר inputs).
• workflow מעשי: אחרי כל session של עבודה — 5 דקות בדיקה על iPhone או Android. לפני launch — 30 דקות מקיפות על iPhone + מכשיר Android + מכשיר ישן (4+ שנים) אם אפשר.

10.14 Responsive Audit Prompt + Mobile-First Site Template

שני פרומפטים שכל Vibe Coder צריך בכיס. הראשון — לאודיט של אתר קיים. השני — לבנייה חדשה מאפס.

Prompt 1: Responsive Audit Prompt

קופץ לאתר שכבר קיים, מוצא את הבעיות. העתקו את הפרומפט הבא, הדביקו ל-Claude/Cursor, והצמידו את קוד ה-CSS + HTML.

Please audit this website for mobile-first responsive design issues.
Check for and report:

1. MOBILE-FIRST CHECK: Are media queries using @media (min-width)
   or @media (max-width)? Count each. If max-width dominates,
   this is desktop-first and needs refactoring.

2. VIEWPORT META: Is <meta name="viewport"
   content="width=device-width, initial-scale=1.0"> present?

3. BREAKPOINTS: List all breakpoint values. Flag any that aren't
   standard (640, 768, 1024, 1280, 1536) without clear reason.

4. TOUCH TARGETS: Find all interactive elements (buttons, links,
   inputs, icons). Flag any with width or height under 44px.

5. RESPONSIVE IMAGES: Find all <img> tags. Flag any missing
   srcset, sizes, or loading attributes. Flag hero images with
   loading="lazy" (this hurts LCP).

6. HORIZONTAL SCROLL: Check if any element has
   width > 100vw or overflow issues at 320px viewport.

7. RTL LOGICAL PROPERTIES: If site is Hebrew/Arabic (dir="rtl"),
   flag usage of margin-left/right, padding-left/right, left/right
   positioning. Should use margin-inline-start/end,
   padding-inline-start/end, inset-inline-start/end instead.

8. CONTAINER QUERIES OPPORTUNITY: Find components that appear
   in multiple contexts (e.g., same .card in sidebar AND main).
   These are candidates for @container queries.

9. SPACING RESPONSIVENESS: Check if section padding is responsive
   (different values or clamp()). Fixed padding of 96px+ on mobile
   is wasteful.

10. FONT SIZE ON MOBILE: Flag body text under 16px on mobile —
    zooming required, hurts accessibility and bounce rate.

Output: Prioritized list of issues (Critical / Warning / Nice-to-have)
with specific line numbers and suggested fixes.

Prompt 2: Mobile-First Site Template Prompt

לבנייה חדשה, מאפס. הוסיפו אותו אחרי הפרומפטים של פרקים 1, 3, 4, 5 (colors, typography, layout).

Build this site mobile-first with the following
non-negotiable responsive specs:

=== BASE APPROACH ===
- Start all styles at 320px viewport as the default
- Use ONLY @media (min-width: X) — never max-width
- Progressive enhancement: add complexity at larger sizes

=== BREAKPOINTS (Tailwind defaults) ===
- sm: 640px  — dual-column cards
- md: 768px  — show sidebar, desktop navigation
- lg: 1024px — full desktop layout
- xl: 1280px — wider content max-width
- 2xl: 1536px — max spacing and container

=== RESPONSIVE SPACING (use clamp) ===
- Section padding-block: clamp(48px, 8vw, 160px)
- Section padding-inline: clamp(16px, 4vw, 80px)
- Card padding: clamp(16px, 2.5vw, 32px)
- Grid gap: clamp(16px, 3vw, 48px)

=== CONTENT MAX-WIDTHS ===
- Prose (article): 40rem (640px)
- Content (landing): 64rem (1024px)
- Wide (dashboard): 80rem (1280px)

=== TOUCH TARGETS ===
- All buttons and interactive elements: min-height: 44px, min-width: 44px
- 8px minimum gap between tap targets
- Use padding-based sizing on buttons, not width/height

=== RESPONSIVE IMAGES ===
- Every <img> must have srcset with at least 3 widths
  (400w, 800w, 1200w) and sizes attribute
- Use <picture> with AVIF + WebP sources and JPEG fallback
- Hero / above-fold images: loading="eager" fetchpriority="high"
- Below-fold images: loading="lazy"
- Always include width and height attributes (prevents CLS)

=== NAVIGATION ===
- Mobile: slide-in drawer pattern (hamburger menu)
- Desktop (768px+): horizontal nav bar
- Ensure hamburger button is 44x44px minimum

=== CONTAINER QUERIES ===
- Use @container for reusable components (cards, article items)
- Use @media for layout shell (header, hero, footer)

=== RTL SUPPORT (if Hebrew/Arabic) ===
- Add dir="rtl" to <html>
- Use CSS logical properties: margin-inline-start,
  padding-inline-end, inset-inline-start
- NEVER use margin-left/right directly
- Flip directional icons with transform: scaleX(-1) under [dir="rtl"]

=== VIEWPORT META (required) ===
<meta name="viewport" content="width=device-width, initial-scale=1.0">

=== TESTING CHECKLIST ===
After build, confirm:
- 320px width: no horizontal scroll
- All buttons are tap-able with adult thumb
- Hero image loads first (eager + high priority)
- Body text is 16px+ on mobile
- Section padding responsive (not fixed 96px everywhere)

10.15 תרגילים מעשיים