أهم 10 أخطاء يرتكبها الذكاء الاصطناعي في تطوير الويب

Philip Walton

تاريخ النشر: 11 نوفمبر 2026

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

منذ أن طرحنا لأول مرة النسخة المبكرة الحصرية من "إرشادات الويب الحديث" في مايو الماضي، تحسّنت برامج الترميز الآلية بشكل كبير، وتم إصدار العديد من النماذج الرائدة الجديدة والمذهلة. من الأسئلة التي نتلقّاها كثيرًا: ألا تتّبع هذه النماذج الرائدة الجديدة أفضل الممارسات في مجال تطوير الويب؟

للأسف، الإجابة هي "لا"، ونحن نعرف أنّ الإجابة هي "لا" لأنّنا نختبر ذلك.

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

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

في المتوسط، لا يتجاوز وكلاء الترميز غير الموجَّهين سوى %50 تقريبًا من عمليات التحقّق في مجموعة التقييم، مقارنةً بنحو %90 عند استخدام ميزة "إرشادات الويب الحديث".

يمكنك الاطّلاع على لوحة بيانات التقييم لمعرفة القائمة الكاملة لعمليات التحقّق المحدّدة التي نُجريها لكل دليل، وكيفية تقييم كل نموذج بناءً عليها.

لتقديم نظرة عامة شاملة، يتناول هذا المنشور 10 من أبرز المشاكل التي نلاحظ أنّ نماذج الذكاء الاصطناعي تخطئ فيها باستمرار، وذلك في مجالات رئيسية من المرجّح أن يواجهها مطوّرو تطبيقات الويب في عملهم اليومي، مثل تسهيل الاستخدام وتجربة المستخدم والأداء والأمان.

1. أدوات تسهيل الاستخدام: التركيز على لوحة المفاتيح وإدارة inert

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

يُعدّ التركيز وإدارة inert من أكبر الثغرات في أدوات تسهيل الاستخدام في تقييماتنا، ومن أكثر المجالات التي تتحسّن من خلال "إرشادات الويب الحديث". تشمل الأخطاء الأكثر شيوعًا ما يلي:

• عدم نقل التركيز إلى طرق العرض المفتوحة حديثًا ونسيان استعادة التركيز إلى العنصر الذي تم تشغيله عند الرجوع إلى الخلف.
• الاعتماد على فخاخ علامات التبويب اليدوية في JavaScript وaria-modal="true" في النوافذ المشروطة المخصّصة، بدلاً من استخدام نافذة مشروطة <dialog> أو وضع علامة على محتوى الخلفية inert
• عرض كل عنصر في شريط أدوات أو شبكة اتجاهية كعلامة تبويب منفصلة بدلاً من استخدام علامة تبويب واحدة مع tabindex متغيّر
• إنشاء حدود مخصّصة لـ :focus-visible لا تتوفّر فيها نسبة تباين تبلغ 3:1 مقارنةً بالخلفيات المجاورة

2. أدوات تسهيل الاستخدام: إتاحة ميزة "الحدّ من الحركة"

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

تتذكّر نماذج الذكاء الاصطناعي عادةً التحقّق من prefers-reduced-motion عند إضافة انتقالات CSS عادية أو صور متحركة للإطارات الرئيسية. ومع ذلك، عند استخدام ميزات أحدث، مثل الانتقال السلس أو انتقالات العرض أو الصور المتحركة المستندة إلى الانتقال، غالبًا ما ينسى المطوّرون ميزة "تقليل الحركة" أو يرتكبون أخطاءً عند تنفيذها:

