۱۰ اشتباه برتر هوش مصنوعی در توسعه وب

Philip Walton

تاریخ انتشار: ۱۱ نوامبر ۲۰۲۶

این هفته، نسخه ۱.۰ «راهنمای وب نوین» را منتشر کردیم که مجموعه‌ای از مهارت‌ها است که تخصص پلاتفرم وب، روال‌های مطلوب، و داده‌های سازگاری مرورگر را مستقیماً در عامل‌های کدنویسی شما جاسازی می‌کند. هدف ما از «راهنمای وب نوین» این است که به توسعه‌دهندگانی که از عامل‌های کدنویسی هوش مصنوعی استفاده می‌کنند کمک کنیم تا از قدرت و قابلیت‌های پلاتفرم وب نوین به‌طور کامل بهره‌مند شوند و درنهایت تجربه وب را برای کاربران بهبود بخشند.

از زمانی که برای اولین‌بار نسخه پیش‌نمای اولیه «راهنمای وب نوین» را در ماه مه معرفی کردیم، عامل‌های کدنویسی بهتر و بهتر شده‌اند و مدل‌های مرزشکن جدید و شگفت‌انگیز بسیاری منتشر شده‌اند. یکی از پرسش‌هایی که اغلب می‌شنویم این است: آیا این مدل‌های مرزشکن جدید از قبل از روال‌های مطلوب توسعه وب پیروی نمی‌کنند؟

متأسفانه پاسخ «نه» است—و ما می‌دانیم که پاسخ «نه» است چون آن را آزمایش می‌کنیم.

هر راهنما در «راهنمای وب نوین» مجموعه‌ای از انتظارات را تعریف می‌کند که اگر روال‌های مطلوب در راهنما به‌درستی دنبال شده باشند، باید درست باشند. سپس مجموعه ارزیابی ما این راهنماها را با دادن پیام‌واره یکسان به عاملی که «راهنمای وب نوین» روی آن نصب شده است (عامل راهنمایی‌شده) و عامل دیگری که «راهنمای وب نوین» روی آن نصب نشده است (عامل راهنمایی‌نشده) آزمایش می‌کند. خروجی هر دو اجرا با انتظارات تعریف‌شده در راهنما مقایسه می‌شود.

وقتی نرخ‌های قبولی هدایت‌شده و هدایت‌نشده را مقایسه می‌کنید، می‌بینید که مدل‌های هوش مصنوعی (حتی جدیدترین مدل‌های مرزشکن) به‌تنهایی از بهترین روش‌های توسعه وب مدرن به‌طور قابل‌اعتماد پیروی نمی‌کنند.

به‌طور میانگین، عامل‌های کدنویسی بدون راهنما فقط حدود ۵۰٪ از بررسی‌ها را در مجموعه ارزیابی ما می‌گذرانند، درحالی‌که وقتی از «راهنمای وب نوین» استفاده می‌شود، این میزان به حدود ۹۰٪ می‌رسد.

می‌توانید داشبورد ارزیابی ما را بررسی کنید تا فهرست کامل بررسی‌های خاصی را که برای هر راهنما اجرا می‌کنیم و نحوه امتیازدهی هر مدل به آن‌ها را ببینید.

اما برای یک نمای کلی سطح بالا، این پست ۱۰ مورد از مشکل‌سازترین حوزه‌هایی را پوشش می‌دهد که می‌بینیم مدل‌های هوش مصنوعی به‌طور مداوم در رشته‌های کلیدی که توسعه‌دهندگان وب به‌احتمال زیاد در کار روزانه خود با آن‌ها مواجه می‌شوند، مانند دسترس‌پذیری، تجربه کاربری، عملکرد، و امنیت، اشتباه می‌کنند.

۱. دسترس‌پذیری: مدیریت کردن ناحیه تمرکز صفحه‌کلید و inert

برای افرادی که با صفحه‌کلید یا صفحه‌خوان پیمایش می‌کنند، ترتیب تمرکز قابل‌پیش‌بینی چیزی است که واسط‌های کاربر تعاملی را قابل‌استفاده می‌کند. بدون آن، فوکوس ممکن است به محتوای پنهان پس‌زمینه منتقل شود یا در ده‌ها توقف زبانه اضافی گیر کند.

