אנחנו שמחים להציג את המהדורה השנייה של Chrome Dev Insider, שבה אנחנו משתפים עדכונים לגבי מה חדש ומעניין בקהילה, כאן ב-Chrome. זהו פרק חדש של סיפורים פנימיים על הגישה שלנו לעבודה שלנו, ומבט מהיר על כמה מהעדכונים החשובים ביותר שכדאי לשים לב אליהם.
אני רייצ'ל אנדרו, מנהלת התוכן של web.dev ו-developer.chrome.com, כחלק מצוות קשרי המפתחים של Chrome. אני עובדת באינטרנט כבר יותר מ-20 שנה, מתמקדת בתקני אינטרנט פתוחים וב-CSS, ואני חברה בקבוצת העבודה של שירותי CSS.
לפני חודשיים סגרנו את Google I/O שבו סיפרנו כמה מהעדכונים החשובים ביותר לגבי האופן שבו אנחנו תומכים במפתחים כדי להפוך את האינטרנט למהיר וחזק יותר, תוך שמירה על הבטיחות והפרטיות של נתוני המשתמשים.
אחד הדברים שהכי בלטו (ואנחנו שמחים שהקהילה שמה לב לכך!) הוא העבודה העצומה שהצוות משקיעים כדי לתמוך ביותר תכונות של שירותי CSS וממשק משתמש באינטרנט. במהדורה הזו של Chrome Dev Insider, ניקח אתכם אל מאחורי הקלעים של הפעילויות האלה, ונסביר איך אנחנו פועלים לתמיכה בפיתוח של שירותי CSS ומפתחים של ממשק המשתמש, ומה צפוי בהמשך. לכן אני שמחה לארח את המהדורה הזו של הניוזלטר.
בחדשות
ב-Chrome Dev Insider הראשון, שיתפנו כמה עדכונים לגבי יוזמות של תאימות ל-2021 ו-Interop 2022, שבהן ספקי דפדפנים ושחקנים בסביבה העסקית פועלים בשיתוף פעולה כדי להוסיף לאינטרנט עוד תכונות שנתמכות בכל הדפדפנים. היוזמה שלנו מתמקדת בעיקר ב-CSS כי חוסר תאימות של דפדפנים הוא אחד מהאתגרים הגדולים ביותר למפתחים של שירותי CSS.
אמנם זו לא בהכרח חדשות, אבל זה יהיה מרגש לראות את ההתקדמות שלנו כבר עכשיו בדפדפנים שונים.
בתחילת החודש שעבר, ראינו ב-Safari הכרזה על השקת באמפר עם Safari 16.0 בטא, שכולל תכונות מלהיבות כמו Container שאילתות, subgrid ובודק Flexbox. הגרסאות האחרונות של Firefox ו-Chrome כללו כמה תכונות ותיקונים מרגשים – אני סוקרת את הנושאים העיקריים בדפדפנים יציבים וגרסת בטא בכל חודש, בסדרת הפוסטים החדשה לפלטפורמת האינטרנט.
מידע פנימי: תמיכה במפתחים של שירותי CSS וממשק משתמש
שנת 2022 הייתה שנה מלהיבה לשימוש בתכונות של שירותי CSS, וחשבנו שהגיע הזמן לקחת אתכם אל מאחורי הקלעים. ישתי עם
קדימה, נתחיל. נשמח לשמוע קצת יותר על עצמך?
ניקול: אני מנהלת המוצר של ממשק המשתמש באינטרנט ב-Chrome. אני מתמקדת במיוחד בממשקי API חדשים של CSS וב-HTML, ובמפתחים ובמעצבים שבונים ממשקי משתמש. זהו מרחב מרגש עם כמה ממשקי API חשובים מאוד כמו שאילתות קונטיינרים, היקף, וקצב אנכי (תקווה!).
יונית: אני מנהלת את צוותי ממשק המשתמש באינטרנט וצוותי DevRel של כלי הפיתוח. אנחנו מתמקדים בתמיכה במהנדסי ממשק משתמש בפלטפורמת האינטרנט ומוודאים שיש להם את הכלים הדרושים להם כדי להצליח. ההרשאה כוללת ממשקי API של CSS ורכיבי HTML וגם תכונות של כלי פיתוח שמאפשרות לראות משוב פעיל ושינויים פעילים.
התמיכה של Chrome למפתחים של ממשק משתמש התגברה בשנים האחרונות. למה לדעתך לקח כל כך הרבה זמן להגיע לכאן? מה היו האתגרים הגדולים ביותר?
יונית: היינו צריכים לעשות קצת עבודה כדי להסביר עד כמה העבודה הזו חשובה ולמה היא צריכה להיות בעדיפות גבוהה. התחלנו עם סקר ה-MDN DNA בשנת 2019, שזיהה את ממשק המשתמש כאחת מהבעיות הנפוצות ביותר בפלטפורמה. ומאז המשכנו להשתמש בנתונים כמדריך ב-MDN ובסקרי שביעות הרצון הפנימיים של המפתחים. התוצאה היא שהצלחנו להשיג מעורבות עמוקה יותר בארגון ההנהלה והצלחנו לתעדף את העבודה ההנדסית תוך התייחסות לכמה מהתכונות המבוקשות ביותר למפתחים בממשק המשתמש. בנוסף, אנחנו מתמקדים בעיקר ביוזמות כמו Compat 2021 ו-Interop 2022.
Nicole: בנוסף לכך שהתחלנו להשתמש במנהיגות, היינו צריכים למצוא גם את הדרך הנכונה להביא את ממשקי ה-API האלה למפתחים. כשהצטרפתי ל-Chrome בפעם הראשונה, גיליתי את הטעות בפרויקט בשם Layered APIs (או בקיצור LAPIs). ממשקי LAPI נועדו להעניק למפתחים חוויה של רכיבים משולבים. אני עדיין חושב שזו הייתה תוצאה נהדרת, אבל עשינו הרבה טעויות! התמקדנו קודם בהתראות של הודעות חסומות וברשימה וירטואלית. כמעט בלתי אפשרי להפוך את פתיחת טוסטר לגלויה, ורשימה וירטואלית היא אחד המרכיבים שקשה ביותר לספק בצורה נכונה. הכוונות שלנו היו טובות אבל לא עזרו למפתחים, ולכן סגרנו את הפרויקט. קשה ללמוד את הדרך הקשה, אבל כל טעות מעודדת את החידושים בתחום ה-CSS וה-HTML שמתרחשים עכשיו.
בואו נדבר קצת יותר על LAPIs. מה קרה שם?
Nicole: לגבי ממשקי LAPI, ידענו שהאינטרנט זקוק לחוויית מפתח של רכיבים שקרובה יותר לפיתוח ממשק משתמש מקורי. היה ברור שהמציאה מחדש של הגלגל מעכבת את המפתחים. אני לא יכולה לספור את מספר הכרטיסיות שיצרתי בקריירה שלי! עם זאת, ניסינו לפתור את הבעיה על ידי שליחת JavaScript באמצעות הדפדפן, כך שהייתה קשה מאוד. אף אחד לא שלח JavaScript בדפדפן לפני כן, ולא היה ברור איך הוא צריך לקיים אינטראקציה עם קוד C++ שמפעיל את מנוע העיבוד של הדפדפן. הקשבנו לספקי דפדפנים אחרים (תודה, Mozilla!) וגזרנו מהגישה הזו ולכן הצלחנו למצוא משהו הרבה יותר טוב עם Open UI. הודות ל-HTML ול-CSS, אנחנו מציעים פתרונות גמישים והצהרתיים. מכיוון שהוא מבוסס על הצהרתיות, אנחנו יכולים לשפר את הנגישות בדרך שלא הייתה קלה לביצוע עם JavaScript. אני ממש מתרגשת לקראת המקום הזה. אנחנו פועלים כדי לתמוך בתמיכה בתפריטים, בחלונות קופצים, בהסבר קצר, בניווט, באקורדיון, בכרטיסיות, בקרוסלה ומתגים, שהם דפוסים חיוניים בעיצוב של ממשק המשתמש.
אז למדנו המון. ידוע לי שהיו יוזמות נוספות בתחום הזה, כמו CSS Houdini. מה הסיפור?
יונית: כן, CSS Houdini, הוא מקום נוסף שבו למדנו מהקהילה. יש המון תכונות Houdini שימושיות, אבל רבות מהן היו ברמה נמוכה מדי מכדי לקבל אימוץ נרחב יותר ותמיכה נרחבות יותר. הבנו שהטמעה של ממשקי API ברמה נמוכה לא בהכרח מצמצמת את הקושי של המפתחים. במקום זאת, התמקדות בפתרונות ובצרכים ברמה גבוהה יותר עזרה להשיג תמיכה בדפדפנים שונים ואת הבסיסים הדרושים להעברת מחט בסביבה העסקית. אנחנו עוקבים כרגע אחרי ההתקדמות בכתובת https://ishoudinireadyyet.com/.
למרות התמיכה בדפדפנים שונים, נראה שיוזמות כמו Interop 2022 ו-Open UI מספקות תוצאות חיוביות משמעותיות לקהילה. מה אתם שומעים מהמפתחים?
יונית: אחת הבעיות העיקריות שאנחנו שומעים ממפתחים היא "לעבוד על העיצוב באופן זהה בדפדפנים שונים". טיפלנו בבעיה הזו באמצעות שיתוף פעולה עם ספקי דפדפנים אחרים כדי לתעדף ולהציג חלק מהתכונות המבוקשות ביותר למפתחים. המשוב שקיבלנו מהקהילה היה חיובי ביותר. בנוסף, כתוצאה ממאמץ נרחב של ארכיטקטורה מחדש שנקרא RenderingNG, אפשר להפוך חלק מהתכונות האלה לביצועים הרבה יותר טובים. המפתחים מתרגשים שהתכונות שלהם, שכולם מצפים להן במשך שנים רבים, עובדו סוף סוף ומגיעים לדפדפנים שונים.
ניקול: אפשר להבחין בהתרגשות בקהילה. אפשר לראות אותו ב-Twitter. :)
העבודה עם הסביבה העסקית הוכחה כקריטית לכל הצלחה שהשגנו למפתחים לחיים קלים יותר. אני יודע שהצוות שלך השקיע בו הרבה עבודה. רוצה לשתף כמה פרטים?
ניקול: קודם כל, אני כל הזמן נרגשת מהפרויקטים שמפתחים יוצרים באינטרנט. המפתחים בונים דברים מדהימים, מהספרייה הקטנה ביותר ועד למסגרות מלאות ב-frameworks. זוהי קהילה מדהימה של יוצרים. ו-Chrome מבצע עוד כמה פעולות כדי לשפר את החיבור לפרויקטים האלה.
לדוגמה, לפני כמה שנים התחלנו לעבוד עם מסגרות JavaScript כמו React ו-Agular. ו-metaframeworks - לדוגמה, Next, Nuxt ו-Gatsby. בשנה שעברה, התחלנו לעשות את זה גם עם כלים ו-frameworks של ממשק משתמש כמו Sass , Bootstrap ו-Material. אני מקווה שבשנה הקרובה נוכל לשתף פעולה עם GreenSock ועם כלים אחרים שמפתחים לחיים קלים יותר. ראיתי את קייסי אוונס מ-GreenSock מדברת ב-Smashing Conference והתרגשתי מאוד לעבוד עם אנשים בעולם האנימציה.
אז איפה אנחנו רואים את ההזדמנות הכי גדולה לסביבה העסקית של ממשק המשתמש באינטרנט?
יונית: מבחינת הזדמנויות גדולות, לדעתי אנחנו ממש רוצים לעשות עוד מאמץ כדי להתאים אישית את חוויות השימוש באינטרנט. ממשקי API חדשים כמו שאילתות קונטיינרים ותכונות המדיה של העדפות המשתמש ב-CSS מגדירים מחדש את הדרך שבה מפתחים צופים בעיצוב רספונסיבי. אני גם שמחה לקבל את חוויות העיצוב המשותפות שמאפשרות למפתחים ולמעצבים לעבוד יחד עם המשתמשים שמבקרים באתרים שלהם.
וניקול, מה צפוי בהמשך בתוכנית של הצוות שלך?
ניקול: לא כל הניתוחים הופכים לדברים שניתן לשלוח, אבל יש הרבה דברים שמרגשים אותי כרגע:
הדבר הראשון שצריך לעשות הוא להפעיל עיצוב רספונסיבי ומבוסס-רכיבים. היא כוללת כלים לעיצוב מערכות צבע כדי שהמעצבים יוכלו להגיב להעדפות של המשתמשים כמו מצב כהה. לדוגמה, אם מרחב הצבעים OKLCH, הבהירות נשמרת באופן עקבי בכל גוונים. המעצבים יכולים לעבור מבחירת צבעים לעיצוב יחסים בין צבעים, בלי לסיים את העיצוב שלהם בלוחות צבעים עזים.
אנחנו גם עובדים על כמה מממשקי ה-API המבוקשים ביותר, כמו שאילתות קונטיינר, שכבות מדורגות, בורר הורה (:has), סגנונות של היקף הרשאות והצבת היררכיה. המפתחים צריכים את הכלים האלה כדי לפתח מערכות עיצוב גמישות שמלאות ברכיבים לשימוש חוזר.
גלילה בין האנימציות המקושרות היא עוד אזור כיף. אני ממש אוהב את ההדגמה של סטיב גארדנר. הוא משתמש בגלילה חלקה ובאנימציות מגניבות של מטוס מופעלות בזמן הגלילה. אמנם הן כיפיות, אבל לפעמים קשה להבין את כולן, במיוחד כשמביאים בחשבון את הנגישות. לכן אנחנו מריצים עכשיו בדיקות משתמשים כדי לבדוק את הנגישות בתכונה.
הדבר שהכי מעניין אותי הוא הפקדים המובנים בממשק המשתמש באינטרנט. המפתחים ממשיכים ליצור את אותה קבוצת כרטיסיות שוב ושוב, לדעתי הדפדפן יכול לעזור. בקטע Open UI אנחנו עובדים על רכיבים כמו בחירת תפריט, חלון קופץ, הסבר קצר, כרטיסיות, ניווט, אקורדיון והחלפת מצב. אנחנו בודקים איך ייראה רכיב הנגישות לרכיבי הדפדפן האלה כדי שהאינטרנט יהיה נגיש כברירת מחדל עם הזמן. לאחר מכן המפתחים יכולים להתמקד בבעיות מורכבות ומניואנסות יותר, בעוד שהדפדפנים יכולים לתמוך ביסודות, כמו הכרטיסייה 'איך עושים את זה'. כנראה שיש צורך בפוסט נפרד, אז אפסיק שם בינתיים!
לבסוף, נמשיך להשקיע בפעולות הדדיות בין דפדפנים. נהניתי לעבוד עם האנשים ב-WebKit וב-Gecko כדי ליצור עקביות בחוויית המפתחים. שמענו שהמפתחים שמעו בבירור שהם רוצים את זה!
אה, ואם עדיין לא בדקת את התכונה החדשה, Shared Element Transitions API של צוות האתר ללא חלק (sLLM) עומד לשנות את האופן שבו אנשים מתכננים את האתר. כל המעברים הקטנים והקלים שמאפשרים למעצבים לכוון את העיצובים שלהם במרחב הפיזי יהיו קלים ופשוטים. לג'ייק ארצ'יבלד יש הדגמה מעולה.
יכול להיות שאם הסטנדרטים יהיו טובים, נוכל אפילו לבחון את הקצב האנכי השנה! יש לנו אפשרות לבנות על גבי LayoutNG שמאפשרת גישה לכל כך הרבה תכונות.
תודה לשניכם. אני בטוח שכל הקהילה, כמונו, שמחים לראות את הקצב המחודש של השיפורים והתכונות שיושקו בעולם של ממשק המשתמש באינטרנט. יש עדיין הרבה הפרעות, אז איך אפשר לומר שאף אחד צריך להתחיל את המסע שלו?
Una: המפגש שלנו בנושא מה חדש בפלטפורמת האינטרנט בכנס I/O עוסק בסיכום התכונות העיקריות שהשקנו השנה. אדם ארגייל גם כתב מאמר מעולה על כל הנחיתה החדשות והעתידיות של שירות ה-CSS. באופן קבוע, אני אתמקד בשלב זה בגרסאות יציבות וחשוב לי לשים לב לעבודה הנוספת שתתבצע בקרוב. הסדרה המדהימה חדשים בפלטפורמת האינטרנט היא דרך מצוינת לעשות זאת. ההרשמה לניוזלטר web.dev גם תעביר את התוכן הזה למפתחים בתיבת הדואר הנכנס. בנוסף, מפתחים שרוצים להיות מעורבים בכל מה שצריך ולעזור להם בכל מה שצריך: הצטרפות ל-Open UI היא אחת מהדרכים הטובות ביותר לתמוך בפעילות הזאת.
עדכונים חשובים צפויים
אנחנו שומרים על המסורת שלנו כדי ליידע אתכם לגבי שינוי שצפוי לקרות, שכדאי לזכור כשאתם בונים את חוויות השימוש שלכם באינטרנט.
יש להגביל את הגיל המקסימלי לקובצי cookie ל-400 יום
- העדכון: כשקובצי Cookie מוגדרים עם מאפיין
Expires/Max-Ageמפורש, הערך יוגבל עכשיו ל-400 ימים לכל היותר בעתיד. בעבר, לא הייתה מגבלה והתוקף של קובצי Cookie עשוי לפוג כמה אלפי שנים בעתיד. מטרת המגבלה הזו היא לאזן בין דפוסי שימוש נפוצים לבין שמירה על פרטיות המשתמשים. בכל אתר שמבקרים בו בתדירות גבוהה יותר מ-400 יום, אפשר לרענן קובצי cookie כדי להבטיח את המשכיות השירות, והמשתמשים יכולים להיות בטוחים שקובצי cookie לא יישארו בדפדפן למשך אלפי שנים ללא שימוש. - לוח הזמנים המשוער: משלוח ב-Chrome 104 (יציב ב-2 באוגוסט 2022).
- קריאה לפעולה למפתחים: יכול להיות שהמפתחים יצטרכו לרענן באופן יזום את קובצי ה-cookie בתדירות גבוהה יותר מאשר בעבר, כשמשתמשים נכנסים לאתרים שלהם. אחרת, ייתכן שהמשתמשים ינותקו 400 יום לאחר ההגדרה הראשונית של קובץ ה-cookie.
אני מקווה שנהניתם לקרוא את המהדורה הזו של Chrome Dev Insider. אם פספסת, הנה התשובה הראשונה. נשמח לספק לכם עוד משחקים ברבעון הבא.
עד אז, נשמח לשמוע מה דעתך על המהדורה הזו של Chrome Dev Insider ומה נוכל לעשות כדי לשפר אותה.
מה דעתך על המהדורה הזו של Chrome Dev Insider? שולחים משוב.