مرحبًا بك في النسخة الثانية من 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 عن إصدار ضخم من الإصدار التجريبي 16.0 من Safari يتضمّن ميزات مثيرة مثل طلبات البحث عن الحاويات والشبكة الفرعية وأداة فحص المربّع المرن. تضمّنت الإصدارات الأخيرة من Firefox وChrome عددًا من الميزات والإصلاحات المثيرة للاهتمام. ونتناول كل شهر في سلسلة المشاركات معلومات جديدة حول منصة الويب أهم الميزات في المتصفحات الثابتة والتجريبية.
معلومات حصرية: دعم مطوّري CSS وواجهات المستخدم
مع حلول العام 2022، الذي يُعدّ عامًا مثيرًا لميزات CSS، قرّرنا أن نأخذك في جولة خلف الكواليس. لقد جلست مع Una Kravets، رئيسة قسم تطوير العلاقات مع المطوّرين لواجهة المستخدم على الويب وأدوات المطوّرين، وNicole Sullivan، مديرة المنتجات لواجهة المستخدم على الويب التي تركّز على واجهات برمجة التطبيقات لتنسيقَي CSS وHTML، للحديث عن رحلة Chrome لدعم مطوّري واجهة المستخدم.
لنبدأ بكما. هل يمكنكم إخبارنا ببعض المعلومات عن أنفسكم؟
نيكول: أنا مديرة المنتجات في واجهة المستخدم على الويب في Chrome. أركز بشكل خاص على واجهات برمجة التطبيقات الجديدة لتنسيقَي CSS وHTML وعلى المطوّرين والمصمّمين الذين يبنون واجهة المستخدم. إنّها مساحة مثيرة للاهتمام مع بعض واجهات برمجة التطبيقات المهمة جدًا التي يتم طرحها، مثل طلبات بحث الحاوية والنطاق والإيقاع العمودي (على أمل أن يكون ذلك).
أونا: أنا رئيسة فريقَي تطوير العلاقات مع المطوّرين في واجهة المستخدم على الويب و"أدوات مطوّري البرامج". نحن نركّز على دعم مهندسي واجهة المستخدم على منصة الويب والتأكّد من توفّر الأدوات التي يحتاجونها لتحقيق النجاح. ويشمل ذلك واجهات برمجة تطبيقات CSS ومكوّنات HTML بالإضافة إلى ميزات "أدوات مطوّري البرامج" للاطّلاع على التغييرات النشطة والملاحظات.
لقد ازدادت سرعة تحسين Chrome لمطوّري واجهة المستخدم في السنوات القليلة الماضية. ما رأيك في سبب استغراق هذا الوقت الطويل للوصول إلى هنا؟ ما هي أكبر التحديات التي واجهتها؟
أونا: كان علينا إجراء بعض الأعمال لإظهار مدى أهمية هذا العمل وسبب ضرورة إعطاء الأولوية له. بدأنا بإجراء استطلاع MDN DNA في عام 2019، الذي حدد واجهة المستخدم كأحد أهم المشاكل في المنصة. ومنذ ذلك الحين، واصلت Google استخدام البيانات كدليل لها في MDN واستطلاعات الرضا الداخلية الخاصة بالمطوّرين. نتيجةً لذلك، تمكّنا من الحصول على موافقة أكثر فاعلية من القادة وتمكّنا من إعطاء الأولوية للعمل الهندسي حول بعض الميزات الأكثر طلبًا من المطوّرين في مساحة واجهة المستخدم، والتي تشكّل أيضًا معظم التركيز على مبادرات مثل Compat 2021 وInterop 2022.
نيكول: بالإضافة إلى الحصول على موافقة القادة، كان علينا أيضًا العثور على الطريقة المناسبة لتوفير واجهات برمجة التطبيقات هذه للمطوّرين. عندما انضممت إلى Chrome لأول مرة، أخطأت في مشروع يُسمى Layered APIs (أو LAPIs اختصارًا). كان الهدف من واجهات برمجة التطبيقات هذه هو منح المطوّرين تجربة مكونات قابلة للاستخدام الفوري. ما زلت أعتقد أنّ هذه نتيجة رائعة نسعى إليها، ولكننا ارتكبنا الكثير من الأخطاء. ركزنا أولاً على الإشعارات المنبثقة والقائمة الافتراضية. يكاد يكون من المستحيل الوصول إلى الإشعارات المنبثقة، وتعد القائمة الافتراضية من أصعب المكوّنات التي يمكن إتقانها. كانت نوايانا حسنة، ولكنّ المشروع لم يكن مفيدًا للمطوّرين، لذلك أوقفناه نهائيًا. من الصعب تعلُّم CSS وHTML من خلال التجربة والخطأ، ولكن كل خطأ يساهم في إعادة إحياء CSS وHTML التي تحدث الآن.
لنتحدث قليلاً عن واجهات برمجة التطبيقات لجهات خارجية. ما الذي حدث؟
نيكول: بالنسبة إلى واجهات برمجة التطبيقات لتطبيقات الويب، كنا نعلم أنّ الويب بحاجة إلى تجربة مطوّر مكونات قابلة للاستخدام الفوري تكون أقرب إلى إنشاء واجهة مستخدم أصلية. وكان من الواضح أنّ إعادة اختراع العجلة كان يعرقل المطوّرين. لا يمكنني إحصاء عدد علامات التبويب التي أنشأتها خلال مسيرتي المهنية. ومع ذلك، حاولنا حلّ هذه المشكلة من خلال شحن JavaScript مع المتصفّح، وهو أمر كان صعبًا جدًا. لم يسبق لأحد شحن JavaScript في المتصفّح، ولم يكن من الواضح كيف يجب أن يتفاعل مع رمز C++ الذي يشغّل محرّك عرض المتصفّح. لقد استمعنا إلى مورّدي المتصفّحات الآخرين (شكرًا لك، Mozilla) وتراجعنا عن هذا النهج، وبالتالي تمكّنا من العثور على ميزة أفضل بكثير من خلال واجهة المستخدم المفتوحة. ومن خلال الاعتماد على 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) والأنماط على مستوى نطاق معيّن والتداخل. يحتاج المطوّرون إلى هذه الأدوات حتى يتمكّنوا من إنشاء أنظمة تصميم مرنة مليئة بالمكونات القابلة لإعادة الاستخدام.
يمكنك أيضًا الانتقال إلى الصور المتحركة المرتبطة. أعجبني حقًا العرض الترويجي الذي أعدّه "ستيف غاردنر". يعرض محتوى سلسًا وصورًا متحركة رائعة للطائرات يتم تشغيلها عند الانتقال إلى الأعلى أو الأسفل. على الرغم من أنّ هذه التجارب ممتعة، إلا أنّه قد يكون من الصعب إكمالها بشكل صحيح، خاصةً مع مراعاة تسهيل الاستخدام. لذلك، نحن بصدد إجراء اختبارات على المستخدمين لتقييم مدى سهولة استخدام هذه الميزة.
إنّ أكثر ما يهمّني شخصيًا هو عناصر التحكّم المضمّنة في واجهة المستخدم على الويب. يواصل المطوّرون إنشاء مجموعة علامات التبويب نفسها مرارًا وتكرارًا، وأعتقد أنّ المتصفح يمكن أن يساعدهم في ذلك. في واجهة المستخدم المفتوحة، نعمل على مكونات مثل قائمة الاختيار والنوافذ المنبثقة ونصائح التلميح وعلامات التبويب وعناصر التنقّل واللوحات المنسدلة ومفتاح التبديل. نحن نستكشف شكل دمج ميزات تسهيل الاستخدام في هذه العناصر الأساسية للمتصفّح حتى يصبح بإمكان المستخدمين الوصول إلى الويب تلقائيًا بمرور الوقت. ويمكن للمطوّرين بعد ذلك التركيز على المشاكل الأكثر تعقيدًا ودقّة، في حين يمكن للمتصفّح توفير الأساسيات، مثل كيفية استخدام علامات التبويب. قد تحتاج هذه المشكلة إلى مشاركة خاصة بها، لذا سأتوقف عند هذا الحدّ الآن.
أخيرًا، سنواصل الاستثمار في إمكانية التشغيل التفاعلي بين المتصفحات. لقد كان من الرائع العمل مع فريقَي 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 Insider. إذا فاتتك هذه المقالة، يمكنك الاطّلاع على المقالة الأولى. ونتطلّع إلى تقديم المزيد من الميزات في الربع التالي.
إلى ذلك الحين، يُرجى مشاركة ملاحظاتك حول هذا العدد من Chrome Dev Insider والإجراءات التي يمكننا اتّخاذها لتحسينه.
ما رأيك في هذا العدد من The Chrome Dev Insider؟ مشاركة ملاحظاتك