‏المانِ HTMLِ usermedia برای دوربین و میکروفون

به گفتهٔ مقاله، بعد از عرضهٔ المانِ تو کروم ۱۴۴، حالا کنترلِ کاربردیِ بعدی تو مجموعهٔ Capability Elementsه و از کروم ۱۵۱ در دسترسه. این المان مرحلهٔ بعدیِ گذار از promptهای عمومیِ اجازه به سمتِ کنترل‌های هدفمند و کاربردی برای دسترسی به استریمِ دوربین و میکروفونه. با فاصله گرفتن از promptهایی که با اسکریپت تریگر می‌شن و رفتن به سمتِ یه تجربهٔ declarative و فعال‌شده توسط کاربر، این المان boilerplate رو کم می‌کنه، امنیت رو بهتر می‌کنه و برای کسایی که قبلاً دسترسی رو رد کردن یه مسیرِ بازیابیِ روون فراهم می‌کنه.

نویسنده توضیح می‌ده که برخلاف پیشنهادِ عمومی‌ترِ اولیه ( از ابتکارِ PEPC) که بیشتر روی مدیریتِ وضعیتِ اجازه (allow در برابر deny) تمرکز داشت، این Capability Elementها مثلِ «واسطهٔ داده» عمل می‌کنن. کلِ جریانِ دسترسی رو مدیریت می‌کنه: نیتِ کاربر رو ثبت می‌کنه، promptِ مرورگر رو مدیریت می‌کنه و در نهایت آبجکتِ MediaStream رو به اپلیکیشن تحویل می‌ده. این‌جوری نیازی به فراخوانیِ جدای getUserMedia() نیست.

طبق مقاله، دادهٔ واقعیِ Origin Trial نشون داده که این کنترل‌های درون‌بافتار و کاربر-آغاز، نرخ موفقیت رو محسوس بالا می‌برن: سیسکو دیده کاربرهایی که اول دسترسی رو رد کرده بودن، با promptهای قدیمی فقط حدود ۱۰٪ احتمال داشت بعداً اجازه بدن، ولی با المانِ جدید این رقم به بیش از ۶۵٪ پرید؛ Zoom از ۴۶.۹٪ کاهشِ خطاهای گرفتنِ دوربین/میکروفون خبر داده؛ و Google Meet ۱۷٪ کاهش تو بازخوردِ «میکروفون کار نمی‌کنه» و ۱۳۱٪ افزایش تو بازیابیِ موفقِ دسترسی برای کسایی که اول رد کرده بودن دیده.

مشکلی که حل می‌شه اینه که درخواست‌های رسانه به فراخوانی‌های imperativeِ جاوااسکریپت وابسته‌ان که اغلب prompt رو خارج از بافتار نشون می‌دن، و اگه اشتباهی سایتِ خودتو block کنی، برگردوندنِ اون تصمیم نیازمندِ فرو رفتن تو اعماقِ تنظیمات مرورگره؛ همون «حفرهٔ دسترسی» که خیلی وقت‌ها به رها شدنِ قابلیت منجر می‌شه. این المان با سه چیز حلش می‌کنه: نیت و زمان‌بندیِ روشن (prompt فقط بعد از یه تپِ فیزیکی روی یه المانِ کنترل‌شده توسط مرورگر ظاهر می‌شه)، بازیابیِ ساده (با تپ کردن، یه جریانِ بازیابیِ ویژه فعال می‌شه و همون‌جا رو صفحه دوربین/میکروفون رو دوباره روشن می‌کنی)، و دسترسیِ مستقیم به استریم که boilerplate رو کم می‌کنه.

پیاده‌سازی‌اش خیلی boilerplateِ کمتری از API قدیمی می‌خواد. تگِ رو تو HTML می‌ذاری و با متدِ setConstraints() نیازهای سخت‌افزار رو تنظیم می‌کنی:

<usermedia id="media-ctrl">
  <button>Enable camera and microphone</button>
</usermedia>

و بعد تو جاوااسکریپت محدودیت‌ها رو تعیین و به رویدادِ stream گوش می‌دی:

const el = document.getElementById('media-ctrl');
el.setConstraints({
  video: { width: 1280, height: 720 },
  audio: { echoCancellation: true }
});
el.addEventListener('stream', () => { /* از el.stream استفاده کن */ });

نویسنده برای پشتیبانی‌سنجی هم می‌گه با 'HTMLUserMediaElement' in window می‌شه وجودِ این المان رو تشخیص داد و اگه نبود، به getUserMedia() قدیمی fallback کرد. برای کسایی که تو Origin Trial از المانِ عمومیِ استفاده کردن هم مهاجرت ساده‌ست: تگ رو به عوض کن و چک‌ها رو از HTMLPermissionElement به HTMLUserMediaElement ببر. نویسنده در آخر می‌گه نقشهٔ راهِ آینده المان‌های اختصاصی‌ترِ (فقط ویدیو) و (فقط صدا) رو هم شامل می‌شه.

نکات کلیدی:

• از کروم ۱۵۱ کلِ جریانِ دسترسی به دوربین و میکروفون رو declarative مدیریت می‌کنه
• prompt فقط بعد از تپِ فیزیکی روی خودِ المان ظاهر می‌شه؛ یه سیگنالِ مطمئن از نیتِ کاربر
• «حفرهٔ دسترسی» رو با یه مسیرِ بازیابیِ درون‌صفحه‌ای حل می‌کنه، بدون رفتن تو تنظیمات
• دادهٔ Origin Trial: Meet ۱۳۱٪ افزایشِ بازیابیِ دسترسی، Zoom ۴۶.۹٪ کاهشِ خطای گرفتنِ رسانه
• تنظیم با setConstraints() و گوش دادن به رویدادِ stream؛ fallback به getUserMedia با پشتیبانی‌سنجی