پچ پچ زیادی در اطراف ol <details> و <summary> عناصر اخیرا! دیدم لیا ورو اخیراً در توییتی نظری را منتشر کرده است در مورد عنصر display رفتار و آن دسته از افراد به مشاهدات و یادداشت های استفاده بیشتر از مردم، از جمله الف بحث را احیا کرد در مورد اینکه <summary> باید اجازه داده شود که حاوی عناصر تعاملی باشد یا خیر.
نقاط زیادی برای اتصال وجود دارد و من تمام تلاش خود را در اینجا انجام خواهم داد تا دقیقاً این کار را انجام دهم.
آیا می توانیم نمایش عناصر تو در تو را تغییر دهیم <details> عنصر؟
فوق العاده عجیب! اگر DevTools را باز کنیم، شیوه نامه عامل کاربر به ما می گوید <details> به عنوان یک عنصر بلوک نمایش داده می شود.
به موارد مورد نیاز توجه کنید <summary> عنصر و دو اضافی <div>در آنجا است. ما می توانیم نادیده بگیریم display، درست؟
آنچه ما ممکن است انتظار داشته باشیم این است <details> اکنون دارای ارتفاع صریح است 40vh و سه ردیف که ردیف سوم فضای باقی مانده از دو ردیف اول را اشغال می کند. مثل این:
اوه، اما ردیف سوم این کار را نمی کند.
ظاهراً چیزی که ما با آن سروکار داریم یک ظرف شبکه است که قادر به اعمال رفتار شبکه برای موارد شبکه خود نیست. اما مشخصات HTML به ما می گوید:
La
detailsعنصر است انتظار می رود به عنوان یک جعبه بلوک. همچنین انتظار می رود این عنصر دارای یک داخلی باشد درخت سایه با دو جک پات.(تاکید از من است)
و کمی بعد:
La
detailsعنصر دوم شکاف انتظار می رود آن را داشته باشدstyleویژگی تنظیم شده روی "display: block; content-visibility: hidden;" وقتی کهdetailsعنصر یک نداردopenویژگی. زمانی که آن را داردopenصفت،styleانتظار می رود ویژگی از دومی حذف شود شکاف.(تاکید دوباره من است)
بنابراین، مشخصات می گوید اسلات دوم - دو اضافی <div>s از مثال - فقط زمانی مجبور می شوند که عناصر بلوکی باشند <details> بسته است. وقتی باز است - <details open> - آنها باید با صفحه نمایش شبکه ای مطابقت داشته باشند که سبک عامل کاربر را نادیده می گیرد... درست است؟
بحث همین است. گرفتم slots تنظیم شده اند display: contents به صورت پیش فرض، اما به نظر می رسد پارازیت عناصر تو در تو در اسلات ها و از بین بردن قابلیت استایل دادن به آنها کارساز نیست. آیا این یک مشکل مشخصات است که محتویات اسلات هستند یا یک مشکل مرورگر است که ما نمی توانیم آنها را نادیده بگیریم display حتی اگر آنها در درخت جعبه هستند؟ افراد باهوش تر می توانند من را روشن کنند، اما به نظر می رسد اجرای نادرست است.
Is <details> یک ظرف یا یک عنصر تعاملی؟
بسیاری از مردم هستند با استفاده از <details> برای تغییر منوها باز و بسته این یک تمرین است توسط GitHub محبوب شده است.
منطقی به نظر می رسد. مشخصات مطمئناً اجازه می دهد:
La
detailsعنصر نشان دهنده ویجت افشایی که کاربر می تواند از آن اطلاعات بیشتری کسب کند یا کنترل ها.(تاکید از من است)
خوب، پس ما ممکن است انتظار آن را داشته باشیم <details> ظرف است (دارای یک ضمنی role=group) و <summary> یک عنصر تعاملی است که ظرف را تنظیم می کند open حالت. از آن زمان منطقی است <summary> ضمنی دارد button نقش در برخی زمینه ها (اما نقش WAI-ARIA مربوطه وجود ندارد).
اما ملانی سامنر کمی حفاری انجام داد که نه تنها به نظر می رسد با آن تناقض دارد، بلکه به این نتیجه می رسد که استفاده از <details> به عنوان یک منو احتمالا بهترین چیز نیست. ببینید چه اتفاقی می افتد <details> بدون رندر می شود <summary> عنصر:
این دقیقا همان چیزی است که مشخصات نشان می دهد در صورت عدم وجود یک <summary> - خودش را می سازد:
اول
summaryعنصر فرزند عنصر، اگر وجود داشته باشد, نشان دهنده خلاصه یا افسانه جزئیات اگر بچه ای نباشدsummaryعامل کاربر باید افسانه خود را ارائه دهد (به عنوان مثال "جزئیات").(تاکید از من است)
ملانی آن را از طریق یک اعتبارسنجی HTML اجرا کرد و - شگفت زده شد! - نامعتبر است:
پس <details> نیاز به <summary>. و وقتی که <summary> گم شده است، <details> خود را ایجاد می کند، اگرچه به عنوان نشانه گذاری نامعتبر منتقل می شود. این همه هنگی-دور و معتبر زمانی است <summary> وجود دارد:
همه اینها به یک سوال جدید منجر می شود: چرا است <summary> ضمنی داده شده است button نقش وقتی <details> چیزی که به نظر می رسد عنصر تعاملی است؟ شاید این مورد دیگری باشد که اجرای مرورگر نادرست است؟ سپس دوباره، مشخصات هر دو را به عنوان دسته بندی می کند عناصر تعاملی. می توانید ببینید که همه اینها چقدر گیج کننده است.
در هر صورت، نتیجه نهایی ملانی است که ما باید از استفاده از آن اجتناب کنیم <details> برای منوها بر اساس نحوه خواندن و اعلام فناوری کمکی است <details> که حاوی عناصر تعاملی است. عنصر اعلام شده است، اما هیچ اشاره ای به کنترل های تعاملی فراتر از آن وجود ندارد تا زمانی که شما، تعامل با <details>. فقط پس از آن چیزی شبیه به لیست پیوندها اعلام می شود.
علاوه بر این، محتوای داخل یک فرو ریخت <details> از جستجوی درون صفحه حذف می شود (به جز در مرورگرهای Chromium، که می توانند در زمان نوشتن به محتوای جمع شده دسترسی داشته باشند)، پیدا کردن همه چیز را حتی دشوارتر می کند.
باید <summary> اجازه دادن به عناصر تعاملی؟
این سوال مطرح شده در این تاپیک باز. ایده این است که چیزی شبیه به این نامعتبر است:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>اسکات اوهارا به خوبی خلاصه می شود چرا این یک مسئله است:
پیوند به هیچ وجه در JAWS هنگام پیمایش با مکان نما مجازی آن قابل کشف نیست. اگر از طریق کلید Tab به عنصر خلاصه حرکت کنید، JAWS "متن نمونه، دکمه" را به عنوان نام و نقش عنصر اعلام می کند. اگر دوباره کلید Tab را فشار دهید، JAWS دوباره "متن نمونه، دکمه" را اعلام می کند، حتی اگر تمرکز صفحه کلید روی پیوند باشد.
[...]
موارد بیشتری وجود دارد که می‌توانم درباره مشکلات مختلف AT با مدل محتوا برای خلاصه صحبت کنم... اما این فقط این نظر را فراتر از آنچه لازم است گسترش می‌دهد. tldr; مدل محتوای خلاصه برای افرادی که از AT استفاده می‌کنند، تجربیات بسیار ناسازگار و گاهی اوقات ساده ایجاد می‌کند.
اسکات برای اصلاح این رفتار بلیط ها را باز کرد کروم و WebKit. ممنون، اسکات!
با این حال، HTML معتبر است:
اسکات در الف فراتر می رود پست وبلاگ جداگانه. مثلاً سیلی زدن را توضیح می دهد role=button on <summary> ممکن است یک راه حل معقول به نظر برسد تا اطمینان حاصل شود که به طور مداوم توسط فناوری کمکی اعلام می شود. این همچنین بحث در مورد اینکه آیا را حل می کند <summary> باید به عناصر تعاملی اجازه دهد زیرا دکمه ها نمی توانند حاوی عناصر تعاملی باشند. تنها مشکل این است که Safari سپس درمان می کند <summary> به عنوان یک دکمه استاندارد، که خود را از دست می دهد expanded و collapsed ایالت ها. بنابراین، نقش صحیح اعلام شده است، اما اکنون وضعیت آن نیست. 🙃
الان کجا برویم؟
آیا از استفاده می ترسید <details>/<summary> با همه این مسائل و ناهماهنگی ها؟ من مطمئن هستم، اما فقط تا آنجا که مطمئن شوم آنچه در آن است تجربه و انتظارات مناسب را برای کاربران فراهم می کند.
من فقط خوشحالم که این گفتگوها اتفاق می افتد و در فضای باز برگزار می شود. به همین دلیل، می‌توانید در مورد سه راه‌حل پیشنهادی اسکات برای چگونگی مدل‌سازی محتوا نظر دهید <summary> تعریف شده است، به بلیط های او رأی مثبت دهید، و مشکلات و موارد استفاده خود را در حالی که در آن هستید گزارش دهید. امیدواریم، هر چه بهتر درک کنیم که عناصر چگونه استفاده می شوند و انتظار داریم آنها چه کاری انجام دهند، بهتر اجرا می شوند.