مدیریت تمرکز و inert یکی از بزرگ‌ترین شکاف‌های دسترس‌پذیری در ارزیابی‌های ما است و یکی از حوزه‌هایی است که با «راهنمای وب نوین» بیشترین بهبود را داشته است. رایج‌ترین اشتباهات عبارت‌اند از:

• عدم انتقال تمرکز به نماهای تازه بازشده و فراموش کردن بازیابی تمرکز به عنصر راه‌انداز هنگام پیمایش به عقب.
• تکیه بر تله‌های برگه جاوا اسکریپت دستی و aria-modal="true" در مدال‌های سفارشی، به‌جای استفاده از مدال <dialog> یا علامت‌گذاری محتوای پس‌زمینه inert.
• نمایش هر مورد در نوارابزار یا شبکه جهت‌دار به‌عنوان یک توقف زبانه جداگانه به‌جای استفاده از یک توقف زبانه با tabindex متحرک.
• ایجاد طرح‌های کلی :focus-visible سفارشی که نسبت کنتراست ۳:۱ با پس‌زمینه‌های مجاور ندارند.

۲. دسترس‌پذیری: پشتیبانی از کاهش حرکت

حرکت غیرمنتظره صفحه و پویانمایی‌های بزرگ‌مقیاس نه‌تنها حواس را پرت می‌کنند، بلکه برای کاربران مبتلا به اختلالات دهلیزی یا حساسیت حرکتی می‌توانند باعث سرگیجه، حالت تهوع، یا سردرد شوند.

مدل‌های هوش مصنوعی معمولاً به‌خاطر می‌آورند که هنگام افزودن انتقال‌های CSS استاندارد یا پویانمایی‌های قاب کلیدی، prefers-reduced-motion را بررسی کنند. بااین‌حال، هنگام استفاده از ویژگی‌های جدیدتر مانند پیمایش روان، گذرهای نما، یا پویانمایی‌های پیمایش‌محور، اغلب کاهش حرکت را فراموش می‌کنند یا در اجرای آن اشتباه می‌کنند:

• تنظیم scroll-behavior:smooth به‌صورت سراسری و بدون شرط در عنصر ریشه.
• استفاده از پویانمایی‌های CSS پیمایش‌محور بدون بررسی کاهش حرکت.
• برداشتن مدت‌زمان transition در موارد گردونه برای فعال کردن کاهش حرکت درطول پیمایش، اما فراموش کردن برداشتن ویژگی‌های تبدیل، که باعث می‌شود اندازه موارد درطول پیمایش تغییر کند.
• Applying a blanket 0.01ms duration reset on *, *::before, and *::after when reduced motion is active, wiping out all essential non-motion transitions as well (needed to communicate UI state changes).
• فعال کردن انتقال‌های نمای بین‌سندی بدون قیدوشرط و لغو کردن پویانمایی‌های ::view-transition-* وقتی کاهش حرکت فعال است، به‌جای اینکه فقط قانون @view-transition را پشت بررسی کاهش حرکت قرار دهد.

۳. دسترس‌پذیری: اعتبارسنجی فرم، راهنمایی‌های قالب، و وضعیت‌های تکمیل خودکار

فرم‌ها سنگ بنای اکثر مسیرهای قطعی کاربر در وب هستند. یک مشکل جزئی در فرم تسویه‌حساب می‌تواند تأثیر عمده‌ای بر سود خالص کسب‌وکار داشته باشد.

هنگام ساختن فرم‌ها، مدل‌های هوش مصنوعی بسیاری‌از اصول اولیه را به‌درستی انجام می‌دهند. بااین‌حال، آن‌ها اغلب در جزئیات کوچک اما مهم، مانند خطاهای اعتبارسنجی، قرار دادن مناسب جای‌بان‌ها و راهنمایی‌های قالب، و ادغام صحیح با مدیران گذرواژه و ویژگی‌های تکمیل خودکار، شکست می‌خورند:

