פרק 3: Easing ותזמון — המדע של תנועה טבעית

למה אנימציה זהה יכולה להרגיש רובוטית או קסומה — והתשובה היא לא הקוד, אלא העקומה. בפרק הזה תלמדו את המדע מאחורי תנועה טבעית — easing curves, spring physics, timing, stagger, choreography — ותצאו עם כלים שהופכים כל אנימציה "שעובדת" לאנימציה "שמרגישה נכון"

3.1 למה תזמון חשוב יותר מהאנימציה עצמה

נתחיל עם שאלה פשוטה: למה אנימציה ב-PowerPoint מרגישה "זולה", אבל אנימציה באתר של Apple מרגישה "יוקרתית"? שניהם עושים fade-in. שניהם מזיזים אלמנטים ממקום למקום. ההבדל הוא לא מה זז — אלא איך זה זז. PowerPoint משתמש ב-easing גנרי (או גרוע מזה — linear). Apple מכיילת כל עקומה, כל duration, כל delay בקפדנות. זה ההבדל בין תנועה מכנית לתנועה שמרגישה "חיה".

ב-1981 פרסמו פרנק תומאס ואולי ג'ונסטון, שני אנימטורים ותיקים של דיסני, את הספר The Illusion of Life. בתוכו הם תיארו 12 עקרונות אנימציה שהנחו את דיסני מאז שנות ה-30. שלושה מתוך 12 העקרונות עוסקים ישירות ב-timing ו-easing:

1. Slow In and Slow Out — אובייקטים מתחילים לזוז לאט, מאיצים, ומאטים לפני שעוצרים. זה בדיוק מה ש-ease-in-out עושה ב-CSS.
2. Timing — מספר הפריימים (=משך הזמן) קובע אם תנועה מרגישה כבדה או קלה. כדור באולינג שנופל ב-200ms מרגיש כמו כדור פינג-פונג. אותו נפילה ב-800ms מרגישה כמו סלע.
3. Secondary Action — תנועות משניות שמלוות את התנועה הראשית. כשדלת נסגרת, הרוח מזיזה את הווילון. ב-web: כשמודאל נפתח, הרקע מיטשטש — שתי אנימציות מתואמות.

המסקנה: האנימציה עצמה (מה זז) היא רק חצי מהסיפור. איך זה זז — המהירות, ההאצה, ההאטה — זה מה שקובע אם זה מרגיש אמיתי או מזויף.

שאר 9 העקרונות של דיסני גם רלוונטיים לאנימציית web, אבל שלושת אלה הם הליבה. בואו נראה איך הם מתרגמים ל-CSS:

עקרון דיסני	תרגום ל-CSS/JS	דוגמה פרקטית
Slow In / Slow Out	ease-in-out או cubic-bezier מותאם	כרטיס שנכנס למסך — מתחיל איטי, מאיץ, מאט לפני שנח
Timing	duration — 100ms vs 800ms	tooltip שמופיע ב-150ms (קל) vs מודאל שנפתח ב-400ms (כבד)
Secondary Action	אנימציות מקבילות עם delay	מודאל נפתח + רקע מיטשטש + overlay fade — שלוש אנימציות מתואמות
Anticipation	תנועה קטנה לכיוון ההפוך לפני התנועה העיקרית	כפתור שמצטמק ב-2px לפני שמתרחב — "מתכונן לקפוץ"
Follow Through	overshoot ב-cubic-bezier	אלמנט שחורג מהיעד ב-5% וחוזר — תחושת מומנטום
Squash & Stretch	scaleX + scaleY לא-אחיד	כדור שנופל: מתמתח לאורך בנפילה, מתרחב לרוחב בנגיעה

אתם לא צריכים לזכור את כל 12 העקרונות. הנקודה היא: אנימטורים מקצועיים הבינו כבר ב-1930 שתזמון ועקומות הם הלב של תנועה משכנעת. 90 שנה אחרי, אותם עקרונות עובדים בדפדפן. כל הפרק הזה הוא בעצם תרגום של העקרונות האלה ל-CSS ו-JavaScript.

הנה דוגמה קונקרטית. קחו כפתור פשוט עם hover effect:

/* גרסה בסיסית — עובד אבל "מת" */
.btn:hover {
  transform: scale(1.05);
  transition: transform 200ms linear;
}

/* גרסה עם anticipation + follow-through — חי */
.btn {
  transition: transform 300ms cubic-bezier(0.34, 1.56, 0.64, 1);
}
.btn:hover {
  transform: scale(1.05);
}
.btn:active {
  transform: scale(0.95); /* anticipation — "מתכונן לקפוץ" */
  transition: transform 100ms ease-in;
}

ההבדל: הגרסה הראשונה פשוט מגדילה את הכפתור. הגרסה השנייה נותנת תחושה של "הכפתור מגיב לי" — הוא מצטמק בלחיצה (anticipation), מתרחב (action), חורג קצת מעבר ל-1.05 וחוזר (overshoot/follow-through). שלושה עקרונות דיסני בשלוש שורות CSS.

זו בדיוק הסיבה שאתם פה. בפרק 2 בניתם אנימציות שעובדות. בפרק הזה תלמדו לגרום להן להרגיש נכון.

3.2 Linear vs Easing — למה Linear נראה רובוטי

ברירת המחדל של כל דבר בעולם הדיגיטלי היא linear — מהירות קבועה מהתחלה ועד הסוף. הבעיה: שום דבר בעולם האמיתי לא זז כך. כשאתם זורקים כדור, הוא מאיץ (כוח משיכה) ומאט (חיכוך אוויר). כשאתם פותחים דלת, היא מתחילה לאט (אינרציה) ומאיצה. כשאתם בולמים מכונית, ההאטה הדרגתית.