• ضبط scroll-behavior:smooth بشكل عام وبدون شروط على عنصر الجذر
• يتم استخدام صور متحركة في CSS مستندة إلى الانتقال بدون التحقّق من إعدادات تقليل الحركة.
• إزالة مُدد transition في عناصر لوحة العرض الدوّارة لتقليل الحركة أثناء الانتقال، ولكن نسيان إزالة سمات التحويل أيضًا، ما يؤدي إلى تغيُّر حجم العناصر أثناء الانتقال
• تطبيق إعادة ضبط شاملة لمدة 0.01ms على * و*::before و*::after عندما تكون ميزة "تقليل الحركة" مفعَّلة، ما يؤدي إلى محو جميع الانتقالات الأساسية غير المتحركة أيضًا (اللازمة لإبلاغ المستخدم بتغييرات حالة واجهة المستخدم).
• تفعيل انتقالات العرض في المستندات المتعددة بدون شروط وإلغاء تأثيرات الحركة في ::view-transition-* عندما تكون ميزة "تقليل الحركة" مفعَّلة، بدلاً من حظر قاعدة @view-transition فقط عند تفعيل ميزة "تقليل الحركة".

3- تسهيل الاستخدام: التحقّق من صحة النموذج وتلميحات التنسيق وحالات الملء التلقائي

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

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

• إعادة تنفيذ CSS :user-invalid مع التحقّق من صحة JavaScript blur المخصّصة، والتي غالبًا ما تضع علامة على حقول required التي لم يتم لمسها بمجرد أن يتجاوزها المستخدمون.
• السماح لـ aria-invalid بعدم المزامنة مع الأخطاء المرئية، أو ضبط aria-invalid="true" قبل الأوان على blur، أو تصميم :user-invalid في CSS بدون مزامنة aria-invalid في JavaScript.
• الاعتماد على نص placeholder يختفي لعرض التنسيقات المطلوبة (مثل MM/YY في حقل إدخال تاريخ انتهاء صلاحية البطاقة) بدلاً من عرض تلميح دائم مرتبط بـ aria-describedby
• وضع تلميحات التنسيق وقواعد كلمة المرور أسفل <input> (بدلاً من أعلاه) حيث يمكن حجبها بواسطة لوحات المفاتيح على الأجهزة الجوّالة والنوافذ المنبثقة للملء التلقائي عندما يحتاج المستخدم إلى قراءتها.
• يتم تمييز حقول الإدخال في :autofill من خلال تغيير لون الحدود فقط بدلاً من إقران اللون بإشارة غير لونية لا تغيّر التنسيق (مثل box-shadow الداخلي).

4. تجربة المستخدم: إيماءات التمرير السريع واللمس

يُجيد الوكلاء تنفيذ إيماءات اللمس باستخدام JavaScript الإلزامي وكتابة منطق فيزيائي مخصّص. تعمل عمليات التنفيذ هذه، ولكن نادرًا ما تبدو تفاعلات اللمس المستندة إلى JavaScript سلسة كما يتوقّع المستخدمون من التطبيقات الأصلية.

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

• تنفيذ إيماءات التمرير السريع للإغلاق أو التمرير السريع للكشف باستخدام أدوات الاستماع pointermove أو touchmove بدلاً من استخدام CSS Scroll Snap
• حذف overscroll-behavior-x:none في واجهات التمرير السريع في علامات التبويب، ما قد يؤدي إلى تشغيل التنقّل للخلف أو للأمام في المتصفّح عن طريق الخطأ أثناء التمرير السريع.
• تفعيل تأثيرات تقدّم التمرير السريع في سلسلة التعليمات الرئيسية في عمليات استدعاء JavaScript بدلاً من استخدام الصور المتحركة المستندة إلى الانتقال
• عدم إتاحة تركيز لوحة المفاتيح بشكل صحيح في لوحات إجراء التمرير السريع المستندة إلى التمرير

5- تجربة المستخدم: مربّعات الحوار والعناصر المنبثقة والانتقالات في الطبقة العليا

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

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

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