• پیاده‌سازی مجدد اعتبارسنجی CSS :user-invalid با جاوا اسکریپت blur سفارشی، که اغلب فیلدهای required دست‌نخورده را به‌محض اینکه کاربران از آن‌ها عبور می‌کنند پرچم‌گذاری می‌کند.
• Letting aria-invalid fall out of sync with visible errors, either setting aria-invalid="true" prematurely on blur, or styling :user-invalid in CSS without syncing aria-invalid in JavaScript.
• تکیه بر نوشتار محوشونده placeholder برای نشان دادن قالب‌های الزامی (مثل MM/YY در ورودی تاریخ انقضای کارت) به‌جای ارائه راهنمایی دائمی پیوندشده با aria-describedby.
• قرار دادن راهنمایی‌های قالب و قوانین گذرواژه در زیر <input> (به‌جای بالای آن) که ممکن است درست زمانی که کاربر نیاز به خواندن آن‌ها دارد، توسط صفحه‌کلیدهای تلفن همراه و پنجره‌های تکمیل خودکار پنهان شوند.
• برجسته کردن ورودی‌های :autofill فقط با تغییر رنگ حاشیه به‌جای جفت کردن رنگ با یک نشانه غیررنگی که چیدمان را تغییر نمی‌دهد (مانند box-shadow داخلی).

۴. تجربه کاربری: اشاره‌های تند کشیدن و لمس کردن

عوامل در پیاده‌سازی اشاره‌های لمسی بااستفاده از جاوا اسکریپت امری و نوشتن منطق فیزیک سفارشی خودشان مهارت دارند. این پیاده‌سازی‌ها کار می‌کنند؛ بااین‌حال، تعامل‌های لمسی مبتنی بر جاوا اسکریپت به‌ندرت به همان روانی‌ای هستند که کاربران از همتایان برنامه به زبان اصلی دستگاه انتظار دارند.

بسیاری از این تعامل‌ها را می‌توان با CSS و میاناهای برنامه‌سازی کاربردی پیمایش بومی پیاده‌سازی کرد، که به مرورگر اجازه می‌دهد فیزیک اشاره را خارج از رشته اصلی اجرا کند. بااین‌حال، در ارزیابی‌های ما، مدل‌های هوش مصنوعی اغلب این ویژگی‌ها را نادیده می‌گیرند:

• Implementing swipe-to-dismiss or swipe-to-reveal gestures with pointermove or touchmove listeners instead of using CSS Scroll Snap.
• حذف overscroll-behavior-x:none در رابط‌های تند کشیدن برگه، که می‌تواند به‌طور تصادفی باعث فعال شدن پیمایش عقب یا جلو مرورگر درطول تند کشیدن بیش‌ازحد شود.
• Driving swipe progress effects on the main thread in JavaScript callbacks instead of using scroll-driven animations.
• عدم پشتیبانی مناسب از تمرکز صفحه‌کلید در پانل‌های کنش تند کشیدن مبتنی بر پیمایش.

۵. تجربه کاربری: کادرهای گفتگو، پاپ‌اورها، و انتقال‌های لایه بالایی

در ارزیابی‌های ما، مدل‌ها اغلب هنگام پویانمایی، رد کردن، یا دربرگرفتن پیمایش در اطراف کادرهای گفتگوی مدال و پنجره‌های بالاپر، به راه‌حل‌های جاوا اسکریپت امری متوسل می‌شوند.

به‌جای تکیه بر ویژگی‌های مدرن HTML و CSS که برای هم‌پوشانی‌های لایه بالایی ساخته شده‌اند، عامل‌ها اغلب ماشین‌های حالت ورود و خروج، قلاب‌های سابقه، و قفل‌های پیمایش بدنه را به‌صورت دستی می‌سازند که نگهداری آن‌ها دشوارتر است و مستعد اشکالات جزئی در واسط کاربر هستند.

وقتی این تعاملات را به‌درستی انجام دهید، می‌توانید تجربه‌ای را که احساس شکنندگی دارد به تجربه‌ای صیقلی تبدیل کنید که کاربران به آن اعتماد دارند. در اینجا رایج‌ترین اشتباهاتی که می‌بینیم آورده شده است:

