ميثاق Web Performance في W3C يفصل اهتمام المنفذين عن قابلية التشغيل البيني

الخلاصة

• أقر W3C ميثاق Web Performance Working Group في 10 أغسطس 2026، ويمتد حتى 1 أغسطس 2028.
• ينبغي أن تحصل الميزة الجديدة على إبداء اهتمام من منفذين اثنين على الأقل قبل إدراجها في مواصفات تُحافظ عليها المجموعة بصفتها Candidate Recommendations.
• إذا لم تتوفر عبارتا الاهتمام، يمكن إدراج الميزة في Candidate Recommendation Draft بشرط وضع وسم at risk عليها.
• يتوقع تجاوز Candidate Recommendation وجود تنفيذين مستقلين قابلين للتشغيل البيني لكل ميزة، تثبتهما اختبارات مفتوحة؛ مع بقاء مسار استثناء معلل وعلني في W3C Process.
• يلزم سجل حالة لكل ميزة يفصل الاهتمام واعتماد المجموعة ووسم المخاطر وهوية التنفيذ وإصدار الاختبار وقرار الانتقال.

ماذا يثبت الاهتمام؟

تعمل مجموعة Web Performance على وسائل قياس التحميل والرسم والاستجابة للتفاعل والذاكرة وغيرها من سلوك التطبيقات. وفي 10 أغسطس أعلن W3C إقرار الميثاق ودعا إلى المشاركة، محدداً 1 أغسطس 2028 نهاية لفترته.

بين مسودة يونيو والنص المعتمد تغيرت عبارة في معايير النجاح. كانت المسودة تتحدث عن دعم منفذين اثنين على الأقل. أما النص النهائي فيستخدم تعبيرات الاهتمام. هذا الاختيار يضبط المعنى بدلاً من أن يخفض الطموح.

قد ترى مؤسسة أن المشكلة جديرة بالمراجعة، أو تنشئ نموذجاً تجريبياً، أو تريد بقاء خيار تقني متاحاً قبل قرار المنتج. ويمكن أن تفعل ذلك من دون فريق مخصص أو موعد إصدار أو وعد بالتفعيل الافتراضي. يثبت التصريح أن العمل يستحق الانتباه، لكنه لا يثبت وجود سلوك متوافق بين منتجات مستقلة.

لهذه الدعوى اللاحقة معيار آخر. يتوقع الميثاق، قبل تجاوز Candidate Recommendation، تنفيذين مستقلين قابلين للتشغيل البيني لكل ميزة، مع إمكان التحقق عبر حزم اختبارات مفتوحة، ويفرض وجود حزمة مفتوحة لكل ميزة. هنا لا يُسأل عن موقف المؤسسة، بل عن نتيجة يمكن تكرارها عند تشغيل الاختبار على نظامين مستقلين.

الجمع بين الحالتين تحت كلمة «دعم» يزيل المعلومة التي حاول الميثاق إضافتها.

أربعة أوضاع لا خانة واحدة

يبدأ الاقتراح في مرحلة الاحتضان داخل Web Platform Incubator Community Group، حيث تتطور حالات الاستخدام والنماذج من دون أن تكون Web Performance Working Group قد تبنته رسمياً.

ثم يأتي اعتماد المجموعة. يقول الميثاق إن اقتراح WICG الذي نُفذ وأصبح متاحاً في متصفح رئيسي واحد على الأقل، وحصل على دعم إضافي، يجوز أن تتبناه WebPerf. يتغير عندها موضع القرار المؤسسي، لكن لا يظهر تلقائياً تنفيذ مستقل ثانٍ.

الوضع الثالث هو الوجود في Candidate Recommendation Draft. تسمح الصياغة بإدخال ميزة لا تملك عبارتي اهتمام إذا وُسمت بأنها at risk. الغاية إبقاء فرصة التجربة مفتوحة مع إعلان أن بقاء الميزة في الانتقال التالي غير مضمون.

أما الوضع الرابع فهو دليل التنفيذ الذي يسمح بالانتقال. يصف W3C Process مرحلة Candidate Recommendation بأنها وقت جمع الخبرة التنفيذية. كما يميز بين CR Draft، الذي يعرض تغييرات مقصودة للمراجعة، وCR Snapshot الذي يؤدي وظيفة انتقالية وبراءاتية مختلفة. لذلك لا تكفي جملة «الميزة في CR» لتحديد حالتها.

قد تعني علامة واحدة في جدول الدعم تعليقاً إيجابياً أو نموذجاً خلف إعداد تجريبي أو قرار اعتماد من المجموعة أو نجاح جزء من الاختبارات أو تشغيلية بين تنفيذين مستقلين. لا يمكن معرفة أيها المقصود من اللون وحده.

رد Mozilla يحدد نطاقه بوضوح

في الرد العلني على مراجعة الميثاق، أيدت Mozilla المقترح سواء اعتُمدت تعديلاتها أم لا، وأيدت تغيير العبارة المتعلقة بدعم منفذين اثنين. كما أشارت إلى نية مراجعة المسودات وتطوير تنفيذات تجريبية وتقارير خبرة وبناء منتجات على أساس العمل.

