مرحبًا بك في الإصدار الثاني من Chrome Dev Insider حيث نشارك آخر الأخبار حول كل ما هو جديد ومثير في المنتدى هنا في Chrome. هذه حلقة جديدة من قصص داخلية حول كيفية تعاملنا مع عملنا، وإلقاء نظرة سريعة على بعض أهم التحديثات التي يجب الانتباه إليها.
أنا رايتشل أندرو، رئيسة قسم المحتوى في web.dev وdeveloper.chrome.com ضمن فريق علاقات مطوّري برامج Chrome. أعمل على الويب منذ أكثر من عشرين عامًا، وأركّز على معايير الويب المفتوحة وCSS، وأنا عضو في مجموعة عمل CSS.
قبل شهرين، اختتمنا مؤتمر Google I/O حيث شاركنا بعض أهم التعديلات حول جهودنا في دعم المطوّرين لجعل الويب أكثر سرعة وفعالية مع الحفاظ على أمان وخصوصية معلومات المستخدمين.
أحد أبرز الأمور التي لفتت انتباهنا (ويسعدنا أنّ المنتدى قد لاحظ) هو الكم الهائل من الإجراءات التي يبذلها الفريق لإتاحة المزيد من ميزات CSS وواجهة المستخدم على الويب. في هذا الإصدار من Chrome Dev Insider، سنطلعكم على ما وراء كواليس هذا العمل، وكيف نعمل على دعم مطوّري CSS وواجهة المستخدم وما مستقبلنا. لهذا السبب يسعدني أن أستضيف هذا الإصدار من Insider.
في الأخبار
في النسخة الأولى من Chrome Dev Insider، شاركنا بعض التعديلات حول مبادرات Compat 2021 وInterop 2022 التي تعاون مورّدو المتصفِّحات ومشغّلو المنظومة المتكاملة معها لتوفير المزيد من الميزات على الويب التي يمكن استخدامها في جميع المتصفحات. تركّز هذه المبادرة بشكل كبير على لغة CSS لأنّ عدم توافق المتصفّح هو أحد أكبر التحديات التي تواجه مطوّري خدمة CSS.
وعلى الرغم من أنّ هذا الخبر قد لا يكون على مستوى معظم الأخبار، إلا أنّه من المشوّق أن نرى التقدم الذي أحرزناه بالفعل عبر المتصفحات.
في وقت سابق من الشهر الماضي، شاهدنا متصفّح Safari أعلن عن إطلاق ملصق صغير يتضمّن الإصدار التجريبي من Safari 16.0 الذي يتضمّن ميزات رائعة مثل Container Query وsubgrid وأداة flexbox Inspector. شملت الإصدارات الحديثة من متصفحَي Firefox وChrome عددًا من الميزات والإصلاحات الرائعة، وأنا بصدد تناول المواضيع الأساسية في المتصفحات الثابتة والتجريبية كل شهر في سلسلة مشاركات الجديدة على النظام الأساسي للويب.
التفاصيل الداخلية: دعم مطوّري CSS وواجهة المستخدم
مع اقتراب عام 2022 للحصول على ميزات CSS، اعتقدنا أنّ هذا العام هو الوقت المناسب للتعرّف على كواليس خدمات CSS. تحدثنا مع أونا كرافيتس، مسؤولة فريق DevRel عن واجهة المستخدم على الويب وDevtools، ونيكول سوليفان، مديرة المنتجات لواجهة المستخدم على الويب التي تركّز على CSS وواجهات برمجة تطبيقات HTML، للتحدث عن رحلة Chrome لدعم مطوّري واجهات المستخدم.
لِنبدأ معكما. هل يمكنك إطلاعنا على مزيد من المعلومات عن نفسك؟
نيكول: أنا مديرة المنتجات لواجهة مستخدم الويب في Chrome. وأركّز بشكل خاص على واجهات برمجة التطبيقات الجديدة بتنسيق CSS وHTML وعلى المطوّرين والمصممين الذين ينشئون واجهة المستخدم. وهو يمثل مساحة مثيرة للاهتمام من خلال بعض واجهات برمجة التطبيقات المهمة حقًا، مثل Container Query (استعلامات الحاوية)، وScope، والإيقاع العمودي (نأمل!)
أونا: أقود فريقَي واجهة مستخدم الويب وDevRel في "أدوات مطوري البرامج". نحن نركّز على دعم مهندسي واجهة المستخدم على منصة الويب ونضمن حصولهم على الأدوات اللازمة لتحقيق النجاح. ويشمل ذلك واجهات برمجة تطبيقات CSS ومكوّنات HTML، إلى جانب ميزات "أدوات مطوّري البرامج" للاطّلاع على التغييرات والملاحظات النشطة.
في السنوات القليلة الماضية، ازدادت وتيرة دعم Chrome لمطوّري برامج واجهة المستخدم. لماذا تعتقد أن الأمر استغرق وقتًا طويلاً للوصول إلى هنا؟ ما هي أكبر التحديات التي واجهتها؟
أونا: احتجنا إلى تنفيذ بعض الأعمال لتوضيح مدى أهمية هذا العمل وسبب وجوب إعطائه الأولوية. بدأنا باستطلاع MDN (الحمض النووي) في 2019، الذي حدّد واجهة المستخدم على أنّها من أهم المشاكل على المنصة. ومنذ ذلك الحين، واصلنا استخدام البيانات كدليلنا من خلال MDN واستطلاعات رضا المطوّرين الداخلية الخاصة بنا. نتيجةً لذلك، استطعنا الحصول على مزيد من دعم القيادة وإعطاء الأولوية للأعمال الهندسية المتعلّقة ببعض الميزات الأكثر طلبًا للمطوّرين ضِمن مساحة واجهة المستخدم، والتي تمثّل أيضًا الجزء الأكبر من التركيز على مبادرات مثل Compat 2021 وInterop 2022.
نيكول: بالإضافة إلى الحصول على دعم القيادة، كان علينا أيضًا إيجاد الطريقة المناسبة لتوفير واجهات برمجة التطبيقات هذه للمطوّرين. عندما انضممت إلى Chrome لأول مرة، أخطأت في ذلك في مشروع يسمى واجهات برمجة التطبيقات ذات الطبقات (أو LAPIs للاختصار). تهدف LAPIs إلى منح المطورين تجربة ذات مكونات أقل. ما زلتُ أعتقد أنّ الهدف كان إيجابيًا، ولكنّنا ارتكبنا الكثير من الأخطاء. ركّزنا أولاً على إشعارات Toast والقائمة الافتراضية. يكاد يكون من المستحيل جعل الوصول إلى الخبز المحمّص، وتعد القائمة الافتراضية من أصعب المكونات التي يجب أخذها في الاعتبار. كانت نوايانا جيدة ولكنها لم تساعد المطورين، لذلك أوقفنا المشروع. من الصعب تعلم الطريق الصعب، ولكن كل خطأ يعزز نهضة CSS وHTML التي تحدث الآن.
لنتحدّث قليلاً عن LAPIs. ما الذي حدث؟
نيكول: بالنسبة إلى LAPIs، أدركنا أنّ الويب بحاجة إلى تجربة خاصة بمطوّري المكوّنات أقرب إلى إنشاء واجهة مستخدم أصلية. وكان من الواضح أن إعادة ابتكار العجلة كانت تعيق المطورين. لا يمكنني حساب عدد علامات التبويب التي أنشأتها خلال مسيرتي المهنية. ومع ذلك، حاولنا حل هذه المشكلة عن طريق شحن JavaScript إلى المتصفح، وكان ذلك صعبًا جدًا. لم يشحن أحد لغة JavaScript في المتصفح من قبل، ولم يكن من الواضح كيف يجب أن يتفاعل مع رمز C++ الذي يعمل على تشغيل محرك عرض المتصفح. لقد استمعنا إلى مورّدي المتصفح الآخرين (شكرًا لك، Mozilla!) وتراجعنا عن هذا النهج وتمكنا من العثور على شيء أفضل بكثير من خلال Open UI. من خلال الاعتماد على HTML وCSS، نتوصل إلى حلول تعريفية مرنة. ولأنّها تعريفية، يمكننا دمج إمكانية الوصول بطريقة لم يكن من السهل تنفيذها باستخدام JavaScript. أنا متحمسة حقًا بشأن ما سيحدث. نحن نعمل على دعم القائمة المحددة والنوافذ المنبثقة والتلميح والتنقّل والأكورديون وعلامات التبويب ولوحة العرض الدوّارة والتبديل، كلّها أنماط أساسية في تصميم واجهة المستخدم.
لقد تعلمنا الكثير. أدرك أنّه كانت هناك مبادرات أخرى في هذا المجال، مثل CSS Houdini. ما هي القصة؟
أونا: نعم، CSS Houdini هي منصة أخرى تعلّمنا فيها من المنتدى. هناك عدد هائل من ميزات Houdini المفيدة، ولكن العديد منها كان ضعيفًا جدًا بحيث تعذّر الوصول إليه والحصول على الدعم على نطاق أوسع. وأدركنا أنّ استخدام واجهات برمجة تطبيقات منخفضة المستوى لم يحدّ بالضرورة من الصعوبات التي يواجهها المطوّرون. وبدلاً من ذلك، ساعد التركيز على حلول واحتياجات ذات مستوى أعلى في جذب الدعم عبر المتصفحات وعمليات التحقيق اللازمة للارتقاء بمدى تقدّمك في المنظومة المتكاملة. يتم حاليًا تتبُّع مستوى التقدّم على الرابط https://ishoudinireadyyet.com.
عند الحديث عن التوافق مع جميع المتصفّحات، يبدو أنّ بعض المبادرات، مثل Interop 2022 وOpen UI (واجهة المستخدم المفتوحة) تحقّق نتائج إيجابية كبيرة للمنتدى. ما رأيك في آراء المطوّرين؟
أونا: واحدة من أهم الشكاوى التي نسمعها من مطوّري البرامج هي "جعل التصميم يعمل بالطريقة نفسها على جميع المتصفحات". وقد تعاملنا مع هذا الأمر من خلال العمل مع مورّدي المتصفحات الآخرين لتحديد أولويات بعض ميزات المطوّرين الأكثر طلبًا وتحقيقها. وكانت الملاحظات التي تلقيناها من أفراد المنتدى إيجابية للغاية. بالإضافة إلى ذلك، أصبح من الممكن تحقيق بعض من هذه الميزات بشكل أكثر فعالية من خلال الجهود الكبيرة التي بذلتها في مجال إعادة الهندسة المعمارية تُسمى RenderingNG. يشعر المطورون بالحماس لأن هذه الميزات التي طال انتظارها والتي طلبوها لسنوات تم العمل عليها أخيرًا للوصول إليها عبر المتصفحات.
نيكول: الحماس في المنتدى واضح. ويمكنك الاطّلاع عليها على Twitter. :)
لقد أثبت العمل باستخدام المنظومة المتكاملة دورًا مهمًا في أي نجاح حققناه في تسهيل حياة المطوّرين. أعلم أن فريقك قام بالكثير من العمل هناك. هل يهمّك مشاركة بعض التفاصيل؟
نيكول: أولاً، أنا مندهش باستمرار من المشاريع التي ينشئها مطوّرو البرامج على الويب. يسعى المطوّرون إلى تطوير ميزات رائعة، بدءًا من أصغر مكتبة وصولاً إلى جميع أطر العمل. إنه منتدى رائع من المبدعين. ويتخذ Chrome أيضًا مجموعة من الخطوات لتعزيز ارتباطها بهذه المشاريع.
على سبيل المثال، بدأنا قبل بضع سنوات العمل باستخدام إطارات عمل JavaScript مثل React وAngular. والأطر الوصفية - على سبيل المثال Next وNuxt وGatsby. وفي العام الماضي، بدأنا نفعل الشيء نفسه باستخدام أدوات وأطر واجهة المستخدم مثل Sass وBotstrap وMaterial. وأتمنى في العام المقبل أن نتمكن من التعاون مع GreenSock وغيرها من الأدوات التي تسهّل حياة المطوّرين. لقد رأيتُ للتو "كاسي إيفانز" من مؤسسة GreenSock تتحدث في Smashing Conference، وكان ذلك يشعرني بالحماس تجاه العمل مع الأشخاص في مجال الصور المتحركة.
أين نرى الفرصة الأكبر للمنظومة المتكاملة لواجهة مستخدم الويب؟
أونا: في ما يتعلق بفرص التحسين الكبيرة، أشعر بأنّنا ما زلنا في بداية إمكاناتنا لتجارب ويب قابلة للتخصيص. تعمل واجهات برمجة التطبيقات الجديدة، مثل طلبات بحث الحاوية وميزات الوسائط المفضّلة للمستخدم في CSS على إعادة تحديد طريقة ظهور التصميم السريع الاستجابة للمطوّرين. أنا متحمس أيضًا لتجارب التصميم التعاونية التي تمكن المطورين والمصممين من العمل في انسجام تام مع المستخدمين الذين يزورون مواقع الويب الخاصة بهم.
بالنسبة إلى "نيكول"، ما هي الخطوات التالية في خطة تحقيق أهداف فريقك؟
نيكول: لا تتحول كل الاستكشافات إلى محتوى قابل للشحن، ولكن هناك الكثير من الأمور التي أشعر بالحماسة بشأنها حاليًا:
لقد تطرقنا أونا إلى أول شيء وهو أننا نقدم تصميمًا سريع الاستجابة قائمًا على المكونات. وهو يتضمن أدوات لتصميم أنظمة الألوان حتى يتمكن المصممون من الاستجابة لتفضيلات المستخدم مثل الوضع الداكن. على سبيل المثال، تحافظ مساحة اللون OKLCH على اتساق السطوع في جميع درجات اللون. يمكن للمصممين الانتقال من اختيار الألوان إلى تصميم العلاقات بين الألوان، دون أن ينتهي بهم الأمر بلوحات ذات مظهر موحل!
ونعمل أيضًا على بعض واجهات برمجة التطبيقات الأكثر طلبًا، مثل طلبات بحث الحاوية وطبقات التتالي وأداة الاختيار الرئيسية (:has) والأنماط ذات النطاق والدمج. يحتاج المطورون إلى هذه الأشياء حتى يتمكنوا من بناء أنظمة تصميم مرنة مليئة بالمكونات القابلة لإعادة الاستخدام.
من الأشياء الممتعة الأخرى أن تكون الرسوم المتحركة المرتبطة بالتمرير. يعجبني جدًا العرض التوضيحي الذي أنشأه "ستيف غاردنر". ولديه التمرير السلس الزبدي والرسوم المتحركة الرائعة بالطائرة التي يتم تشغيلها عند التمرير. على الرغم من أنها ممتعة، فقد يكون من الصعب تنفيذها بشكل صحيح، خاصة مع وضع سهولة الوصول في الاعتبار. لذلك نحن نجري اختبار المستخدم لإمكانية الوصول إلى الميزة الآن.
أكثر ما يهمني شخصيًا هو عناصر التحكم المضمنة في واجهة مستخدم الويب. يواصل المطورون إنشاء مجموعة علامات التبويب نفسها مرارًا وتكرارًا، أعتقد أن المتصفح يمكن أن يساعدك. أو في فتح واجهة المستخدم، نعمل على مكونات مثل selectmenu، والنافذة المنبثقة، وتلميح، وعلامات التبويب، والتنقل، والأكورديون، والتبديل. نحن نستكشف كيف سيبدو إعداد إمكانية الوصول إلى البيانات الأساسية للمتصفّح هذه بحيث يمكن الوصول إلى الويب بشكل تلقائي بمرور الوقت. بعد ذلك يمكن للمطوّرين التركيز على المشاكل الأكثر تعقيدًا وتحديدًا دقة، في حين أنّ المتصفِّح يتيح استخدام الأساسيات مثل علامة تبويب "كيفية إجراء ذلك". ربما يحتاج هذا إلى مشاركة خاصة به، لذلك سأتوقف عند هذا الحد في الوقت الحالي!
وأخيرًا، سنواصل الاستثمار في ميزة إمكانية التشغيل التفاعلي بين المتصفحات. لقد كان العمل مع الموظفين في WebKit وGecko رائعًا لتحقيق الاتساق في تجربة مطوري البرامج. لقد علمنا من المطورين بوضوح أنهم يريدون هذا،
حسنًا، إذا لم تكن قد درست هذه الميزة، ستعمل واجهة برمجة التطبيقات المشتركة للعناصر المشتركة على تغيير طريقة تصميم الأشخاص للويب. كل هذه الانتقالات الصغيرة الدقيقة التي تسمح للمصممين بتوجيه تصميماتهم في المساحة المادية لن تكون ممكنة فحسب، بل سهلة أيضًا. يقدّم "جيك أرشيبالد" عرضًا توضيحيًا رائعًا.
إذا سارت المعايير بشكل جيد، قد نطّلع على الوتيرة الرأسية هذا العام. يمكننا الاعتماد على LayoutNG التي تفتح قفل العديد من الميزات.
شكرًا لكما كليهما. أنا متأكد من أنّ المجتمع بأكمله، مثلنا، متحمسون لرؤية الوتيرة المتجددة للتحسينات والميزات التي سيتم طرحها في عالم واجهة مستخدم الويب. لا يزال هناك الكثير من الغرائز التي يجب التنبّه إليها، فأين يمكن أن يبدأ مسيرته؟
أونا: تتناول جلسة ما الجديد للمنصة على الويب في مؤتمر I/O النقاط البارزة في العديد من الميزات التي سيتم طرحها هذا العام. كتب "آدم أرجيل" أيضًا مقالة رائعة حول جميع عمليات الإرسال الجديدة والقادمة لخدمة مقارنة الأسعار. بشكل مستمر، سأركز على الإصدارات الثابتة في الوقت الحالي، وسأكون على دراية بالأعمال الأخرى التي سيتم تنفيذها في المستقبل. ننصحك بإنشاء سلسلة جديد على النظام الأساسي للويب الرائعة. سيؤدي الاشتراك في النشرة الإخبارية من الموقع الإلكتروني web.dev أيضًا إلى إرسال هذا المحتوى إلى البريد الوارد للمطوّرين. وبالنسبة إلى المطوّرين الذين يريدون المشاركة والمساعدة في حلّ هذه المشكلة، يُعدّ الانضمام إلى Open UI إحدى أفضل الطرق التي تتيح لهم ذلك.
أهم التعديلات القادمة
ونحن نواكب التقليد لدينا لإشعارك بالتغيير القادم الذي يجب مراعاته أثناء إنشاء تجاربك على الويب.
ضبط الحد الأقصى لعمر ملفات تعريف الارتباط على 400 يوم
- التحديث: عند ضبط ملفات تعريف الارتباط باستخدام سمة
Expires/Max-Ageفاضحة، لن يتم الآن تحديد أكثر من 400 يوم كحد أقصى في المستقبل. وفي السابق، لم يكن هناك حد أقصى لحجم ملفات تعريف الارتباط ويمكن أن تنتهي صلاحيتها بعدة آلاف السنين في المستقبل. والهدف من هذا الحد هو تحقيق التوازن بين أنماط الاستخدام الشائعة واحترام خصوصية المستخدم. يمكن تحديث ملفات تعريف الارتباط لأي موقع إلكتروني تتم زيارته بشكل متكرر كل 400 يوم لضمان استمرار الخدمة، كما يطمئن المستخدمون بأنّ ملفات تعريف الارتباط لن تظل في المتصفح لآلاف السنين بدون استخدامها. - المخطط الزمني المقدَّر: الشحن في Chrome 104 (القناة مستقرة في 2 آب (أغسطس) 2022).
- الحثّ على اتخاذ إجراء للمطوِّر: قد يحتاج المطوّرون إلى إعادة تحميل ملفات تعريف الارتباط بشكل استباقي على نحو أكثر من ذي قبل عند زيارة المستخدمين لمواقعهم الإلكترونية. وبخلاف ذلك، قد يتم تسجيل خروج المستخدمين بعد 400 يوم من إعداد ملف تعريف الارتباط في البداية.
آمل أن تكون قد استمتعت بقراءة هذا الإصدار من Chrome Dev Insider. إذا فاتتك الرسالة، إليك أول رسالة. نتطلع إلى تقديم المزيد في الربع القادم.
وحتى ذلك الحين، يمكنك إخبارنا برأيك في هذا الإصدار من Chrome Dev Insider وما يمكننا فعله لتحسينه.
ما رأيك في هذا الإصدار من The Chrome Dev Insider؟ يُرجى مشاركة ملاحظاتك.