• إنشاء تراكبات position:fixed مخصّصة باستخدام معالِجات النقر خارج النافذة يدويًا لإغلاقها بسهولة، بدلاً من استخدام popover فقط
• إنشاء صور متحركة للدخول والخروج من خلال تبديل فئات انتقال CSS والتنسيق مع مستمعي requestAnimationFrame() وtransitionend (مع إجراءات احتياطية لـ setTimeout())، بدلاً من إجراء ذلك في CSS خالص باستخدام @starting-style وtransition-behavior.
• قفل تمرير الصفحة خلف نافذة مشروطة مفتوحة من خلال ضبط overflow:hidden على <html> بدلاً من استخدام عنصر <dialog> لاحتواء تجاوز حد التمرير
• إضافة مستمعين من النوع popstate لرصد إيماءات الرجوع في Android وإغلاق النوافذ المشروطة المفتوحة، بدلاً من استخدام وظيفة الإغلاق المضمّنة في زر الرجوع لعنصر <dialog> في النافذة المشروطة.

6. تجربة المستخدم: الوضع الداكن وعناصر التحكّم المتوافقة مع المظهر

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

قد يبدو زرّ تفعيل الوضع الداكن بسيطًا، ولكن النماذج غير الموجَّهة في تقييماتنا تفوتها باستمرار تفاصيل أساسية في المنصة مطلوبة لتبديل المظهر وعناصر التحكّم في النماذج الأصلية بشكل صحيح:

• السمة <meta name="color-scheme" content="light dark"> غير متوفّرة في <head>، ما يؤدي إلى ظهور وميض أبيض على الشاشة لمستخدمي الوضع الداكن أثناء تحميل أوراق الأنماط الخارجية.
• تنسيق المظاهر الداكنة أو المكوّنات ذات الأسطح الداكنة بألوان مخصّصة بدون ضبط السمة color-scheme، ما يؤدي إلى بقاء أشرطة التمرير وعناصر التحكّم في النماذج الأصلية في الوضع الفاتح
• تجاهل دالة CSS light-dark() عند تحديد رموز الألوان المتوافقة مع المظهر والتي تتبع تلقائيًا color-scheme النشط.
• توفير مفتاح تبديل ثنائي فقط بين الوضعَين الفاتح والداكن يضبط خيارًا صريحًا للتجاوز في "localStorage" بدون خيار للعودة إلى الوضع التلقائي لنظام التشغيل
• نسيان إضافة متتبِّع أحداث storage، ما يؤدي إلى عدم مزامنة علامات التبويب المفتوحة الأخرى عندما يغيّر المستخدم المظاهر

7. الأداء: سرعة الاستجابة وسلاسة التشغيل

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

في تقييماتنا، تتّبع النماذج بشكل عام أفضل الممارسات الكلاسيكية المتعلّقة بوقت التحميل والتي تم الترويج لها في أدوات مثل Lighthouse لسنوات، وعادةً ما تعرف كيفية نقل العمليات الثقيلة الواضحة إلى Web Worker. أما المشكلة التي يواجهونها باستمرار، فهي استجابة سلسلة التعليمات الرئيسية، وهو أمر ضروري لتحسين مقياس INP: عزل عمل التنسيق، وجدولة المهام حسب الأولوية، والاستفادة من ميزات HTML وCSS الجديدة التي تؤدي عمل العرض خارج سلسلة التعليمات الرئيسية.

على سبيل المثال، نرى غالبًا الوكلاء:

• استخدام قوائم انتظار setTimeout() مخصّصة للمهام التي تعمل في الخلفية أو المهام ذات الأولوية المنخفضة بدلاً من منح الأولوية للمهام التي تظهر للمستخدم باستخدام scheduler.postTask() أو الاستفادة من ميزة متابعة المهام باستخدام scheduler.yield() عندما يتيح المتصفّح ذلك
• إنشاء تنسيقات معقّدة (مثل شبكات البيانات الكثيفة) بدون تطبيق content-visibility:auto وcontain-intrinsic-size، ما يعني أنّ التعديلات بعد تفاعلات المستخدمين تؤدي إلى إعادة تدفق الصفحة بالكامل
• إخفاء طرق عرض SPA غير النشطة باستخدام display:none (أو إزالتها) بدلاً من استخدام content-visibility:hidden (مقترنة بـ inert)، لأنّ الطريقة الأولى تؤدي إلى تدمير حالة العرض المخزّنة مؤقتًا، وبالتالي يؤدي التبديل مرة أخرى إلى تشغيل التنسيق والرسم بالكامل.
• يتم إيقاف صور <canvas> المتحركة خارج الشاشة مؤقتًا، بالإضافة إلى تكرار تشغيل الخلفية باستخدام عمليات استدعاء Intersection Observer بدلاً من إقران content-visibility:auto بحدث contentvisibilityautostatechange (حيثما كان ذلك متاحًا)، ما يؤدي إلى فقدان هامش العرض المُسبَق في المتصفّح قبل انتقال العناصر إلى العرض.
• إنشاء تلميحات لواجهة المستخدم حول إمكانية الانتقال على الصفحة باستخدام متتبِّعات الأحداث scroll التي تفرض إجراء عمليات حسابية مستمرة للتنسيق، بدلاً من استخدام طلبات البحث عن حالة الانتقال على الصفحة في CSS عندما تكون متاحة (مع استخدام Intersection Observer كبديل)

8. الأداء: تغيّرات التصميم والوميض المرئي

تؤدي تغييرات التنسيق غير المتوقعة إلى تشتيت انتباه القارئ، وقد تؤدي إلى نقر المستخدمين على أزرار غير متوقعة، ما قد يؤدي أحيانًا إلى عواقب لا يمكن التراجع عنها.

تضيف النماذج بشكل موثوق السمتَين width وheight إلى عناصر <img> العادية للحماية من تغيّرات التصميم، ولكنّها تفوّت باستمرار مصادر شائعة أخرى لتغيّرات التصميم وومضات ما قبل العرض من عناصر <video> وعمليات تبديل خطوط الويب وأشرطة أدوات متصفّح الأجهزة الجوّالة والتجارب من جهة العميل، وكلّها يمكن أن تؤثر في CLS.

• حذف السمتَين الصريحتَين width وheight في عناصر <video> (بحيث يتم ضبط المشغّلات التي لم يتم تحميلها تلقائيًا على 300×150 وتغيير التنسيق بعد تحميل البيانات الوصفية)، أو تصميم عناصر تضمين الوسائط بدلاً من ضبط السمتَين aspect-ratio وobject-fit مباشرةً في عناصر الوسائط.
• يتم إقران خطوط الويب بخطوط النظام الاحتياطية بدون font-size-adjust، ما يؤدي إلى إعادة تدفق الفقرات والعناوين بشكل مرئي عند تبديل خطوط الويب.
• تحديد حجم أقسام hero وتنسيقات ملء الشاشة باستخدام وحدات vh الثابتة بدلاً من وحدات إطار العرض الديناميكية أو الصغيرة (dvh وsvh)، ما يؤدي إلى انتقال المحتوى مع توسيع أشرطة أدوات متصفّح الأجهزة الجوّالة وتصغيرها
• إخفاء المحتوى باستخدام مقتطفات قديمة من opacity:0 أو visibility:hidden لمنع الوميض ومهلات لعدة ثوانٍ لاختبارات A/B من جهة العميل (تأخير سرعة عرض أكبر محتوى مرئي وترك العناصر غير المرئية قابلة للنقر)، بدلاً من استخدام النصوص البرمجية مع blocking="render" عندما تكون متاحة
• يتم تفعيل انتقالات العرض بين المستندات قبل تحليل الترميز المهم في الجزء المرئي من الصفحة بدلاً من تأخير العرض الأول باستخدام rel="expect" وblocking="render"، ما يؤدي إلى ظهور عناصر تم تحليلها جزئيًا في منتصف عملية الانتقال.

9. الأمان: دفاعات DOM XSS وتنقية HTML

تتيح ثغرة واحدة في البرمجة عبر المواقع (XSS) للمهاجم تشغيل رمز عشوائي في متصفحات المستخدمين، أو سرقة بيانات الجلسة أو اتخاذ إجراءات نيابةً عنهم. لهذا السبب، من المهم جدًا استخدام وسائل الدفاع التي يفرضها المتصفّح، مثل تنقية HTML الآمنة و"الأنواع الموثوق بها" و"سياسات أمان المحتوى" الصارمة.

