الخلاصة

  • ينص الميثاق المقترح على أن WebDriver وWebDriver BiDi سيتجهان إلى Candidate Recommendation مع Snapshots، مع تحديث مستمر في تلك المرحلة وعدم التخطيط للانتقال إلى Recommendation.
  • هذا نموذج تشغيل مقترح، لا قرار مكتمل. لا يزال التقريران التقنيان الحاليان Working Drafts، بينما تبقى WebDriver Recommendation الصادرة في 2018 حالة نشر مستقلة.
  • يميز W3C بين Candidate Recommendation Snapshot خضع لمراجعات رسمية وCandidate Recommendation Draft يدمج تغييرات أحدث لم تنل المراجعة الرسمية نفسها. ولا يجوز وصف أي منهما بأنه معيار W3C.
  • يحتاج ادعاء الدعم القابل للتكرار إلى نسخة مواصفة ثابتة، ونوع النضج، وcommit الاختبارات واختيارها، وبنيات المتصفح والمشغل ومكتبة العميل، والمنصة، وتاريخ النتيجة، والاستثناءات المعروفة.

مرحلة مرشحة دائمة هي اختيار حوكمي

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

في 18 أغسطس 2026، دعا W3C لجنته الاستشارية إلى مراجعة ميثاق بديل للمجموعة. تستمر التعليقات العامة حتى 18 سبتمبر، فيما مُدد الميثاق الحالي حتى 23 أكتوبر. الميثاق الجديد إذاً لم يصبح قراراً. لكن أهميته أنه يعلن السياسة التي ستدار بها المواصفات إن اعتُمد.

يقول النص إن المجموعة تنوي نشر أحدث حالة من WebDriver وWebDriver BiDi بوصفها Candidate Recommendation، بما في ذلك Snapshots. ولا تنوي دفع الوثيقتين إلى Recommendation، بل تتوقع مواصلة تحديث Candidate Recommendation بعد الوصول إليها. هذه ليست صياغة عن تأخر مؤقت، بل اختيار لمرحلة نضج وسيطة كي تكون الحالة التشغيلية المستمرة.

يشرح W3C سبب معقولية هذا الاختيار. خبرة التنفيذ تأتي من قواعد شفرية متعددة، لكل منها أولويات وإيقاع إصدار مختلف. يمكن لـSnapshot أن ينشئ نقطة مراجعة، بينما يدمج Candidate Recommendation Draft التحسينات اللاحقة. وهكذا تبقى المواصفة قريبة من التجربة التي تنتجها التطبيقات الحقيقية.

غير أن الاستمرار في Candidate Recommendation ينقل عبئاً إضافياً إلى الاستشهاد. فـRecommendation توفر عادة مرجعاً ثابتاً يحمل اعتماد W3C ودليلاً كافياً على خبرة التنفيذ. أما عندما يكون البقاء في CR مقصوداً، فلا تكفي عبارات مثل «يدعم WebDriver» أو «يطابق WebDriver BiDi» أو حتى «يتوافق مع CR» لتدقيق طويل الأجل أو عقد شراء أو تقرير عطل.

تواريخ الميثاق تكشف حركة السلسلة

يسمي جدول المخرجات في الميثاق المقترح إصدار WebDriver بتاريخ 1 أبريل 2026 وإصدار WebDriver BiDi بتاريخ 19 مارس باعتبارهما أحدث نسختين. لكن صفحات التقارير التقنية الحية كانت قد تحركت عند تاريخ هذه المقالة: أصبح أحدث WebDriver Working Draft بتاريخ 2 يوليو، وأحدث WebDriver BiDi Working Draft بتاريخ 25 أغسطس.

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

يحمل الاسم نفسه أيضاً أكثر من حالة نضج. ما زال W3C يسجل أول مواصفة WebDriver بوصفها Recommendation بتاريخ 5 يونيو 2018، ويسجل التقرير التقني الأحدث بصورة منفصلة كـWorking Draft. لا يرث النص الجديد نضج وثيقة 2018 لمجرد اشتراكهما في الاسم، ولا تصف الوثيقة القديمة تلقائياً كل أمر وسلوك أضيف لاحقاً.

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

Snapshot وDraft ليستا تسميتين متبادلتين

يقسم W3C النشر في Candidate Recommendation إلى شكلين. تحتاج Candidate Recommendation Snapshot إلى طلب انتقال أو تحديث تم التحقق منه، وتعد كذلك Patent Review Draft الذي يبدأ مسار الاستثناءات ذي الصلة. ووفق دليل W3C العلني، تجمع Snapshot توافق المجموعة والمراجعة العامة والمراجعات الرسمية من مجموعات W3C الأخرى والتزامات الترخيص من المشاركين.

أما Candidate Recommendation Draft فتدمج التغييرات المقصودة بعد Snapshot حتى يتمكن المجتمع من قراءة الاتجاه الجاري واختباره. تخفف العملية متطلبات النشر لتظل الوثيقة حديثة. ويقول دليل أنواع الوثائق إن هذه التغييرات لم تحصل بعد على المراجعة الرسمية، وإن Draft لا تحمل بنفسها الحماية البرائية الموصوفة للـSnapshot.

ليست أي منهما معيار W3C. ويحذر W3C صراحة من أن Snapshot قد لا تصبح معياراً أبداً. كما أن الوصول إلى Snapshot لا يشترط بذاته دليلاً كافياً على خبرة التنفيذ. يسجل دليل Living CR أن بعض الخصائص قد تظل متغيرة، أو محدودة الاختبار، أو متفاوتة التوافر، أو ضعيفة التشغيل البيني.

لا يجعل ذلك Snapshot غير موثوقة. بل يحدد بدقة ما تثبته: هدف تنفيذ راجعته المؤسسة ونقطة مراجعة براءات. وتكشف Draft ما أدمج بعد تلك النقطة. أما Recommendation فتضيف اعتماد W3C وعتبة أخرى من أدلة التنفيذ. لا ينبغي لتسمية واحدة أن تستعير خصائص تسمية أخرى من دون سجل.

المطابقة نتيجة ربط عدة سجلات

يوفر الميثاق المقترح أجزاء من انضباط الإثبات. فالتغييرات في Candidate Recommendation والخصائص المنشورة بالفعل ينبغي أن تملك Web Platform Tests. وينبغي للخاصية الجديدة أن تجذب تعبيراً عن الاهتمام من منفذين محتملين اثنين على الأقل. كما يجب توثيق آثار الأمن والخصوصية وإتاحة الاستخدام، وطلب المراجعة الأفقية عند الانتقالات الكبرى، ويفضل قبل أول دخول إلى Candidate Recommendation بثلاثة أشهر على الأقل.

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

لذلك ينبغي أن يحتوي الحد الأدنى لأي ادعاء مهم على:

نسخة مواصفة ثابتة + نوع النضج + commit الاختبارات واختيارها + بنية المتصفح + بنية المشغل + بنية مكتبة العميل + المنصة + تاريخ النتيجة + الاستثناءات المعروفة

إذا كان النص المختبر Candidate Recommendation Draft، فيجب ذكر Snapshot السابقة والتغييرات الجوهرية التي تخضع للاختبار. وإذا كان Snapshot، فيجب ربط قرار الانتقال أو التحديث وحالة مراجعة البراءات. وإذا اتبعت السياسة رابط latest، فعليها تسجيل آلية الحل ووقته والنسخة الثابتة التي أعادها.

هذا السجل ليس نظام اعتماد جديداً. يقرر W3C حالة النشر، وتقرر المجموعة نص المواصفة، ويحافظ مساهمو WPT على الاختبارات، ويقرر مطورو المتصفحات والمشغلات والعملاء ما يشحنونه. يستطيع المشغل أو المشتري حفظ نقطة التقاء هذه السجلات من دون الاستيلاء على سلطة أي طرف.

المقصود ليس فرض Recommendation

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

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

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

ما يبقى غير محسوم

قد تعتمد اللجنة الاستشارية الميثاق، أو تطلب تغييرات، أو ترفضه. وقد تتغير فقرة Living CR قبل القرار النهائي. ولم يصل WebDriver ولا WebDriver BiDi بعد إلى Candidate Recommendation التي يصفها المشروع، كما لا يقدم النص موعداً لأول انتقال.

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

الخلاصة المحدودة هي أن هوية النسخة تصبح جزءاً من منتج الحوكمة عندما تكون Candidate Recommendation هي الوجهة المستمرة. اسم السلسلة يخبرنا أين ينتمي العمل، لا ماذا كان يعمل.

المصادر

  1. إعلان W3C عن ميثاق Browser Testing and Tools المقترح
  2. ميثاق Browser Testing and Tools Working Group المقترح
  3. ميثاق Browser Testing and Tools Working Group الحالي
  4. وثيقة W3C Process
  5. اعتبارات المرحلة النهائية لنضج المخرجات
  6. أنواع الوثائق التي ينشرها W3C
  7. أحدث تقرير تقني لـWebDriver
  8. سجل نشر WebDriver
  9. أحدث تقرير تقني لـWebDriver BiDi
  10. سجل نشر WebDriver BiDi
  11. نتائج Web Platform Tests لـWebDriver BiDi
  12. شجرة اختبارات WebDriver BiDi في WPT