لم يتضمن حقل الجدول الزمني العلني تاريخاً للتنفيذ.

هذه ليست فجوة ينبغي ملؤها بالتخمين. الرد يعبر عن اهتمام عام بعمل المجموعة، ولا يقدم التزاماً لكل ميزة. لا يسمي منفذين لواجهة محددة، ولا إصدار متصفح، ولا موعد تفعيل. احتسابه تنفيذاً منجزاً يضيف إلى كلام Mozilla ما لم تقله.

ولا تعوض قائمة المشاركين هذا النقص. المشاركة تمنح المؤسسة دوراً في المراجعة والعمل، لكنها ليست موافقة شاملة على كل ميزة ولا كشفاً لخطة المنتج.

At risk حالة لا حكم بالفشل

يوحي التعبير خارج سياق المعايير بأن الفشل متوقع. أما في W3C Process فيؤدي الوسم وظيفة أضيق: يحذر من إمكان إزالة الميزة في انتقال لاحق وفق مسار محدد. وبذلك لا تنتقل مرتبة الوثيقة كلها إلى كل ميزة بداخلها.

ينبغي ربط الوسم بمعرف الميزة وإصدار المواصفة. وإذا أزيل، يجب أن يوضح السجل هل وصل اهتمام ثانٍ، أم اكتمل تنفيذ، أم ضُيق النطاق، أم حُذفت الميزة، أم تغير ترتيب النص فقط.

والاختبار يحتاج هوية مماثلة. عبارة «نجح متصفحان» تظل ناقصة من دون إصدار المنتج والمحرك، وحالة التفعيل الافتراضي، ومراجعة Web Platform Tests، والتغطية، والنتائج المتبقية. وقد يشترك منتجان في أصل واحد للكود؛ لذا تحتاج الاستقلالية إلى سبب تقني، لا إلى عد شعارين.

الاستثناء قرار يجب إظهاره

يصف الميثاق التنفيذين المستقلين بأنهما متوقعان. ويسمح W3C Process للـTeam، عند وجود سبب قاهر، بالموافقة على انتقال بخبرة تنفيذية محدودة، على أن ينشر القرار وتعليله.

لا يلغي ذلك القاعدة، بل ينشئ حالة جديدة: الجهة التي قررت، وإصدار Process، والنطاق، والدليل، والسبب. وقد يكون الاستثناء المعلن أكثر نزاهة من عد تنفيذين اسميين يقومان على أصل تقني واحد.

يفيد تمييز Heng Lu بين النشر والتبني هنا: لا يجعل الإعلان وحده التغيير واقعاً من دون تنفيذ واختبار واستخدام. لكن العكس صحيح أيضاً؛ الكود العامل لا يمنح نفسه صفة W3C Recommendation. السلطة المؤسسية والدليل التشغيلي مختلفان، ويجب عرضهما معاً من دون استبدال أحدهما بالآخر.

إيصال حالة الدليل لكل ميزة

ينشر W3C بالفعل المواثيق والمواصفات والقضايا والاختبارات والقرارات وصفحات الحالة. ويمكن لوثيقة ربط صغيرة أن تسجل:

• معرفاً ثابتاً للميزة ومراجعة غير قابلة للالتباس من المواصفة؛
• إصدار الميثاق وW3C Process المطبقين؛
• كل عبارة اهتمام علنية، مع المنفذ والتاريخ والنطاق والمصدر؛
• هل التصريح استكشافي أو مجدول أو منفذ أو مسحوب أو بلا موعد؛
• قرار اعتماد Working Group ومراجعة الاقتراح المعتمدة؛
• رابط وسم at-risk وتاريخ إضافته وتغييره؛
• المنتج والمحرك والإصدار لكل تنفيذ، وسبب اعتباره مستقلاً؛
• مراجعة حزمة الاختبار المفتوحة وتغطيتها ونتائجها المؤرخة؛
• الانتقال والاعتراضات وأي استثناء منشور؛
• المراجعة المقبلة والتصحيح والاستبدال.

لا يتطلب الإيصال كشف خطط تجارية سرية أو كود خاص. بل يسمح لعبارة «مهتم، من دون جدول زمني» بأن تبقى بهذا المعنى، ولا تتحول إلى وعد أثناء انتقالها بين الصفحات.

وضع الميثاق حدوداً سليمة: الاهتمام سبب للمناقشة، والاختبار المستقل دليل آخر. ينبغي أن تحترم قوائم التوافق وعقود الشراء هذه الحدود أيضاً.

المصادر

1. W3C — إقرار الميثاق والدعوة إلى المشاركة
2. W3C — ميثاق Web Performance Working Group المعتمد
3. W3C — الفروق بين المسودة والنص المعتمد
4. W3C — إعلان المراجعة العامة لمسودة الميثاق
5. أرشيف W3C العلني — رد Mozilla
6. W3C — Process Document
7. W3C — منشورات Web Performance Working Group
8. W3C — صفحة Web Performance Working Group
9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption