קו יישור אחד לכל האתר

בתיקון האחרון של הפורטפוליו שלי חזרתי לשאלה שנראית קטנה: איפה התוכן מתחיל ונגמר בכל עמוד?

בקוד היו כמה תשובות. דף הבית השתמש ברוחב מרבי של 1480 פיקסלים. אזור הפרויקטים הגדיר 1380 פיקסלים עם חישוב שוליים משלו. לבלוג הייתה מעטפת של `76rem`, ולכתבה בודדת הגדרה נוספת של `72rem`. כל כלל היה סביר בפני עצמו, אבל יחד הם יצרו כמה מערכות יישור בתוך אותו אתר.

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

האבחון: הרוחב הוא רק חלק מהגאומטריה

קל לחפש `max-width` ולהחליף מספר. אלא שקו היישור נקבע גם על ידי הריווח הפנימי, המעטפת ההורית וכללים שמופעלים רק במובייל.

בבלוג, למשל, היה ריווח אופקי על העמוד עצמו ורוחב נפרד על המעטפת שבתוכו. בפרויקטים, השוליים חושבו באמצעות הפחתה מתוך הרוחב, עם ערך אחר במסך קטן. בדף הבית כבר היו משתנים משותפים, אבל הם נשאו שמות מקומיים לעמוד הבית.

לכן לא הסתפקתי במספר אחד חדש. היה צריך לקבוע מי אחראי לרוחב החיצוני, מי לשוליים הפנימיים, ואילו כללים ישנים צריכים לרדת כדי שלא יתחרו בהם.

התיקון: מעטפת משותפת עם אחריות מוגדרת

הוספתי שני משתנים ומחלקה משותפת:

:root {
  --content-container-max: 92.5rem;
  --content-container-gutter: clamp(1.25rem, 3.4vw, 3rem);
}

.content-container {
  box-sizing: border-box;
  width: min(100%, var(--content-container-max));
  margin-inline: auto;
  padding-inline: var(--content-container-gutter);
}

הערכים האלה הם בחירה לפורטפוליו הזה, לא נוסחה לכל אתר. המשמעות החשובה היא חלוקת האחריות: המעטפת מגדירה את הרוחב, ממרכזת את עצמה ומחזיקה את השוליים הפנימיים. `border-box` כולל את הריווח בתוך הרוחב שהוגדר.

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

יישור משותף אינו רוחב קריאה אחיד

כתבה, כרטיס פרויקט וטופס אינם צריכים אותה פריסה פנימית. המעטפת המשותפת מגדירה את המסגרת החיצונית; בתוכה אפשר לשמור על עמודת קריאה, חלוקה לטורים או מגבלת רוחב לכותרת.

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

לבדוק את הקצוות שהדפדפן מצייר

לצד השינוי נוספה בדיקת דפדפן שמודדת את המעטפות הנראות בפועל. היא קוראת `getBoundingClientRect()` ואת ה־padding המחושב, במקום להסתפק בשאלה אם מחלקת CSS נמצאת ב־DOM.

ב־viewport של 1680 פיקסלים הבדיקה מצפה למעטפת ברוחב 1480, למרחק חיצוני של 100 פיקסלים מכל צד ולריווח פנימי מעוגל של 48. ב־390 פיקסלים היא מצפה למעטפת ברוחב המסך ולריווח פנימי מעוגל של 20.

המסלול עובר על תשעה נתיבים, בעברית ובאנגלית, ובודק גם שאין גלילה אופקית. אנגלית נבדקת בבהיר ועברית בכהה. זו בדיקה ממוקדת של הגאומטריה במסכים שנבחרו; היא אינה מכסה כל רוחב, שילוב שפה וערכת נושא, או מחליפה קריאה חזותית של העמוד.

מה אקח לשינוי הבא

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

מעטפת משותפת מועילה כשהכללים שסביבה מפסיקים להתחרות בה. המדידה בדפדפן סוגרת את המעגל: היא מאפשרת לבדוק אם הכוונה שב־CSS הפכה לאותם גבולות גם בתוצאה שהמשתמש רואה.