פריסה של LayoutNG, שמתוכננת לצאת ב-Chrome בגרסה 76, היא מנוע פריסה חדש שיוצא ממאמץ רב-שנתי. יש מספר שיפורים מיידיים ומרגשים, ובקרוב נוסיף שיפורים בביצועים ותכונות פריסה מתקדמות.
מה חדש?
- שיפור בידוד הביצועים.
- תמיכה טובה יותר לסקריפטים שאינם לטיניים.
- תיקון בעיות רבות בנושא צפים ושוליים.
- מתקן מספר גדול של בעיות תאימות באינטרנט.
לתשומת ליבכם, LayoutNG תושק בשלבים. ב-Chrome בגרסה 76, נעשה שימוש ב-LayoutNG לפריסה מוטבעת ולפריסה של בלוקים. פרימיטיבים אחרים של הפריסה (כמו טבלה, flexbox, רשת ופרגמנטציה של בלוקים) יוחלפו בגרסאות הבאות.
שינויים גלויים למפתחים
ההשפעה הגלויה על המשתמש צריכה להיות מינימלית, אבל LayoutNG משנה התנהגות מסוימת בדרכים עדינות, מתקנת מאות בדיקות ומשפרת את התאימות עם דפדפנים אחרים. למרות מאמצינו, סביר להניח שהדבר יגרום לאתרים ולאפליקציות מסוימים להציג או להתנהג באופן מעט שונה.
גם מאפייני הביצועים שונים למדי. על אף שהביצועים באופן כללי דומים או מעט טובים יותר מבעבר, בתרחישים מסוימים של שימושים צפוי שיפור בביצועים, בעוד שבתרחישים אחרים צפוי שיפור מסוים, לפחות לטווח קצר.
צף
LayoutNG מטמיעה מחדש תמיכה באלמנטים צפים (float: left; ו-float: right;) ומתקנת מספר בעיות תקינות בנוגע למיקום של הצפות ביחס לתוכן אחר.
תוכן שכבת-על
בהטמעת התוכן הצף מדור קודם, לא נלקחו בחשבון שולי רווח כאשר הצבתם תוכן מסביב לאלמנט צף, וכתוצאה מכך התוכן חופף באופן חלקי או מלא את ה-float עצמו. הביטוי הנפוץ ביותר של הבאג הזה מופיע כאשר תמונה ממוקמת לצד פסקה, כאשר לוגיקת ההימנעות לא מביאה בחשבון את גובה השורה. (פרטים נוספים זמינים במאמר באג מס' 861540 ב-Chromium.)
הטקסט חופף לתמונה הצפה מימין
הטקסט מופיע ליד התמונה הצפה מימין
אותה בעיה עשויה להתרחש בשורה אחת. בדוגמה הבאה מוצג רכיב בלוק עם שוליים שליליים אחרי רכיב צף (#895962). הטקסט לא יכול לחפוף לצף.
הטקסט חופף לאלמנט הכתום הצף
הטקסט ממוקם לצד האלמנט הכתום הצף
עיצוב מיקום ההקשר
כשגודל של רכיב שיוצר הקשר של עיצוב בלוקים נקבע ליד נתונים צפים, מנוע הפריסה מהדור הקודם ינסה להגדיל את הבלוק מספר קבוע של פעמים לפני שיוותר עליו. הגישה הזו הובילה להתנהגות לא צפויה ובלתי יציבה, ולא תאמה להטמעות אחרות. ב-LayoutNG, כל הצפים נלקחים בחשבון כשמשנים את גודל הבלוק. (פרטים נוספים זמינים במאמר באג מס' 548033 ב-Chromium.)
עכשיו מיקומים מוחלטים וקבועים תואמים יותר למפרטי W3C, ומתאימים יותר להתנהגות בדפדפנים אחרים. ההבדלים בין שני המצבים בולטים ביותר בשני מקרים:
- שורות מרובות קווים המכילים בלוקים
אם בלוק מכיל שנמצא במיקום מוחלט מתפרס על מספר קווים, המנוע מהדור הקודם עשוי להשתמש באופן שגוי רק בקבוצת משנה של הקווים כדי לחשב את גבולות הבלוקים שמכילים. - מצבי כתיבה אנכית
במנוע מהדור הקודם היו הרבה בעיות בהצבת אלמנטים מחוץ לתהליך במיקום ברירת המחדל במצבי כתיבה אנכיים. בקטע הבא תוכלו למצוא פרטים נוספים על תמיכה משופרת במצב כתיבה.
שפות מימין לשמאל (RTL) ומצבי כתיבה אנכיים
תוכנת LayoutNG תכננה מההתחלה לתמוך במצבי כתיבה אנכיים ובשפות RTL, כולל תוכן דו-כיווני.
טקסט דו-כיווני
ב-LayoutNG יש תמיכה באלגוריתם דו-כיווני העדכני ביותר שהוגדר על ידי תקן Unicode. העדכון מתקן שגיאות רינדור שונות, אלא גם כולל תכונות חסרות כמו תמיכה בסוגריים תואמים (מידע נוסף זמין במאמר באג #302469 ב-Chromium).
זרימה אורתוגונלית
פריסת פריסה אנכית משפרת את הדיוק של פריסת הזרימה האנכית, כולל, לדוגמה, מיקום של אובייקטים במיקום מוחלט ושינוי גודל של תיבות זרימה אורתוגונליות (במיוחד כשמשתמשים באחוזים). מתוך 1,258 הבדיקות בחבילות הבדיקה של W3C, 103 בדיקות שנכשלו במעבר הקודם של מנוע הפריסה ב-LayoutNG.
מידה פנימית
גדלים מהותיים מחושבים עכשיו נכון כשבלוק מכיל ילדים במצב כתיבה אורתוגונלי.
פריסת טקסט ושבירת שורות
מנוע הפריסה מדור קודם של Chromium איבר את הטקסט בכל אלמנט, שורה אחרי שורה. הגישה הזו התאימה ברוב המקרים, אבל דרשה הרבה מורכבות נוספת כדי לתמוך בסקריפטים ולהשיג ביצועים טובים. היא גם גרמה לחוסר עקביות במדידה, שגרם להבדלים קלים בגודל של קונטיינרים של גודל לתוכן ובתוכן שלהם, או במעברי שורה מיותרים.
ב-LayoutNG, הטקסט מעוצב ברמת הפסקה ולאחר מכן מחולק לשורות. הדבר מאפשר ביצועים טובים יותר, עיבוד טקסט באיכות גבוהה יותר ומעבר שורה עקבי יותר. ההבדלים העיקריים ביותר מפורטים בהמשך.
איחוד בין גבולות הרכיב
בסקריפטים מסוימים ניתן לצרף תווים מסוימים כאשר הם סמוכים זה לזה. הנה דוגמה בערבית:
ב-LayoutNG, אפשר עכשיו להצטרף גם אם הדמויות נמצאות באלמנטים שונים. ההצטרפות גם תישמר אם בחרת סגנון שונה. (פרטים נוספים זמינים במאמר באג מס' 6122 ב-Chromium.)
גרף הוא היחידה הקטנה ביותר במערכת הכתיבה של שפה. לדוגמה, באנגלית ובשפות אחרות שמשתמשות באלפבית הלטיני, כל אות היא גרפמה.
בתמונות הבאות מוצג הרינדור של ה-HTML הבא במנוע הפריסה הקודם וב-LayoutNG, בהתאמה:
<div>نسق</div>
<div>نس<span>ق</span></div>
שימו לב איך האות השנייה משתנה
שתי הגרסאות זהות עכשיו
ליגטורות סיניות, יפנית וקוריאנית (CJK)
על אף ש-Chromium כבר תומך בליגטורות ומאפשר אותן כברירת מחדל, יש מספר מגבלות: ליגטורות שכוללות מספר נקודות קוד של CJK לא נתמכות במנוע הפריסה הקודם בגלל אופטימיזציה של העיבוד. LayoutNG מסירה את ההגבלות האלה ותומכת בליגטורות ללא קשר לסקריפט.
הדוגמה הבאה מציגה את העיבוד של שלוש ליגטורות לפי שיקול דעת באמצעות הגופן Adobe SourceHanSansJP:
מגה-הרץ יוצר ליגטורה
אבל マ וחשבוןתיקיות 10点 לא
כל שלוש הקבוצות יוצרות ליגטורות כמצופה
רכיבי גודל לתוכן
לרכיבים שגודלם תואם לערך של התוכן (כמו בלוקים מוטבעים), מנוע הפריסה הנוכחי מחשב קודם את גודל הבלוק ולאחר מכן מבצע פריסה בתוכן. במקרים מסוימים, למשל כשהגופנים מכווצים באופן אגרסיבי, הדבר עלול לגרום לחוסר התאמה בין גודל התוכן לבין הבלוק. ב-LayoutNG, מצב הכשל הזה בוטל כי גודל הבלוק מבוסס על התוכן עצמו.
בדוגמה הבאה מוצג בלוק צהוב בגודל שמתאים לתוכן. היא משתמשת בגופן Lato המשתמש בצמצום כדי להתאים את הריווח בין T ל- -. הגבולות של התיבה הצהובה צריכים להתאים לגבולות הטקסט.
שימו לב לרווח הלבן שבסופו אחרי ה-T האחרון
חשוב לשים לב שהקצה השמאלי והימני של התיבה תואמים לגבולות הטקסט
גלישת שורות
בדומה לבעיה שמתוארת למעלה, אם התוכן של בלוק מסוג 'גודל לתוכן' גדול (רחב יותר) מהבלוק, לפעמים הוא עלול להתגלות שלא לצורך. זה מצב נדיר למדי, אבל לפעמים קורה כשמדובר בתוכן בעל כיווניות מעורבת.
שימו לב למעבר השורה המיותר ולרווח נוסף בצד ימין
חשוב לשים לב שהקצה השמאלי והימני של התיבה תואמים לגבולות הטקסט
מידע נוסף
למידע מפורט יותר על בעיות התאימות הספציפיות ועל הבאגים שתוקנו על ידי LayoutNG, אפשר לעיין בבעיות המקושרות למעלה או לחפש באגים במסד הנתונים של Chromium ולחפש באגים עם הסימון Fixed-In-LayoutNG.
אם אתם חושדים ש-LayoutNG גרמה לקריסה של אתר, תוכלו לדווח על באג, ואנחנו נבדוק את הנושא.