linear = רובוט. easing = חיים.

חשבו על זה ככה: כשאתם נוסעים במכונית, אתם לא מגיעים מ-0 ל-100 קמ"ש באופן מיידי ונוסעים ב-100 קמ"ש קבוע עד שאתם עוצרים באופן מיידי. יש האצה הדרגתית, מהירות שיט, והאטה לפני העצירה. זה מה שeasing עושה לאנימציה — נותן לה "משקל" ו"פיזיקה". בלי easing, כל דבר באתר שלכם מרגיש כמו רכבת הרים שמתחילה ונעצרת בלי אזהרה.

ההשלכה לעבודה עם AI היא ברורה: כשאתם מבקשים מ-AI "add animation", הוא בדרך כלל נותן ease כברירת מחדל — שזה בסדר אבל גנרי. כמו להגיד "תבשל אוכל" במקום "תבשל פסטה ברוטב עגבניות צלויות עם בזיליקום טרי". ככל שתהיו ספציפיים יותר לגבי ה-easing, התוצאה תהיה טובה יותר — וזו בדיוק המיומנות שהפרק הזה מלמד.

הנה ההבדל בקוד:

/* רובוטי — מהירות קבועה */
.box-linear {
  transition: transform 400ms linear;
}

/* טבעי — מאיץ בהתחלה, מאט בסוף */
.box-natural {
  transition: transform 400ms ease-in-out;
}

/* שניהם עושים את אותו הדבר: מזיזים קופסה 200px ימינה.
   אבל ההרגשה שונה לחלוטין. */
.box-linear:hover,
.box-natural:hover {
  transform: translateX(200px);
}

אם תנסו את שני הקודים זה לצד זה, תראו שה-linear נראה כמו שולחן שמישהו גורר במהירות קבועה — מכני, צפוי, לא מעניין. ה-ease-in-out נראה כמו חפץ שמישהו זרק — יש לו מומנטום, יש לו עצירה חינוכית. זה ההבדל בין אתר שמרגיש כמו PowerPoint ובין אתר שמרגיש כמו אפליקציה.

3.3 ארבעת ה-Easing הבסיסיים של CSS

CSS מגיע עם 5 ערכי easing מובנים. ארבעה מהם שימושיים (ואחד — linear — כבר הבנתם למה פחות):

שם	cubic-bezier	התנהגות	מתי להשתמש
ease	cubic-bezier(0.25, 0.1, 0.25, 1.0)	מאיץ מהר, מאט בהדרגה	ברירת מחדל טובה לרוב ה-transitions. אם לא בטוחים — תשתמשו בזה
ease-in	cubic-bezier(0.42, 0, 1.0, 1.0)	מתחיל איטי, מאיץ	אלמנטים שיוצאים מהמסך (exit animations). "הולך ונעלם" — מתחיל בעדינות ומאיץ החוצה
ease-out	cubic-bezier(0, 0, 0.58, 1.0)	מתחיל מהר, מאט	אלמנטים שנכנסים למסך (enter animations). "מגיע ונעצר" — נכנס עם אנרגיה ומתייצב
ease-in-out	cubic-bezier(0.42, 0, 0.58, 1.0)	איטי → מהיר → איטי	תנועות שמתחילות ומסתיימות באותו מקום (toggle, accordion, drawer)

3.4 Cubic-Bezier — שליטה מלאה בעקומת התנועה

ארבעת ה-easing הבסיסיים הם shortcuts ל-cubic-bezier — פונקציה מתמטית שמתארת עקומה עם 4 מספרים. כל easing ב-CSS הוא בסך הכל cubic-bezier(x1, y1, x2, y2) — שתי נקודות שליטה שמגדירות את צורת העקומה.

הנה מה שכל מספר עושה:

• x1, y1 — נקודת השליטה הראשונה. קובעת את ההתנהגות בתחילת האנימציה.
• x2, y2 — נקודת השליטה השנייה. קובעת את ההתנהגות בסוף האנימציה.
• ערכי x חייבים להיות בין 0 ל-1 (זמן). ערכי y יכולים לצאת מהטווח — ערך y מעל 1 = overshoot, ערך y מתחת ל-0 = undershoot.

כמה עקומות שימושיות מעבר לבסיסיות:

/* Snappy — מהיר ונחרץ, מצוין לתגובה ללחיצה */
.snappy {
  transition: transform 250ms cubic-bezier(0.2, 0, 0, 1);
}

/* Smooth — עדין וחלק, מצוין לתפריטים */
.smooth {
  transition: transform 400ms cubic-bezier(0.4, 0, 0.2, 1);
}

/* Overshoot — חורג מהיעד וחוזר, מצוין ל-popovers */
.overshoot {
  transition: transform 500ms cubic-bezier(0.34, 1.56, 0.64, 1);
}

/* Dramatic — תנועה דרמטית עם undershoot + overshoot */
.dramatic {
  transition: transform 600ms cubic-bezier(0.68, -0.55, 0.27, 1.55);
}

שימו לב לדפוס: ה-cubic-bezier values שאתם רואים לעיל הם לא מספרים אקראיים. הם תוצר של שנים של ניסוי וטעייה על ידי צוותי עיצוב בחברות כמו Google, Apple, ו-Material Design. הנה ה-"greatest hits" — עקומות שהופיעו שוב ושוב באתרים premium:

