الكثير من الثرثرة حول العالم <details> و <summary> العناصر في الآونة الأخيرة! لقد رأيت غردت Lea Verou مؤخرًا ملاحظة حول العنصر display السلوك وهذا شيء ينقسم إلى المزيد من الملاحظات وملاحظات الاستخدام من الأشخاص ، بما في ذلك أ أحيت المناقشة على ما إذا كان <summary> يجب السماح لاحتواء عناصر تفاعلية أم لا.
هناك الكثير من النقاط التي يجب ربطها وسأبذل قصارى جهدي هنا للقيام بذلك بالضبط.
هل يمكننا تغيير عرض العناصر المتداخلة في ملف <details> جزء؟
غريب جدا! إذا فتحنا DevTools ، فستخبرنا ورقة أنماط وكيل المستخدم <details> هو معروض كعنصر كتلة.
لاحظ المطلوب <summary> والعنصران الإضافيان <div>ق هناك. يمكننا تجاوز display، حق؟
ما قد نتوقعه هو ذلك <details> الآن ارتفاع واضح يبلغ 40vh وثلاثة صفوف حيث يشغل الصف الثالث المساحة المتبقية المتبقية من الصفين الأولين. مثله:
آه ، لكن الصف الثالث لا ... يفعل ... ذلك.
من الواضح أن ما نتعامل معه هو حاوية شبكة غير قادرة على تطبيق سلوك الشبكة على عناصر الشبكة الخاصة بها. لكن مواصفات HTML تخبرنا:
•
detailsالعنصر من المتوقع تقديمه كملف صندوق كتلة. من المتوقع أيضًا أن يكون للعنصر داخلي شجرة الظل مع اثنين فتحات.(توكيد لي)
وبعد ذلك بقليل:
•
detailsالعنصر الثاني فتحة من المتوقع أن يكون لهاstyleتم تعيين السمة على "display: block; content-visibility: hidden;" عندماdetailsلا يحتوي العنصر على ملفopenالسمة. عندما يكون لديهopenالسمةstyleالسمة من المتوقع إزالتها من الثانية فتحة.(التأكيد لي مرة أخرى)
لذلك ، تشير المواصفات إلى الفتحة الثانية - الفتحتان الإضافيتان <div>s من المثال - يتم إجبارها فقط على كونها عناصر كتلة عندما <details> مغلق. عندما يكون مفتوحا - <details open> - يجب أن تتوافق مع عرض الشبكة الذي يتجاوز تصميم وكيل المستخدم ... أليس كذلك؟
هذا هو النقاش. فهمت ذلك slots يتم تعيين إلى display: contents بشكل افتراضي، ولكن يبدو أن التشويش على العناصر المتداخلة في الفتحات وإزالة القدرة على تصميمها يبدو بعيدًا. هل هي مشكلة في المواصفات أن المحتويات عبارة عن فتحات ، أو مشكلة في المتصفح لا يمكننا تجاوزها display على الرغم من أنهم في صندوق الشجرة؟ يمكن للأشخاص الأكثر ذكاءً أن ينورني ولكن يبدو أنه تنفيذ غير صحيح.
Is <details> حاوية أم عنصر تفاعلي؟
الكثير من الناس استخدام <details> لتبديل القوائم مفتوح ومغلق. إنها ممارسة شاعها جيثب.
يبدو معقولا. المواصفات تسمح بذلك بالتأكيد:
•
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.
فتح Scott تذاكر لتصحيح هذا السلوك في الكروم و بكت. شكرا سكوت!
ومع ذلك ، فهي صالحة HTML:
يذهب سكوت إلى أبعد من ذلك في أ بلوق وظيفة منفصلة. على سبيل المثال ، يشرح كيف الصفع role=button on <summary> قد يبدو كحل معقول لضمان الإعلان عنه باستمرار بواسطة التكنولوجيا المساعدة. ومن شأن ذلك أيضًا أن يحسم الجدل حول ما إذا كان <summary> يجب أن تسمح بالعناصر التفاعلية لأن لا يمكن أن تحتوي الأزرار على عناصر تفاعلية. المشكلة الوحيدة هي أن Safari يعامل بعد ذلك <summary> كزر قياسي ، والذي يفقده expanded و collapsed تنص على. إذن ، الدور الصحيح معلَن ، لكن حالته الآن ليست كذلك. 🙃
أين نذهب الآن؟
هل أنت خائف من استخدام <details>/<summary> مع كل هذه القضايا والتناقضات؟ أنا متأكد من ذلك ، ولكن فقط فيما يتعلق بالتأكد من أن ما يحتويه يوفر النوع الصحيح من الخبرة والتوقعات للمستخدمين.
أنا سعيد فقط بأن هذه المحادثات تحدث وأنها تجري في العراء. لهذا السبب ، يمكنك التعليق على حلول سكوت الثلاثة المقترحة لكيفية استخدام نموذج المحتوى <summary> يتم تعريفه ، والتصويت على تذاكره ، والإبلاغ عن المشكلات الخاصة بك وحالات الاستخدام أثناء تواجدك فيها. نأمل أنه كلما فهمنا بشكل أفضل كيفية استخدام العناصر وما نتوقع منها القيام به ، كان تنفيذها أفضل.