• ساختن هم‌پوشانی‌های سفارشی position:fixed با کنترل‌کننده‌های دستی کلیک کردن در خارج برای رد کردن آسان، به‌جای استفاده از popover.
• ایجاد پویانمایی‌های ورودی و خروجی با جابه‌جایی کلاس‌های انتقال CSS و هماهنگی با شنوندگان requestAnimationFrame() و transitionend (با بازگشت‌های setTimeout())، به‌جای انجام آن در CSS خالص با @starting-style و transition-behavior.
• قفل کردن پیمایش صفحه در پشت یک مدال باز با تنظیم overflow:hidden روی <html> به‌جای استفاده از عنصر <dialog> برای مهار کردن پیمایش بیش‌ازحد.
• افزودن شنوندگان popstate برای تشخیص اشاره‌های برگشتن Android و بستن مدال‌های باز، به‌جای استفاده از عملکرد بستن دکمه برگشتن بومی عنصر مدال <dialog>.

‫۶. تجربه کاربری: حالت تاریک و کنترل‌های سازگار با زمینه

کاربران حالت تاریک را برای کاهش خستگی چشم و تابش خیره‌کننده فعال می‌کنند، بنابراین یک فلاش سفید روشن در بارگذاری صفحه، کنترل‌های فرم بدون زمینه، یا کلیدی که با اولویت سیستم‌عامل آن‌ها همگام‌سازی نمی‌شود، بلافاصله تجربه را تضعیف می‌کند.

کلید روشن/خاموش حالت تیره ممکن است ساده به‌نظر برسد، اما مدل‌های بدون راهنما در ارزیابی‌های ما به‌طور مداوم جزئیات کلیدی پلاتفرم را که برای درست انجام دادن تعویض زمینه و کنترل‌های فرم بومی لازم است ازدست می‌دهند:

• <meta name="color-scheme" content="light dark"> در <head> وجود ندارد، که باعث می‌شود کاربران حالت تاریک هنگام بار شدن برگه سبک نگارش خارجی، فلاش بوم سفید را ببینند.
• سبک‌بندی زمینه‌های تیره یا مؤلفه‌های با سطح تیره با رنگ‌های سفارشی بدون تنظیم color-scheme، که باعث می‌شود نوارهای پیمایش و کنترل‌های فرم بومی در حالت روشن گیر کنند.
• نادیده گرفتن تابع CSS light-dark() هنگام تعریف کردن نشان‌های رنگی سازگار با زمینه که به‌طور خودکار از color-scheme فعال پیروی می‌کنند.
• فقط یک کلید روشن/خاموش دودویی روشن یا تیره ارائه می‌دهد که لغو صریحی را در localStorage تنظیم می‌کند و گزینه‌ای برای بازگشت به پیش‌فرض سیستم‌عامل ندارد.
• فراموش کردن افزودن شنونده رویداد storage، که باعث می‌شود وقتی کاربر زمینه‌ها را تغییر می‌دهد، سایر برگه‌های باز همگام‌سازی نشوند.

‫۷. عملکرد: پاسخ‌گویی و روان بودن زمان اجرا

کاربران بیشتر وقت خود را پس‌از اتمام بار شدن صفحه وب در آن می‌گذرانند، بنابراین تعاملات کُند و انتقال‌های نامنظم می‌تواند به همان اندازه بار شدن اولیه کُند به تجربه کاربری آسیب برساند.

در ارزیابی‌های ما، مدل‌ها معمولاً از روال‌های مطلوب کلاسیک زمان بارگیری پیروی می‌کنند که سال‌ها است در ابزارهایی مانند 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).

‫۸. عملکرد: تغییرات چیدمان و لرزش بصری

تغییرات غیرمنتظره چیدمان تمرکز خواننده را برهم می‌زند و می‌تواند باعث شود کاربران روی دکمه‌های غیرمنتظره کلیک کنند—گاهی با پیامدهای غیرقابل‌برگشت!