שם מקובל	cubic-bezier	מקור	מתי להשתמש
Material Standard	cubic-bezier(0.4, 0, 0.2, 1)	Google Material Design	ברירת מחדל מומלצת לכל מעבר — מאוזן, מקצועי, חלק
Material Decelerate	cubic-bezier(0, 0, 0.2, 1)	Google Material Design	אלמנטים שנכנסים — מאט בחינניות כשמגיע ליעד
Material Accelerate	cubic-bezier(0.4, 0, 1, 1)	Google Material Design	אלמנטים שיוצאים — מאיץ ונעלם
Apple Ease	cubic-bezier(0.25, 0.1, 0.25, 1)	Apple Human Interface	מעברים עדינים, מרגיש "premium Apple"
Expo Out	cubic-bezier(0.16, 1, 0.3, 1)	Framer / Design Studios	כניסות דרמטיות — מהירות ונעצרות בחדות
Back Out	cubic-bezier(0.34, 1.56, 0.64, 1)	Robert Penner / easings.net	overshoot עדין — כפתורים, popovers, badges
Smooth Power	cubic-bezier(0.22, 1, 0.36, 1)	GSAP power2.out	כניסות גדולות — hero, sections, page transitions

טיפ: שמרו את הטבלה הזו. כשאתם מבקשים מ-AI "add animation", הוסיפו "use easing: cubic-bezier(0.4, 0, 0.2, 1)" — תקבלו תוצאה טובה פי 10 מ-"ease" הגנרי.

3.5 Spring Physics — קפיצים, Bounce ו-Elasticity

Cubic-bezier מכסה 90% מהצרכים. הוא מהיר (GPU-accelerated, CSS native, אפס JavaScript), קל להבנה (4 מספרים), ויש לו כלים מצוינים (cubic-bezier.com, easings.net). אבל יש משהו אחד שהוא לא יכול לעשות: תנודות.

ב-cubic-bezier, האנימציה תמיד מתקדמת מנקודה A לנקודה B. היא יכולה לעשות overshoot (לחרוג מעבר ל-B ולחזור), אבל זה overshoot חד-פעמי. כדור שנופל ומקפץ פעמיים לפני שנח? תפריט שנפתח עם bounce קל, חוזר, bounce עדין יותר, ונח? אלה דורשים spring physics — מודל מתמטי שמדמה את ההתנהגות של קפיץ אמיתי.

למה spring מרגיש כל כך טבעי? כי כמעט כל תנועה בעולם האמיתי היא spring. כשאתם מושכים דלת — היא נפתחת, חוזרת קצת, ונחה. כשאתם לוחצים על כפתור פיזי — הוא שוקע, קופץ חזרה, ומתייצב. כשאתם מתקפלים על ספה — הקפיצים דוחפים אתכם קצת למעלה לפני שאתם מתייצבים. הגוף שלנו מכיר spring מהלידה — ולכן spring animation מרגישה "נכונה" באופן אינטואיטיבי.

spring מוגדר על ידי 3 פרמטרים:

