مرحبًا بك في الإصدار الثاني من Chrome Dev Insider حيث نشارك آخر الأخبار حول الميزات الجديدة والمثيرة في المنتدى وفي Chrome. هذه حلقة جديدة من سلسلة "قصص من الداخل" حول طريقة عملنا، ونظرة سريعة على بعض أهم التحديثات التي يجب الانتباه إليها.
أنا "راشيل أندرو"، مسؤولة المحتوى في web.dev وdeveloper.chrome.com، وذلك في إطار فريق علاقات المطوّرين في Chrome. أعمل على الويب منذ أكثر من عشرين عامًا، وأركّز على معايير الويب المفتوحة وCSS، وأنا عضو في "فريق عمل CSS".
قبل شهرَين، اختتمنا فعاليات مؤتمر Google I/O حيث شاركنا بعضًا من أهم الأخبار حول كيفية دعمنا للمطوّرين في جعل الويب أسرع وأكثر فعالية مع الحفاظ على أمان معلومات المستخدمين وخصوصيتها.
من بين الميزات التي لفتت الانتباه (ويسعدنا أنّ المنتدى لاحظها!)، الجهد الكبير الذي يبذله الفريق لإتاحة المزيد من ميزات CSS وواجهة المستخدم على الويب. في هذا الإصدار من Chrome Dev Insider، سنوضّح لك الجهة المسؤولة عن هذا العمل، وكيف نعمل على دعم مطوّري CSS وواجهة المستخدم، وما الذي ينتظرنا في المستقبل. لهذا السبب، يسعدني استضافة هذه الحلقة من "المرشد الداخلي".
في الأخبار
في أول منشور Chrome Dev Insider، شاركنا بعض الأخبار حول مبادرتَي Compat 2021 وInterop 2022، حيث تعاون مورّدو المتصفحات والجهات الفاعلة في المنظومة المتكاملة لتقديم المزيد من الميزات المتوافقة مع جميع المتصفحات على الويب. تركّز المبادرة بشكل كبير على CSS لأنّ عدم التوافق مع المتصفحات هو أحد أكبر التحديات التي تواجه مطوّري CSS.
على الرغم من أنّ هذه المعلومات قد لا تكون جديدة على معظم المستخدمين، إلا أنّه من الرائع رؤية التقدّم الذي أحرزناه حتى الآن على مستوى المتصفّحات.
في بداية الشهر الماضي، أعلن Safari عن إصدار جديد من الإصدار التجريبي 16.0 من Safari يتضمّن ميزات رائعة مثل Container Queries وsubgrid وflexbox inspector. تضمّنت الإصدارات الأخيرة من Firefox وChrome عددًا من الميزات الرائعة وعمليات الإصلاح. وأنا أتناول في سلسلة مشاركاتي ميزات جديدة في منصة الويب أهم الميزات في المتصفحات الثابتة والتجريبية كل شهر.
معلومات حصرية: دعم مطوّري CSS وواجهات المستخدم
بعد أن شهدنا عامًا حافلاً بالميزات الجديدة في CSS، أردنا أن نطلعك على بعض التفاصيل. لقد أجريتُ مقابلة مع أونا كرافيتس، وهي المسؤولة عن علاقات المطوّرين في فريق واجهة المستخدم على الويب وأدوات المطوّرين، ونيكول سوليفان، وهي مديرة المنتجات في فريق واجهة المستخدم على الويب التي تركّز على واجهات برمجة التطبيقات CSS وHTML، وذلك للحديث عن رحلة Chrome نحو توفير الدعم لمطوّري واجهات المستخدم.
لنبدأ بكما. هل يمكنكم إخبارنا ببعض المعلومات عن أنفسكم؟
نيكول: أنا مديرة المنتج لواجهة المستخدم على الويب في Chrome. أركّز تحديدًا على واجهات برمجة التطبيقات الجديدة في CSS وHTML وعلى المطوّرين والمصمّمين الذين ينشئون واجهات المستخدم. إنّها مساحة مثيرة تتضمّن بعض واجهات برمجة التطبيقات المهمة جدًا، مثل طلبات البحث في الحاويات وScope والإيقاع العمودي (نأمل أن تكون متاحة).
أونا: أنا أترأس فِرق Web UI وDevTools DevRel. نركّز على دعم مهندسي واجهات المستخدم على منصة الويب ونتأكّد من توفير الأدوات التي يحتاجونها لتحقيق النجاح. ويشمل ذلك واجهات برمجة تطبيقات CSS ومكوّنات HTML بالإضافة إلى ميزات "أدوات مطوّري البرامج" للاطّلاع على التغييرات النشطة والملاحظات.
تزايدت وتيرة توفير Chrome لأدوات دعم مطوّري واجهات المستخدم في السنوات القليلة الماضية. لماذا استغرق الأمر وقتًا طويلاً للوصول إلى هنا؟ ما هي أكبر التحديات التي واجهتها؟
أونا: كان علينا بذل بعض الجهد لإثبات أهمية هذا العمل وتوضيح سبب ضرورة إعطائه الأولوية. بدأنا باستطلاع MDN DNA في عام 2019، والذي حدّد واجهة المستخدم كإحدى أهم المشاكل التي تواجه المستخدمين على المنصة. ومنذ ذلك الحين، واصلنا استخدام البيانات كدليل لنا من خلال MDN واستطلاعات الرضا الداخلية الخاصة بالمطوّرين. نتيجةً لكل ذلك، تمكّنا من الحصول على موافقة أكبر من القيادة، وتمكّنا من تحديد أولويات أعمال الهندسة المتعلقة ببعض ميزات المطوّرين الأكثر طلبًا في مساحة واجهة المستخدم والتي تشكّل أيضًا الجزء الأكبر من تركيز مبادرات مثل Compat 2021 وInterop 2022.
نيكول: بالإضافة إلى الحصول على موافقة القيادة، كان علينا أيضًا إيجاد الطريقة المناسبة لإتاحة واجهات برمجة التطبيقات هذه للمطوّرين. عندما انضممتُ لأول مرة إلى فريق Chrome، أخطأتُ في هذا الأمر في مشروع يُعرف باسم Layered APIs (أو LAPIs باختصار). كانت واجهات LAPIs تهدف إلى منح المطوّرين تجربة استخدام مكوّنات جاهزة. ما زلت أعتقد أنّ هذه كانت نتيجة رائعة نسعى إلى تحقيقها، ولكننا ارتكبنا الكثير من الأخطاء. ركّزنا أولاً على الإشعارات المؤقتة والقائمة الافتراضية. من المستحيل تقريبًا إتاحة استخدام الإشعارات المنبثقة، كما أنّ القائمة الافتراضية هي أحد أصعب المكوّنات التي يجب إعدادها بشكل صحيح. كانت نوايانا حسنة، ولكنّ المشروع لم يساعد المطوّرين، لذا أوقفناه نهائيًا. من الصعب التعلّم من الأخطاء، ولكن كل خطأ يساهم في إحياء CSS وHTML الذي يحدث الآن.
لنتحدّث قليلاً عن واجهات LAPIs. ما الذي حدث هناك؟
نيكول: بالنسبة إلى واجهات برمجة التطبيقات المحلية (LAPIs)، أدركنا أنّ الويب يحتاج إلى تجربة مطوّرين قريبة من إنشاء واجهة مستخدم أصلية. وكان من الواضح أنّ إعادة اختراع العجلة يعيق تقدّم المطوّرين. لا يمكنني حساب عدد الأغاني التي كتبتها خلال مسيرتي المهنية. مع ذلك، حاولنا حلّ هذه المشكلة من خلال تضمين JavaScript في المتصفّح، وهو أمر كان صعبًا للغاية. لم يسبق لأحد أن أطلق JavaScript في المتصفح، ولم يكن واضحًا كيف يجب أن تتفاعل مع رمز C++ الذي يشغّل محرك العرض في المتصفح. لقد استمعنا إلى مقدّمي خدمات المتصفحات الآخرين (شكرًا لك، Mozilla!) وتراجعنا عن هذا النهج، وبالتالي تمكّنا من العثور على حلّ أفضل بكثير باستخدام Open UI. من خلال الاعتماد على HTML وCSS، نتوصل إلى حلول مرنة وتصريحية. وبما أنّها تعريفية، يمكننا تضمين ميزات تسهيل الاستخدام بطريقة لم يكن من السهل تنفيذها باستخدام JavaScript. أنا متحمّس جدًا بشأن ما سيحدث في المستقبل. نحن نعمل على توفير selectmenu وpopup وtooltip وnav وaccordion وtabs وcarousel وtoggle، وهي أنماط تصميم أساسية لواجهة المستخدم.
لقد تعلّمنا الكثير. وأعلم أنّ هناك مبادرات أخرى في هذا المجال، مثل CSS Houdini. ما هي القصة؟
أونا: نعم، CSS Houdini هو مثال آخر على ما تعلّمناه من المنتدى. تتوفّر الكثير من ميزات Houdini المفيدة، ولكنّ العديد منها كان منخفض المستوى جدًا لكي يحظى بانتشار ودعم أوسع نطاقًا. أدركنا أنّ استخدام واجهات برمجة التطبيقات المنخفضة المستوى لا يقلّل بالضرورة من المشاكل التي يواجهها المطوّرون. بدلاً من ذلك، ساعد التركيز على الحلول والاحتياجات ذات المستوى الأعلى في الحصول على دعم من المتصفحات المختلفة وفي توفير الصفحات المقصودة اللازمة لإحداث تغيير في المنظومة المتكاملة. يمكنك الاطّلاع على مستوى التقدّم حاليًا على https://ishoudinireadyyet.com/.
في ما يتعلّق بالتوافق مع المتصفّحات المختلفة، يبدو أنّ مبادرات مثل Interop 2022 وOpen UI تحقّق نتائج إيجابية كبيرة للمنتدى. ما هي الملاحظات التي تلقّيناها من المطوّرين؟
أونا: من أهم المشاكل التي يواجهها المطوّرون هي "جعل التصميم يعمل بالطريقة نفسها على جميع المتصفّحات". وقد عالجنا هذه المشكلة من خلال العمل مع مورّدي متصفّحات آخرين لتحديد أولويات بعض ميزات المطوّرين الأكثر طلبًا وإتاحتها. وقد تلقّينا ملاحظات إيجابية للغاية من المنتدى. بالإضافة إلى ذلك، أصبح من الممكن توفير بعض هذه الميزات بأداء أفضل بكثير من خلال عملية إعادة تصميم كبيرة تُعرف باسم RenderingNG. يسرّ المطوّرين أنّنا نعمل أخيرًا على هذه الميزات التي طال انتظارها والتي طلبوها على مدار سنوات، وأنّها ستكون متاحة على جميع المتصفّحات.
نيكول: الحماس في المنتدى واضح. يمكنك الاطّلاع عليها على Twitter. :)
لقد تبيّن أنّ التعاون مع المنظومة المتكاملة أمر بالغ الأهمية لتحقيق أي نجاح في تسهيل حياة المطوّرين. أعلم أنّ فريقك بذل جهدًا كبيرًا في هذا المجال. هل يمكنك مشاركة بعض التفاصيل؟
نيكول: أولاً، أُعجب باستمرار بالمشاريع التي ينشئها المطوّرون على الويب. يستخدم المطوّرون أصغر المكتبات وأكثرها شمولاً لإنشاء تطبيقات رائعة. إنّه منتدى رائع للمصنّعين. ويتّخذ Chrome مجموعة من الخطوات ليكون أكثر ارتباطًا بهذه المشاريع.
على سبيل المثال، بدأنا قبل بضع سنوات العمل مع أُطر JavaScript، مثل React وAngular. والأُطر الوصفية، مثل Next وNuxt وGatsby في العام الماضي، بدأنا بتطبيق الأمر نفسه على أدوات وأُطر واجهة المستخدم، مثل Sass وBootstrap وMaterial. آمل أن نتمكّن في العام المقبل من التعاون مع GreenSock وأدوات أخرى تسهّل عمل المطوّرين. لقد استمعتُ إلى محاضرة ألقتها "كاسي إيفانز" من GreenSock في مؤتمر Smashing Conference، وقد أثارت حماسي للعمل مع أشخاص في مجال الرسوم المتحركة.
إذًا، أين نرى أكبر فرصة لمنظومة واجهات مستخدم الويب المتكاملة؟
أونا: في ما يتعلّق بالفرص الكبيرة، أعتقد أنّنا لم نستفد بعد من كل الإمكانات المتاحة لتخصيص تجارب الويب. تعيد واجهات برمجة التطبيقات الجديدة، مثل استعلامات الحاويات وميزات الوسائط المفضّلة لدى المستخدم في CSS، تعريف الطريقة التي يرى بها المطوّرون التصميم السريع الاستجابة. أنا متحمّس أيضًا بشأن تجارب التصميم التعاوني التي تتيح للمطوّرين والمصمّمين العمل معًا مع المستخدمين الذين يزورون مواقعهم الإلكترونية.
نيكول، ما هي الخطوة التالية في خارطة الطريق التي يتبعها فريقك؟
نيكول: لا تؤدي كل الاستكشافات إلى منتج قابل للشحن، ولكن هناك الكثير من الأشياء التي أتحمّس لها حاليًا:
أشارت "أونا" إلى النقطة الأولى، وهي أنّنا نتيح تصميمًا سريع الاستجابة يستند إلى المكوّنات. ويتضمّن أدوات لتصميم أنظمة الألوان حتى يتمكّن المصمّمون من الاستجابة لتفضيلات المستخدمين، مثل الوضع الداكن. على سبيل المثال، تحافظ مساحة الألوان OKLCH على مستوى السطوع متسقًا في جميع درجات الألوان. يمكن للمصمّمين الانتقال من اختيار الألوان إلى تصميم علاقات بين الألوان، بدون الحصول على لوحات ألوان تبدو باهتة.
نعمل أيضًا على بعض واجهات برمجة التطبيقات الأكثر طلبًا، مثل طلبات البحث في الحاويات وطبقات التتالي وأداة اختيار العنصر الأصل (:has) والأنماط المحدودة النطاق والتداخل. يحتاج المطوّرون إلى هذه الأدوات حتى يتمكّنوا من إنشاء أنظمة تصميم مرنة تتضمّن مكونات قابلة لإعادة الاستخدام.
تُعدّ الصور المتحركة المرتبطة بالتمرير منطقة ممتعة أخرى. يعجبني العرض التوضيحي الذي قدّمه "ستيف غاردنر" كثيرًا. يوفّر هذا الموقع تجربة تصفّح سلسة للغاية، كما يعرض صورًا متحركة رائعة للطائرات عند التصفّح. على الرغم من أنّ هذه الميزات ممتعة، قد يكون من الصعب استخدامها بشكل صحيح، خاصةً مع مراعاة إمكانية الوصول. لذلك، نحن نجري حاليًا اختبارات للمستخدمين حول ميزات تسهيل الاستخدام في هذه الميزة.
أكثر ما يثير حماسي شخصيًا هو عناصر التحكّم المضمّنة في واجهة مستخدم الويب. يواصل المطوّرون إنشاء مجموعات علامات التبويب نفسها مرارًا وتكرارًا، وأعتقد أنّ المتصفّح يمكنه المساعدة في ذلك. في Open UI، نعمل على تطوير مكونات مثل selectmenu وpopup وtooltip وtabs وnav وaccordion وtoggle. نحن بصدد استكشاف كيفية دمج ميزات تسهيل الاستخدام في هذه العناصر الأساسية للمتصفح، ما يتيح إمكانية الوصول إلى الويب تلقائيًا بمرور الوقت. يمكن للمطوّرين بعد ذلك التركيز على المشاكل الأكثر تعقيدًا ودقة، بينما يمكن للمتصفّح التعامل مع الأساسيات، مثل كيفية ترتيب علامات التبويب. من المحتمل أنّ هذا الموضوع يحتاج إلى مشاركة منفصلة، لذا سأتوقّف هنا الآن.
أخيرًا، سنواصل الاستثمار في التوافق بين المتصفحات. لقد كان من الرائع العمل مع فريقَي WebKit وGecko لتحقيق التوافق في تجربة المطوّرين. لقد استمعنا إلى ملاحظات المطوّرين التي أكّدت على أهمية هذه الميزة.
إذا لم تكن قد جرّبتها بعد، ستغيّر واجهة برمجة التطبيقات Shared Element Transitions API التي أطلقها فريق Seamless Web طريقة تصميم المواقع الإلكترونية. ستصبح كل تلك الانتقالات الصغيرة الدقيقة التي تتيح للمصمّمين توجيه تصاميمهم في المساحة المادية ليست ممكنة فحسب، بل سهلة أيضًا. قدّم "جيك أرشيبالد" عرضًا توضيحيًا رائعًا.
قد نلقي نظرة على التناغم العمودي هذا العام إذا سارت المعايير على ما يرام. يمكننا الاستفادة من LayoutNG التي تتيح العديد من الميزات.
شكرًا لكما. أنا متأكد من أنّ المنتدى بأكمله، مثلنا، متحمّس لرؤية الوتيرة المتجددة للتحسينات والميزات التي ستتوفّر في واجهة مستخدم الويب. لا يزال هناك الكثير من المعلومات التي يجب استيعابها، فما هي الخطوة الأولى التي تنصح بها؟
أونا: تتناول جلستنا ما الجديد في منصة الويب في مؤتمر I/O أهم الميزات التي سيتم طرحها هذا العام. كتب "آدم آرجايل" أيضًا مقالة رائعة حول جميع صفحات CSS المقصودة الجديدة والقادمة. في الوقت الحالي، أنصحك بالتركيز على الإصدارات الثابتة فقط، مع العلم أنّ هناك إصدارات أخرى قيد الإعداد. سلسلة ميزات جديدة على منصة الويب الرائعة هي سلسلة ممتازة لمتابعة هذه التحديثات. سيؤدي الاشتراك في النشرة الإخبارية من web.dev أيضًا إلى إرسال هذا المحتوى إلى صندوق البريد الوارد للمطوّرين. بالنسبة إلى المطوّرين الذين يريدون المشاركة والمساعدة في كل ما سبق، يُعدّ الانضمام إلى Open UI من أفضل الطرق التي يمكنهم من خلالها دعم هذا العمل.
التحديثات الرئيسية القادمة
نواصل تقديم إشعارات مسبقة بشأن التغييرات القادمة التي يجب أخذها في الاعتبار أثناء إنشاء تجارب الويب.
حصر max-age لملفات تعريف الارتباط بـ 400 يوم
- التعديل: عند ضبط ملفات تعريف الارتباط باستخدام السمة
Expires/Max-Ageالصريحة، سيتم الآن تحديد القيمة بما لا يزيد عن 400 يوم في المستقبل. في السابق، لم يكن هناك حدّ أقصى، وكان من الممكن أن تنتهي صلاحية ملفات تعريف الارتباط بعد آلاف السنين. والهدف من هذا الحدّ هو تحقيق التوازن بين أنماط الاستخدام الشائعة واحترام خصوصية المستخدم. يمكن لأي موقع إلكتروني تتم زيارته بشكل متكرّر أكثر من مرة كل 400 يوم إعادة تحميل ملفات تعريف الارتباط لضمان استمرار الخدمة، ويمكن للمستخدمين الاطمئنان إلى أنّ ملفات تعريف الارتباط لن تبقى في المتصفّح لآلاف السنين بدون استخدام. - الجدول الزمني المقدَّر: سيتم طرح هذه الميزة في الإصدار 104 من Chrome (الإصدار الثابت في 2 آب (أغسطس) 2022).
- عبارة الحث على اتّخاذ إجراء للمطوّرين: قد يحتاج المطوّرون إلى إعادة تحميل ملفات تعريف الارتباط بشكل استباقي بوتيرة أكبر من السابق عندما يزور المستخدمون مواقعهم الإلكترونية. وبخلاف ذلك، قد يتم تسجيل خروج المستخدمين بعد 400 يوم من ضبط ملف تعريف الارتباط في البداية.
أتمنى أن تكون قد استمتعت بقراءة هذا العدد من "رسالة إخبارية من فريق Chrome Dev". إذا فاتتك، إليك الأولى. نتطلّع إلى تقديم المزيد من الميزات في الربع القادم.
في الوقت الحالي، يُرجى إخبارنا برأيك حول هذا الإصدار من "أخبار من فريق Chrome Dev" وما يمكننا فعله لتحسينه.
ما رأيك في هذه النسخة من "أخبار من فريق Chrome Dev"؟ مشاركة ملاحظاتك