مدل‌ها به‌طور قابل‌اعتمادی ویژگی‌های width و height را به عناصر استاندارد <img> اضافه می‌کنند تا از تغییر چیدمان جلوگیری کنند، اما به‌طور مداوم سایر منابع رایج تغییر چیدمان و چشمک‌های پیش‌از رنگ‌آمیزی از عناصر <video>، تعویض قلم وب، نوارهای ابزار مرورگر تلفن همراه، و آزمایش‌های سمت کارخواه را ازدست می‌دهند—همه این موارد می‌توانند بر CLS تأثیر بگذارند.

• حذف کردن مشخصه‌های صریح width و height در عناصر <video> (به‌طوری که پخش‌کننده‌های بارنشده به‌طور پیش‌فرض روی 300×150 تنظیم می‌شوند و پس‌از بار شدن فراداده، چیدمان را تغییر می‌دهند)، یا سبک‌بندی عناصر پوشاننده رسانه به‌جای تنظیم کردن مستقیم aspect-ratio و object-fit در عناصر رسانه.
• جفت کردن قلم‌های وب با قلم‌های جایگزین سیستم بدون font-size-adjust، که باعث می‌شود پاراگراف‌ها و عنوان‌ها هنگام جابه‌جایی قلم‌های وب به‌طور قابل‌مشاهده‌ای بازچینی شوند.
• اندازه بخش‌های اصلی و چیدمان‌های تمام‌صفحه با واحدهای ثابت vh به‌جای واحدهای نمای پویای کوچک (dvh، svh) که باعث می‌شود محتوا با گسترش و جمع شدن نوارهای ابزار مرورگر تلفن همراه جابه‌جا شود.
• پنهان کردن محتوا با قطعه‌های ضدلرزش قدیمی opacity:0 یا visibility:hidden و زمان‌های اتمام چندثانیه‌ای برای آزمایش‌های A/B سمت کارخواه (به‌تأخیر انداختن LCP و قابل‌کلیک گذاشتن عناصر نامرئی)، به‌جای استفاده از اسکریپت‌های دارای blocking="render" درصورت دردسترس بودن.
• راه‌اندازی گذارهای نمای بین‌سندی قبل‌از تجزیه نشان‌گذاری مهم بالای صفحه به‌جای نگه‌داشتن اولین پردازش با rel="expect" و blocking="render"، که باعث می‌شود عناصر نیمه‌تجزیه‌شده در اواسط گذار ظاهر شوند.

‫۹. امنیت: دفاع‌های DOM XSS و پاک‌سازی HTML

یک نقص اسکریپت‌نویسی بین‌سایتی (XSS) به مهاجم اجازه می‌دهد کد دلخواه را در مرورگرهای کاربران شما اجرا کند، داده‌های جلسه را بدزدد، یا ازطرف آن‌ها اقداماتی انجام دهد. به‌همین دلیل است که دفاع‌های اعمال‌شده توسط مرورگر مانند پاک‌سازی ایمن HTML، «انواع مطمئن»، و CSPهای سخت‌گیرانه بسیار مهم هستند.

مدل‌ها به‌ندرت این نگرانی‌های امنیتی را به‌طور پیش‌کنشی برطرف می‌کنند. برای مثال، در تمام تکالیف مجموعه ارزیابی کامل ما، مدل‌ها بدون درخواست صریح، «خط‌مشی امنیتی محتوا» (CSP) یا سرصفحه جداسازی میان‌مبدئی اضافه نکردند.

حتی وقتی پیام‌واره‌ها مستقیماً امنیت را درخواست می‌کنند، مدل‌های بدون راهنما همچنان در بیش‌از نیمی از بررسی‌های امنیتی ما ناموفق هستند و به جایگزین‌های سفارشی شکننده یا خط‌مشی‌های ناقص روی می‌آورند. این موضوع هنگام دفاع دربرابر DOM XSS به‌وضوح نشان داده می‌شود:

• نوشتن پاک‌کننده‌های فهرست مجاز DOMParser دست‌ساز—به‌عنوان setHTML() بازگشت یا داخل خط‌مشی «انواع مطمئن»—به‌جای استفاده از کتابخانه بررسی‌شده‌ای مثل DOMPurify وقتی پاک‌سازی بومی دردسترس نیست.
• Eagerly bundling DOMPurify on every page load instead of using native setHTML() when supported and lazy-loading DOMPurify only as a fallback.
• ثبت خط‌مشی‌های «انواع مطمئن» گذری (input) => input مجاز که اجرای سینک را تضعیف می‌کند.
• جفت کردن «انواع مطمئن» در صفحه‌های ایستا با script-src 'self' CSPهای فهرست مجاز میزبان به‌جای قفل کردن اسکریپت‌های درون‌خطی با درهم‌سازهای SHA-256.
• حذف 'strict-dynamic' و 'report-sample' هنگام پیکربندی «خط‌مشی‌های امنیتی محتوای» script-src مبتنی بر عدد یک‌بارمصرف.

‫۱۰. امنیت: ورود به سیستم با گذرکلید، اصالت‌سنجی مجدد، و چرخه حیات اطلاعات کاربری

گذرکلیدها امنیت کاربران و تبدیل‌های ورود به سیستم را برای کسب‌وکارها بهبود می‌بخشند، اما پیاده‌سازی آن‌ها (حتی با کمک عوامل) چالش‌برانگیز است.

WebAuthn دارای میاناهای برنامه‌سازی کاربردی خاصی برای سریال‌سازی، تشخیص قابلیت، و سیگنال‌دهی است که مدل‌های بدون راهنما تقریباً به‌طور کامل در ارزیابی‌های ما از دست می‌دهند. اگر از مدل هوش مصنوعی بخواهید که ورود به سیستم با گذرکلید، مدیریت، یا بازدرستی‌سنجی گام‌به‌گام را اضافه کند، اغلب کمک‌کننده‌های کدگذاری بایت دستی می‌نویسد، بررسی‌های قابلیت را در میانای کاربر مدیریت رد می‌کند، یا اعتبارنامه‌ها را با مدیران گذرواژه همگام‌سازی نمی‌کند:

• کمک‌کننده‌های تبدیل Base64URL atob() و btoa() را به‌صورت دستی پیاده‌سازی می‌کنند—چه به‌عنوان مسیر اصلی و چه به‌عنوان کد تکراری پشتیبان—به‌جای اینکه به روش‌های سریال‌سازی داخلی مانند parseCreationOptionsFromJSON()، parseRequestOptionsFromJSON()، و credential.toJSON() تکیه کنند.
• حذف PublicKeyCredential.signalUnknownCredential() درطول ورود به سیستم وقتی سرور شناسه اطلاعات اعتباری ناشناخته‌ای را گزارش می‌کند، که باعث می‌شود گذرکلیدهای حذف‌شده یا لغوشده در مدیر گذرواژه کاربران باقی بماند.
• درحال رد شدن از PublicKeyCredential.getClientCapabilities() قبل‌از پرداز کردن میانای کاربری مدیریت و ایجاد گذرکلید.
• حذف AbortController و AbortSignal هنگام شروع درخواست‌های بازدرستی‌سنجی گذرکلید ارتقایی.
• ارسال گزینه mediation:"immediate" آزمایش معرفی ویژگی جدید به‌جای uiMode:"immediate" برای پیام‌واره‌های ورود به سیستم ساده‌شده.

این شکاف‌ها را پر کنید

این ۱۰ حوزه فقط نمونه‌ای از فهرست کامل هستند و انتظار داریم که شکاف‌های دانش خاص درطول زمان تغییر کنند. مدل‌ها به سطح مطلوب خواهند رسید و پلاتفرم وب به تکامل خود ادامه خواهد داد.

خبر خوب این است که راهنمای وب نوین به همه این کاستی‌ها می‌پردازد و همگام با پلاتفرم به تکامل خود ادامه خواهد داد.

برای شروع کار با «راهنمای وب نوین»، فرمان زیر را اجرا کنید یا آن را در بازار افزونه‌های نماینده‌تان جستجو کنید:

npx modern-web-guidance@latest install

آیا دیده‌اید که مدل‌ها در انجام سایر کارهای توسعه وب اشتباه کنند؟ می‌خواهیم درباره آن بشنویم. در مخزن GitHub «راهنمای وب نوین» مشکلی را باز کنید یا با مشارکت در پروژه به ما کمک کنید این شکاف‌ها را برای توسعه‌دهندگان دیگر برطرف کنیم.