פרמטר	מה הוא עושה	ערך נמוך	ערך גבוה
stiffness	עוצמת הכוח שמחזיר את האלמנט למקום	תנועה איטית ועדינה (כמו ג'לי)	תנועה מהירה וחדה (כמו גומייה מתוחה)
damping	כמה מהר התנודות נעצרות	bounce הרבה (כדור פינג-פונג)	כמעט בלי bounce (דלת עם בולם)
mass	"משקל" האלמנט	קל ומהיר (נוצה)	כבד ואיטי (סלע)

ב-CSS אין תמיכה native ב-spring (נכון לאפריל 2026 — יש הצעה של CSS Spring Easing ב-draft, אבל היא עדיין לא זמינה בשום דפדפן). Spring דורש JavaScript — דרך ספריות כמו Framer Motion (React), GSAP, או Motion One.

ההבדל בין הספריות:

• Framer Motion: spring הוא ברירת המחדל. מגדירים stiffness + damping + mass ומקבלים spring טבעי. דורש React.
• GSAP: משתמשים ב-ease: "elastic.out(1, 0.3)" או ease: "bounce.out". לא spring אמיתי (פיזיקלי) אלא פונקציה מתמטית שמדמה spring. עובד בכל framework.
• Motion One: API דומה ל-Framer Motion אבל בלי React. Spring אמיתי עם stiffness/damping. קל משקל (3.8KB).

הנה איך spring נראה בשתי הספריות הפופולריות:

// React + Framer Motion
<motion.div
  animate={{ x: 200 }}
  transition={{
    type: "spring",
    stiffness: 300,  // כוח חזרה — גבוה = חד
    damping: 20,     // ריסון — נמוך = יותר bounce
    mass: 1          // משקל — גבוה = איטי יותר
  }}
/>

// GSAP
gsap.to(".box", {
  x: 200,
  duration: 0.8,
  ease: "elastic.out(1, 0.3)"
  // 1 = amplitude (גובה הקפיצה)
  // 0.3 = period (מהירות התנודה)
});

כשאתם מבקשים spring מ-AI, השתמשו בשפה הזו:

• "bouncy spring" = stiffness: 200-400, damping: 10-15
• "snappy spring" = stiffness: 500-800, damping: 25-35
• "gentle spring" = stiffness: 100-200, damping: 20-30
• "wobbly spring" = stiffness: 150-300, damping: 8-12

איך עקרונות ה-spring מתרגמים לפועל? הנה טבלת המרה שימושית:

רוצים להרגיש	stiffness	damping	mass	תוצאה
Button click	500-700	25-35	0.5-1	תגובה מיידית עם bounce קטנטן אחד — "snappy"
Modal open	300-400	20-25	1	כניסה אלגנטית עם overshoot עדין — "smooth arrival"
Notification pop	400-600	12-18	0.8	bounce בולט אבל קצר — "attention grab"
Page transition	200-300	25-30	1.2	תנועה כבדה ומשמעותית — "something big is happening"
Playful / Fun	150-250	8-12	1	הרבה bounces, אנרגטי — "wobbly jelly"
Drag release	400-600	30-40	0.5	חוזר למקום מהר ובלי bounce — "rubber band"

כשאתם מבקשים spring מ-AI, היו ספציפיים. במקום "add spring animation", תגידו:

/* פרומפט גרוע: */
"Add a spring animation to the modal"

/* פרומפט טוב: */
"Add a spring animation to the modal using Framer Motion.
 Config: type: 'spring', stiffness: 350, damping: 22, mass: 1.
 The modal should scale from 0.85 to 1 (not translate — scale feels
 more natural for modals). The backdrop should fade in with
 duration: 200ms, ease: 'ease-out', starting 30ms before the
 modal spring begins. Include prefers-reduced-motion: the modal
 should appear immediately at scale 1 with no animation."

שימו לב לנוסחה: (1) ספרייה ספציפית (Framer Motion), (2) מספרים מדויקים (stiffness: 350, damping: 22), (3) סוג התנועה (scale, not translate), (4) תיאום עם אלמנטים אחרים (backdrop timing), (5) reduced motion fallback. חמשת המרכיבים האלה הם ההבדל בין אנימציה גנרית לאנימציה מקצועית.

3.6 Stagger — עיכוב מדורג בין אלמנטים

אחד האפקטים הכי מרשימים שאפשר ליצור עם כמעט אפס מאמץ הוא stagger — כשסדרת אלמנטים (כרטיסים, פריטי רשימה, אייקונים) נכנסים אחד אחרי השני עם הפרש זמן קבוע. במקום שכולם מופיעים בבת אחת (=שעמום), כל אחד מגיע חצי שנייה אחרי הקודם (=מרשים).

Stagger ב-CSS טהור:

/* כל כרטיס מקבל delay שגדל */
.card {
  opacity: 0;
  transform: translateY(30px);
  animation: fadeUp 500ms ease-out forwards;
}

.card:nth-child(1) { animation-delay: 0ms; }
.card:nth-child(2) { animation-delay: 100ms; }
.card:nth-child(3) { animation-delay: 200ms; }
.card:nth-child(4) { animation-delay: 300ms; }
.card:nth-child(5) { animation-delay: 400ms; }

@keyframes fadeUp {
  to { opacity: 1; transform: translateY(0); }
}

/* דרך יותר אלגנטית עם custom properties: */
.card {
  animation-delay: calc(var(--i, 0) * 100ms);
}
/* ב-HTML: style="--i: 0", style="--i: 1", etc. */

Stagger ב-GSAP (הרבה יותר פשוט):

gsap.from(".card", {
  y: 30,
  opacity: 0,
  duration: 0.5,
  ease: "power2.out",
  stagger: 0.1  // 100ms בין כל אלמנט
});

שורה אחת של stagger: 0.1 ב-GSAP מחליפה את כל ה-nth-child selectors. זו אחת הסיבות שספריות JS שוות את המשקל — כשיש סדרת אלמנטים.

יש כמה סודות לstagger שנראה מקצועי:

הפרש הזמן הנכון

מהניסיון — 80-120ms הוא ה-sweet spot לרוב המקרים. הנה למה:

• 50ms ומטה: מהיר מדי — כמעט לא מבחינים בstagger, נראה כמו כניסה בבת אחת עם "רעד"
• 80-120ms: מושלם — מרגיש כמו "גל" שזורם, העין עוקבת אבל לא מחכה
• 150-200ms: איטי — עובד אם יש 3-4 אלמנטים, אבל עם 8+ אלמנטים המשתמש מחכה כמעט 2 שניות לאחרון
• 250ms ומעלה: מתסכל — המשתמש רואה "חורים" בדף ומנסה לגלול לפני שהכל נטען

כלל אצבע: חשבו על ה-stagger total time: delay × (items - 1). אם יש 8 כרטיסים עם 100ms stagger, סך ה-stagger הוא 700ms. מעל שנייה = קצרו את ההפרש.

כיוון ה-stagger

ב-grid, stagger יכול לרוץ בכמה כיוונים:

• שמאל לימין (או ימין לשמאל ב-RTL): ברירת מחדל, עובד היטב עם כרטיסים בשורה
• מלמעלה למטה: עובד עם רשימות אנכיות
• מהמרכז החוצה: האלמנט האמצעי נכנס ראשון, אלה מסביב אחריו — מרשים ב-grids סימטריים
• אקראי: כל אלמנט מקבל delay רנדומלי — מרגיש "טבעי" ופחות מכני. GSAP תומך ב-stagger: { each: 0.1, from: "random" }

/* GSAP — stagger מתקדם */
// מהמרכז החוצה:
gsap.from(".card", {
  y: 30, opacity: 0, duration: 0.5,
  stagger: { each: 0.1, from: "center" }
});

// אקראי:
gsap.from(".card", {
  y: 30, opacity: 0, duration: 0.5,
  stagger: { each: 0.1, from: "random" }
});

// Grid 2D (שורות + עמודות):
gsap.from(".card", {
  y: 30, opacity: 0, duration: 0.5,
  stagger: { each: 0.08, grid: [3, 4], from: "start" }
});

3.7 Duration — כמה זמן צריכה להימשך אנימציה?

אחת השאלות הכי נפוצות שתלמידים שואלים היא "כמה זמן צריכה להימשך אנימציה?" — והתשובה הקצרה היא: תלוי בגודל ובהקשר. אנימציות קטנות (hover state, tooltip) צריכות להיות כמעט מיידיות — 100-200ms. אנימציות גדולות (page transition, hero reveal) יכולות לקחת יותר זמן — 500-800ms — כי העין צריכה לעקוב אחרי תנועה גדולה יותר.

הטעות הנפוצה ביותר של מתחילים: אנימציות ארוכות מדי. כשאתם לומדים easing ורואים bounces יפים, המפתה להשתמש ב-duration של שנייה ויותר כדי "להראות" את ה-easing. אבל בחוויית משתמש, כל מילישנייה מעל הנדרש היא מילישנייה של "המשתמש מחכה". אנימציה טובה היא כזו שהמשתמש מרגיש אבל לא מחכה לה.

אין תשובה אחת, אבל יש מדריך שעובד ב-90% מהמקרים:

קטגוריה	Duration	דוגמאות	למה
Micro	100-200ms	hover states, button clicks, tooltip appear, toggle switch	תגובה צריכה להיות מיידית — כל מה שמעל 200ms מרגיש "איטי" לתגובת משתמש
Small	200-300ms	dropdown open, fade-in of small element, tab switch	מהיר מספיק שלא מעכב, איטי מספיק שאפשר לראות את המעבר
Medium	300-500ms	modal open, sidebar slide, card expand, accordion	אלמנטים גדולים צריכים יותר זמן כדי שהתנועה תיראה טבעית
Large	500-800ms	page transition, hero animation, full-screen overlay	תנועות גדולות שמכסות הרבה שטח מסך
Dramatic	800-1200ms	onboarding animation, first-load hero, storytelling scroll	רק לרגעים מיוחדים שבהם רוצים למשוך תשומת לב

3.8 Delay — מתי שימושי ומתי מתסכל

animation-delay ו-transition-delay מוסיפים זמן המתנה לפני שהאנימציה מתחילה. Delay הוא כלי חשוב אבל מסוכן — שימוש נכון יוצר choreography אלגנטי, שימוש לא נכון גורם לאתר להרגיש שבור או איטי.

Delay שימושי ב-3 מקרים:

1. Stagger — כמו שראינו בסעיף 3.6. הפרש מדורג בין אלמנטים.
2. רצף מתוכנן — כותרת מופיעה → אחרי 200ms הטקסט → אחרי עוד 200ms הכפתור. Choreography.
3. מניעת "flicker" — tooltip שמופיע רק אחרי 300ms של hover, כדי למנוע הבהובים כשהעכבר עובר במהירות.

Delay מתסכל כש:

• כפתור שמגיב רק אחרי השהייה — המשתמש חושב שהלחיצה לא עבדה.
• אלמנט שמופיע אחרי 2 שניות בלי סיבה — הדף מרגיש שבור.
• delay על תגובת hover — "למה זה לא מגיב??"

כלל אצבע: delay על כניסה — בסדר. delay על תגובה לאינטראקציה — כמעט תמיד רע.

הנה דוגמה של שימוש נכון ב-delay ליצירת "waterfall" effect:

/* Waterfall entry — hero section */
.hero-bg     { animation: fadeIn 800ms ease-out; }
.hero-title  { animation: slideUp 500ms ease-out 200ms both; }
.hero-sub    { animation: slideUp 500ms ease-out 400ms both; }
.hero-cta    { animation: popIn 400ms cubic-bezier(0.34, 1.56, 0.64, 1) 600ms both; }

/* הפירוק:
   0ms   — רקע מתחיל fade-in (800ms)
   200ms — כותרת מתחילה slide-up (500ms) — הרקע כבר נראה
   400ms — כותרת משנה — הכותרת הראשית כבר במקום
   600ms — כפתור CTA — הכל מוכן, הכפתור "קופץ" עם overshoot

   סה"כ: 600ms + 400ms = 1000ms — הכל נגיש תוך שנייה.
   "both" = animation-fill-mode: both — שומר opacity: 0 לפני ו-opacity: 1 אחרי */

שימו לב לערך both (= animation-fill-mode: both). בלי זה, האלמנטים עם delay יהיו visible לפני שהאנימציה מתחילה — ו"ייעלמו" כשהאנימציה מתחילה. both אומר: שמור את ה-initial state (opacity: 0) לפני שהאנימציה מתחילה, ושמור את ה-final state (opacity: 1) אחרי שהיא נגמרת.

3.9 Choreography — תיאום בין אנימציות מרובות

כשיש בדף 5 אנימציות שרצות בו-זמנית, יש שני תרחישים: (1) כולן מתוזמנות ומרגישות כמו ריקוד מתואם, או (2) כל אחת רצה לבד והדף מרגיש כמו זירת קרקס. ההבדל הוא choreography — תכנון מכוון של סדר, תזמון, ויחסים בין אנימציות.

שלושה דפוסים:

1. Sequence (רצף)

אנימציה A מסתיימת → אנימציה B מתחילה → C מתחילה. כל אחת ממתינה לקודמתה. הסדר חשוב — אלמנט B מסתמך על ההקשר שאלמנט A נתן. מתאים ל: hero sections (רקע → כותרת → CTA), onboarding flows (צעד 1 → צעד 2 → צעד 3), storytelling בגלילה.

יתרון: שולט בסדר הקריאה של המשתמש — אתם מחליטים מה הוא רואה ראשון. חיסרון: הסך הכולל ארוך — אם יש 5 אלמנטים ב-sequence עם 300ms כל אחד, עוברות 1.5 שניות עד שהאחרון נראה.

2. Stagger (מדורג)

אנימציות A, B, C, D מתחילות עם הפרש קבוע (למשל 100ms). כולן רצות "כמעט ביחד" אבל לא בדיוק — כמו כרטיסי דומינו שנופלים. ההפרש הקטן יוצר תחושה של "גל" שזורם דרך הרשימה.

יתרון: מהיר (כולם נראים תוך ~700ms גם אם יש 8 אלמנטים), מרשים ויזואלית, קל לממש. חיסרון: לא שולט בסדר תשומת הלב — המשתמש רואה "קבוצה מופיעה" ולא "אלמנט X ואז Y".

3. Parallel (מקביל)

כמה אנימציות רצות בו-זמנית על אותו אלמנט. opacity משתנה מ-0 ל-1, translateY משתנה מ-30px ל-0, ו-scale משתנה מ-0.95 ל-1 — הכל בבת אחת. התוצאה: כניסה "עשירה" שמרגישה כמו דבר אחד מורכב, לא שלושה דברים נפרדים.

יתרון: מהיר (הכל קורה ב-duration אחד), מרגיש "שלם". חיסרון: אם יש יותר מדי properties שמשתנים בו-זמנית, זה יכול להרגיש "כאוטי". כלל: 2-3 properties ב-parallel מקסימום.

בפועל, רוב ה-choreographies משלבים את שלושת הדפוסים. למשל, hero section טיפוסי:

• Parallel: רקע עושה fade + scale בו-זמנית (2 properties על אלמנט 1)
• Sequence: אחרי שהרקע מוכן (200ms delay), הכותרת נכנסת
• Stagger: שני כפתורי CTA נכנסים עם 100ms הפרש ביניהם

המפתח הוא ההיררכיה: parallel בתוך אלמנטים, sequence בין קבוצות, stagger בתוך קבוצות של אלמנטים דומים.

איך בוחרים בין sequence, stagger, ו-parallel? זה תלוי במה שרוצים לתקשר:

• Sequence מתקשר סיפור — "קודם הבנת את הכותרת, עכשיו קרא את הטקסט, עכשיו לחץ על הכפתור". הוא מנחה את העין. מתאים כש-סדר הקריאה חשוב.
• Stagger מתקשר קבוצה — "כל הכרטיסים האלה שייכים ביחד, הם מסוג אחד". הוא מראה יחסים. מתאים כש-יש אלמנטים דומים.
• Parallel מתקשר שינוי מצב — "הכל משתנה בבת אחת, אנחנו עוברים למשהו חדש". מתאים כש-האלמנט עצמו מורכב (opacity + position + scale של אותו element).

הטעות הנפוצה ביותר ב-choreography: לערבב stagger עם sequence. אם כותרת נכנסת ב-sequence (אחרי הרקע) ואז הכרטיסים נכנסים ב-stagger, זה עובד. אבל אם כותרת נכנסת ב-stagger (אות אחרי אות) ואז הכרטיסים גם ב-stagger — הדף מרגיש כמו שהכל "מטפטף" בלי סוף. כלל: stagger אחד בכל viewport. אם ה-hero משתמש ב-stagger, ה-section שאחריו צריך sequence או parallel.

הנה דוגמה מלאה של choreography מתוכנן ל-landing page:

/* Landing Page Choreography Plan:
   ================================
   0ms    — Hero background: fade-in + subtle scale(1.02→1), 800ms, ease-out
   200ms  — Logo: fade-in, 300ms, ease-out
   350ms  — Headline: slide-up 20px + fade-in, 500ms, cubic-bezier(0.22, 1, 0.36, 1)
   550ms  — Subheadline: slide-up 20px + fade-in, 500ms, same easing
   750ms  — CTA buttons: fade-in + scale(0.95→1), 400ms, cubic-bezier(0.34, 1.56, 0.64, 1)

   [scroll to features section]
   0ms    — Section title: fade-in, 400ms, ease-out
   100ms  — Feature card 1: slide-up + fade, 500ms, ease-out ← stagger starts
   200ms  — Feature card 2: same
   300ms  — Feature card 3: same

   NOTES:
   - Hero uses SEQUENCE (items depend on each other)
   - Features use STAGGER (equal items in a group)
   - No two staggers visible at the same time
   - Total hero sequence: 750ms until interactive ← under 1 second
*/

3.10 Reduced Motion — כשהמשתמש מבקש פחות תנועה

חלק מהמשתמשים סובלים מרגישות לתנועה (vestibular disorders) — אנימציות עלולות לגרום להם לסחרחורת, בחילה, או כאב ראש. זה לא מקרה שולי: לפי WebAIM, כ-15-20% מהאוכלוסייה חווים רגישות כלשהי לתנועה. לכן כל דפדפן מודרני תומך ב-prefers-reduced-motion — הגדרה ברמת מערכת ההפעלה שאומרת "אני רוצה פחות תנועה".

מה זה אומר בפועל? כשמשתמש מפעיל reduced motion במכשיר שלו, ה-media query @media (prefers-reduced-motion: reduce) נהיה אמיתי, ואתם יכולים לבטל או למתן אנימציות. זו לא אופציה — זו חובה. באתר ישראלי: חוק שוויון זכויות לאנשים עם מוגבלות דורש נגישות דיגיטלית. אנימציות בלי fallback הן הפרה פוטנציאלית.

/* גישה 1: ביטול ספציפי — מומלץ */
@media (prefers-reduced-motion: reduce) {
  .card {
    animation: none;        /* ביטול כניסה מונפשת */
    transition-duration: 0.01ms; /* transitions "מיידיים" */
  }
}

/* גישה 2: ביטול גורף — לשימוש זהיר */
@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

המלצה: השתמשו בגישה 1 (ביטול ספציפי). גישה 2 (גורפת) שוברת לפעמים דברים — למשל, tooltips שמסתמכים על transition כדי לעבוד, או CSS-only hamburger menus שמשתמשים ב-transition על checkbox hack.

בכל מקרה, שלושה כללים:

1. אל תסירו את התוכן — רק את התנועה. fade-in הופך לתצוגה מיידית, slide-up הופך לתצוגה מיידית — האלמנט עדיין מופיע, רק בלי תנועה.
2. שמרו על פונקציונליות — אם accordion משתמש ב-transition כדי להיפתח, הוא עדיין צריך להיפתח — רק בלי אנימציה.
3. תבדקו! הפעילו reduced motion במחשב שלכם ושיטטו באתר. כל דבר ששבור = באג נגישות.

הנה גישה שלישית — "motion-safe" — שהופכת את הלוגיקה: במקום לבטל אנימציות ב-reduced-motion, מוסיפים אנימציות רק כש-reduced-motion לא פעיל:

/* גישה 3: motion-safe — הפוך ובטוח */
.card {
  /* ברירת מחדל: visible, no animation */
  opacity: 1;
  transform: none;
}

@media (prefers-reduced-motion: no-preference) {
  /* רק אם המשתמש לא ביקש reduced motion — הוסף אנימציה */
  .card {
    opacity: 0;
    transform: translateY(30px);
    animation: fadeUp 500ms ease-out forwards;
  }
}

/* היתרון: אם שכחתם לטפל באלמנט — הוא visible כברירת מחדל.
   בגישות 1-2, אם שכחתם — הוא invisible (opacity: 0 בלי אנימציה). */

גישה 3 היא הבטוחה ביותר כי היא fail-safe: אם שכחתם לכסות מקרה — האלמנט פשוט visible בלי אנימציה (טוב), במקום invisible בלי אנימציה (רע). שקלו לאמץ אותה כברירת מחדל.

וכשאתם מבקשים מ-AI ליצור אנימציות, תמיד הוסיפו בסוף הפרומפט:

"Use the motion-safe pattern: elements should be visible by default
 (opacity: 1, no transform). Only add animation inside
 @media (prefers-reduced-motion: no-preference). This ensures
 that if reduced-motion is on, all content is visible immediately
 without any animation."

AI ישמח לבצע את ההנחייה הזו — הוא פשוט צריך שתגידו לו. בלי ההנחייה, הוא ייצור אנימציות "רגילות" עם opacity: 0 כ-initial state, בלי reduced-motion fallback, ומשתמשים עם רגישות לתנועה יראו דף ריק. פרומפט טוב = נגישות אוטומטית.

עוד נקודה חשובה: בדיקה. הפעילו reduced motion במחשב שלכם פעם בשבוע ושיטטו באתר שלכם. כל אלמנט שנעלם, כל layout שנשבר, כל interaction שלא עובד — זה באג. טפלו בו כמו בכל באג אחר. הדרך הכי קלה: Chrome DevTools → Rendering tab → Emulate CSS media: prefers-reduced-motion: reduce. אפילו לא צריכים לשנות הגדרות במערכת ההפעלה.

3.11 כלי עזר: cubic-bezier.com, easings.net, easing.dev

כלי	מה הוא עושה	מתי להשתמש
cubic-bezier.com	עורך ויזואלי לעקומות bezier — גוררים נקודות ורואים תצוגה מקדימה בזמן אמת	כשרוצים ליצור easing מותאם אישית ולראות איך הוא מרגיש לפני שמטמיעים
easings.net	ספריית 30+ עקומות easing מוכנות — hover כדי לראות דמו, קליק להעתקת קוד	כשרוצים לבחור easing מוכן מתוך אוסף — reference מהיר
easing.dev	כלי אינטראקטיבי מתקדם עם השוואה בין עקומות ותצוגת spring	כשרוצים להשוות בין כמה אפשרויות זו-לצד-זו
Chrome DevTools → Animation	בדיקת אנימציות חיות — timeline, easing curve, duration	כשרוצים לדבג אנימציה קיימת או ללמוד מאתר אחר

3.12 פרומפטים: איך לתאר "תחושת" תנועה ל-AI

הבעיה הגדולה: כשאתם מבקשים מ-AI "add animation", הוא נותן לכם transition: all 0.3s ease — ברירת מחדל גנרית שלא מרגישה כלום. כדי לקבל אנימציה שמרגישה ספציפית, אתם צריכים שפה מדויקת.

למה? כי ל-AI אין "טעם". הוא לא יודע אם אתם רוצים אנימציה שמרגישה כמו Apple או כמו TikTok. הוא פשוט נותן את הממוצע הסטטיסטי — ו"ממוצע" באנימציה זה "גנרי". כדי לשבור את ברירת המחדל, אתם צריכים לדבר בשפה שה-AI מבין: מספרים, שמות של easing curves, durations, ו-choreography instructions.

ה-5 פרומפטים הבאים הם תבניות שאפשר להעתיק ולהתאים. כל אחד מכוון ל"תחושה" שונה:

הנה 5 פרומפטים מוכנים:

כמה עצות נוספות לנוסח פרומפטים של אנימציה ל-AI:

• תמיד ציינו duration ב-ms, לא ב-s. "300ms" ברור יותר ל-AI מ-"0.3s". גם מונע טעויות (AI לפעמים מבלבל בין 0.3s ל-3s).
• תמיד ציינו את סוג התנועה. "fade-in" ≠ "slide-up" ≠ "scale-in". אל תסתפקו ב-"animate" או "add animation" — ציינו בדיוק מה זז, מאיפה לאיפה.
• ציינו stagger כמספר. "stagger 100ms between cards" ברור יותר מ-"add staggered animation to cards".
• ציינו reduced-motion בפרומפט. AI לא מוסיף reduced-motion בברירת מחדל. הוסיפו בסוף כל פרומפט: "Include prefers-reduced-motion: reduce fallback that shows elements immediately without animation."
• ציינו את הספרייה. "CSS transition" ≠ "Framer Motion spring" ≠ "GSAP timeline". AI צריך לדעת באיזה framework לעבוד.

תבנית כללית לפרומפט אנימציה:

/* תבנית פרומפט אנימציה */
"Add [TYPE] animation to [ELEMENT].
 [ELEMENT] should [MOVEMENT] from [START] to [END].
 Duration: [X]ms.
 Easing: [cubic-bezier / spring config].
 [COORDINATION with other elements if needed].
 Include prefers-reduced-motion fallback."

/* דוגמה מלאה: */
"Add entrance animation to the feature cards grid.
 Each card should slide up 30px and fade in from opacity 0 to 1.
 Duration: 450ms per card.
 Easing: cubic-bezier(0.22, 1, 0.36, 1).
 Stagger: 100ms between cards, starting from the first card.
 Use IntersectionObserver to trigger only when cards enter viewport.
 Include prefers-reduced-motion: show cards immediately at
 opacity 1, transform none, no animation."

3.13 Easing בעולם האמיתי — ניתוח 5 אתרים

תיאוריה זה נחמד, אבל הדרך הטובה ביותר ללמוד easing היא לנתח אתרים שעשו את זה נכון. הנה 5 אתרים שכדאי לנתח, ומה תלמדו מכל אחד:

1. Stripe.com — המלך של "Smooth Professional"

Stripe משתמשים ב-easing עקבי — כמעט הכל מבוסס על Material Standard (0.4, 0, 0.2, 1) עם durations של 200-400ms. הם לא משתמשים ב-bounce או spring — הכל חלק, שקט, מקצועי. זה מתאים למוצר פיננסי שצריך לשדר "אנחנו אמינים".

מה ללמוד: עקביות ב-easing = עקביות ב-branding. Stripe לא "מפגינים" אנימציה — הם משתמשים בה כדי שהמעברים ירגישו חלקים. אם הקהל שלכם מקצועי/B2B — זו הגישה.

2. Linear.app — "Snappy" כפילוסופיה

Linear בחרו בגישה הפוכה: הכל מהיר. hover states ב-100-150ms, מודאלים ב-200ms, אף אנימציה לא נמשכת יותר מ-300ms. ה-easing תמיד aggressive — cubic-bezier שמגיעים מהר ליעד. זה משדר: "הכלי הזה מהיר כמוך".

מה ללמוד: duration קצר + easing מהיר = תחושת "responsive". אם אתם בונים כלי פרודוקטיביות — העתיקו את הגישה הזו.

3. Apple.com — Choreography מושלם

Apple היא המלכה של choreography. בdפי מוצר, כל אלמנט נכנס בתזמון מדויק — כותרת, תמונה, מפרט, כפתור — כל אחד עם delay ספציפי שיוצר רצף שמוביל את העין. ה-easing בדרך כלל ease-out עדין עם durations של 400-600ms.

מה ללמוד: Choreography נכון הופך דף סטטי לסיפור. Apple מראים שה-סדר שבו דברים מופיעים חשוב לא פחות מ-איך הם מופיעים.

4. Vercel.com — Spring ב-מידה

Vercel (יוצרי Next.js) משתמשים ב-spring animations במקומות ספציפיים — כפתורי hover עם bounce קל, מודאלים עם overshoot עדין. אבל הם לא מגזימים — רוב המעברים הם CSS transitions רגילים. Spring שמור ל"רגעים" מיוחדים.

מה ללמוד: Spring הוא תבלין, לא מנה עיקרית. השתמשו בו נקודתית כדי לסמן אלמנטים חשובים — כפתור CTA, notification, hover state מיוחד.

5. Framer.com — "Everything Moves"

Framer (יוצרי Framer Motion) הם showcase של מה שאפשר לעשות עם spring physics. כל דבר באתר שלהם זז — לא רק כניסות, אלא גם תגובות לעכבר, scroll effects, ומעברי דף. ה-springs מכוילים בקפידה: stiffness ו-damping ספציפיים לכל סוג אינטראקציה.

מה ללמוד: אם אתם בונים אתר creative/portfolio — זו ההשראה. אבל אזהרה: מה שעובד ל-Framer (שהקהל שלהם הוא מעצבים שאוהבים אנימציה) לא בהכרח עובד לאתר e-commerce ישראלי.

מה משותף לכולם?

כשאתם מנתחים את חמשת האתרים האלה, תשימו לב ל-4 דפוסים שחוזרים:

1. עקביות פנימית. כל אתר בוחר "פלטת easing" — בדיוק כמו פלטת צבעים. Stripe = smooth בלבד. Linear = snappy בלבד. לא מערבבים בין סגנונות. אתר שמשתמש ב-bounce על הכפתורים ו-smooth על המודאלים מרגיש "שבור" — כמו אתר שמשתמש ב-10 פונטים שונים.
2. Duration hierarchy. micro-interactions (hover, click) תמיד קצרים (100-200ms). macro-animations (page load, section reveal) תמיד ארוכים יותר (400-800ms). אף אתר מקצועי לא הופך את ה-hierarchy הזה — כפתור שנע ב-800ms מרגיש שבור, hero שנכנס ב-100ms מרגיש מבולבל.
3. Easing מתאים לתוכן. אתר פיננסי (Stripe) = smooth ושמרני. כלי פרודוקטיביות (Linear) = snappy ומהיר. אתר שיווקי (Apple) = דרמטי עם choreography. ה-easing משרת את ה-brand, לא להיפך.
4. Reduced motion תמיד נתמך. כל חמשת האתרים — בלי יוצא מהכלל — יש להם prefers-reduced-motion support. זה לא צירוף מקרים. אתרים מקצועיים מתייחסים לנגישות כחלק מהאיכות, לא כ-afterthought.

כשאתם בונים את הפרויקט שלכם, שאלו: "מה ה-Stripe/Linear/Apple של ה-niche שלי?" ולכו לנתח את ה-easing שלהם. ה-DevTools Animation panel הוא החבר הכי טוב שלכם — הוא מראה easing curves, durations, ו-delays של כל אנימציה חיה. זו הדרך הכי מהירה ללמוד easing מקצועי — reverse engineering של אתרים שעובדים.