ونادرًا ما تعالج النماذج هذه المخاوف الأمنية بشكل استباقي. على سبيل المثال، في جميع المهام ضمن مجموعة التقييم الكاملة، لم تُضِف النماذج "سياسة أمان المحتوى" (CSP) أو عنوان "يحظر الوصول من نطاقات آخرى" بدون طلب صريح.

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

• كتابة أدوات تنقية القائمة المسموح بها لـ DOMParser يدويًا، إما كإجراء احتياطي لـ setHTML() أو داخل سياسة "الأنواع الموثوق بها"، بدلاً من استخدام مكتبة تم فحصها مثل DOMPurify عندما لا تكون التنقية الأصلية متاحة
• تجميع DOMPurify بشكل استباقي عند كل تحميل للصفحة بدلاً من استخدام setHTML() الأصلي عندما يكون متاحًا وتحميل DOMPurify بشكل بطيء كحل احتياطي فقط
• تسجيل سياسات Trusted Types المتساهلة التي تسمح بمرور (input) => input والتي تقوّض إجراءات التنفيذ في المتلقّي
• إقران Trusted Types على الصفحات الثابتة مع سياسات أمان المحتوى (CSP) التي تستخدم القائمة المسموح بها للمضيف script-src 'self' بدلاً من حظر النصوص البرمجية المضمّنة باستخدام تجزئات SHA-256
• يتم حذف 'strict-dynamic' و'report-sample' عند ضبط "سياسات أمان المحتوى" في script-src المستندة إلى الرموز غير المتكرّرة.

10. الأمان: تسجيل الدخول باستخدام مفتاح المرور وإعادة المصادقة ودورة حياة بيانات الاعتماد

تعزّز مفاتيح المرور مستوى الأمان للمستخدمين وتزيد من الإحالات الناجحة لتسجيل الدخول في المؤسسات، ولكن تنفيذها (حتى بمساعدة الوكلاء) يمثّل تحديًا.

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

• استخدام أدوات مساعدة مخصّصة لتحويل atob() وbtoa() إلى Base64URL، إما كمسار أساسي أو كرمز احتياطي مكرّر، بدلاً من الاعتماد على طرق التسلسل المضمّنة مثل parseCreationOptionsFromJSON() وparseRequestOptionsFromJSON() وcredential.toJSON()
• تجاهُل PublicKeyCredential.signalUnknownCredential() أثناء تسجيل الدخول عندما يُبلغ الخادم عن معرّف بيانات اعتماد غير معروف، ما يؤدي إلى ترك مفاتيح المرور المحذوفة أو المُلغاة في مدراء كلمات المرور لدى المستخدمين
• سيتم تخطّي PublicKeyCredential.getClientCapabilities() قبل عرض واجهة المستخدم الخاصة بإنشاء مفاتيح المرور وإدارتها.
• تم حذف AbortController وAbortSignal عند بدء طلبات إعادة المصادقة باستخدام مفتاح المرور لتعزيز الأمان.
• تمرير خيار مرحلة التجربة والتقييم mediation:"immediate" بدلاً من uiMode:"immediate" لتبسيط طلبات تسجيل الدخول

سدّ هذه الثغرات

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

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

لبدء استخدام إرشادات الويب الحديث، نفِّذ الأمر التالي أو ابحث عنه في سوق المكوّنات الإضافية للوكيل:

npx modern-web-guidance@latest install

هل لاحظت أنّ النماذج تخطئ في مهام أخرى متعلّقة بتطوير تطبيقات الويب؟ نريد أن نعرف المزيد عنه. يمكنك الإبلاغ عن مشكلة في مستودع GitHub الخاص بـ "إرشادات الويب الحديث" أو مساعدتنا في سدّ هذه الثغرات للمطوّرين الآخرين من خلال المساهمة في المشروع.