במאמר על מיקרו-אינטראקציות כתבתי ש-transform ו-opacity מונפשים בתהליך הקומפוזיטור, כך שאפילו עמוד כבד לא אמור לגמגם באנימציית כפתור. זה עדיין נכון – עם הסתייגות אחת שהמאמר ההוא שתק לגביה: אם התהליך הראשי חסום על ידי משימת JS ארוכה, האנימציה עלולה לעולם לא לקבל הזדמנות להתחיל, כי ה-handler של הלחיצה עצמו ממתין בתור. INP היא המדד שמודד בדיוק את הפער הזה – ו-scheduler.yield() היא אחת הדרכים המעטות לסגור אותו באמת.
רשימה של אלף תגובות מתרנדרת לאט, אז אתם פונים ל-react-window – ובתמורה לגלילה חלקה מאבדים את Ctrl+F, הדפסת העמוד וחלק מהניווט של קורא מסך, כי אלמנטים מחוץ לחלון מפסיקים להתקיים פיזית ב-DOM. content-visibility פותר את אותה בעיה אחרת: האלמנטים נשארים ב-DOM, הדפדפן פשוט מדלג עבורם על העבודה היקרה של layout וציור, עד שהם מגיעים קרוב לאזור הנראה – ובאופן מפתיע, יודע לחשוף אותם זמנית כשמחפשים בהם טקסט.
במאמר על נגישות היה מודל עם display:none שבכל זאת המשיך להתקיים בעץ הנגישות – דוגמה לשגיאה שנובעת מבניית מודל מאפס על divים. השאלה האמיתית היא: למה בכלל היה צריך לבנות אותו מאפס? בודק מה מקבלים בחינם מ-<dialog> הטבעי ומהתכונה popover – top layer, מלכודת פוקוס, light dismiss – ואיפה שני המנגנונים האלה שונים מספיק כדי שבלבול ביניהם יוביל ישר לממשק לא נגיש.
כפתור "לייק" מגיב מיד, הלב מתמלא, המונה עולה – עוד לפני שהשרת בכלל ענה. זו לא אשליית מהירות כמו במאמר על מיקרו-אינטראקציות, זה משהו רחוק יותר: הממשק מציג מצב שעדיין לא קיים, ומניח שהוא עומד להתקיים בעוד רגע. בודק איך בונים את זה בבטחה – עם נסיגה אמיתית מהשקר כשההנחה לא מתממשת, ולמה setState ידני עם catch הוא גרסה גרועה יותר של מה ש-useOptimistic נותן בחינם.
מחלקת עזר .mt-4 מפסידה לכלל .card .card__header .card__title, למרות שהיא לכאורה אמורה לנצח, כי היא נוספה מאוחר יותר. זו לא תקלה – זו ספציפיות שעושה בדיוק את מה שהיא תוכננה לעשות. @layer מציג ציר חלוקה חדש לגמרי להכרעת קונפליקטים, שפועל לפני הספציפיות, לא ביחד איתה – ויש לו מלכודת אחת לא אינטואיטיבית עד כדי כך, שאפילו חלק מהתיעוד ברשת טועה בה.
'use server' נראה כמו סוכר תחבירי מעל fetch ל-API route – ובדיוק בגלל זה רוב היישומים מתייחסים אליו כאל קריאת פונקציה רגילה. זו טעות עם השלכות קונקרטיות: כל פונקציה שמסומנת ב-'use server' הופכת לנקודת קצה ציבורית ברשת, וטופס שנבנה על המנגנון הזה עובד אפילו לפני שה-JavaScript מספיק להיטען. בודק מה באמת קורה מתחת להוראה הזו, והיכן טמונות המלכודות שלא נראות בתיעוד ממבט ראשון.
שדה בטופס אמור להאיר באדום כשה-input בפנים לא תקין. דבר פשוט – רק ש-CSS במשך 25 שנה לא ידע לשאול אלמנט מה קורה בתוכו, רק ההפך. בודק איך :has() הופך את הכיוון הזה, במה הוא שונה מקומבינטורים רגילים, והיכן העוצמה החדשה הזו באמת עולה במחיר של ביצועים.
אותה כרטיסיית מוצר נראית מצוין ברשת אבל נשברת בסרגל צד צר – למרות media query שנבחר בקפידה. הבעיה לא בקוד שלכם, אלא בשאלה שה-media query בכלל שואל: על רוחב המסך, לא על המקום שהרכיב באמת קיבל. בודק איך container queries מעבירים את השאלה הזו למקום שבו היא הייתה צריכה להישאל מלכתחילה, ומה קורה מתחת למכסה המנוע כשאלמנט הופך ל'מיכל שאילתה'.
HTML תקין הוא רק נקודת ההתחלה. גלו איך עץ הנגישות עובד בפועל, מדוע ARIA לעיתים קרובות עושה יותר נזק מתועלת ממה שנדמה, ובנו איתי אקורדיון אמיתי, אזור חי (live region) וניהול פוקוס ב-Next.js.
שתי חנויות, אותו מוצר, אותו זמן תגובה מהשרת – ובכל זאת אחת מהן מרגישה מהירה ואמינה יותר. ההבדל טמון במיקרו-אינטראקציות: כמה מאות מילישניות של אנימציה שמכריעות אם המשתמש בכלל סומך על מה שהוא רואה על המסך. אני מפרק אותן מהיסוד – מודל הטריגר/משוב, מה שבאמת קורה בתוך מנוע הרינדור של הדפדפן, ו-prefers-reduced-motion.
CSS Houdini הוא לא טכנולוגיה אחת, אלא אוסף מפרטים במצבי בשלות שונים מאוד. גלה איזה חלק ממנו מתאים היום לסביבת ייצור, איך `@property` ו-paint worklet באמת עובדים, ולמה שאר החלקים עדיין בגדר ניסוי.
