عادة ما يرتكب القادم الجديد إلى عالم HTML5 أخطاء عديدة ترجع إما لعدم فهمه للعناصر الجديدة أو الإفراط في استخدامها مكان العناصر القديمة. سنحاول في هذا المقال تسليط الضوء على أكثر الأخطاء شيوعا وكيفية تجنب الوقوع فيها.
لا تستخدم <section> كأداة للتغليف بدل <div>
أحد أكثر الأخطاء شيوعا هو الاستبدال المفرط لكل عناصر <div> بعناصر <section> في شفرات HTML5 وخاصة لما يتعلق الأمر بعناصر <div> المستخدمة لأغراض تنسيقية styling. سابقا لدى استخدامنا لـ XHTML و HTML4 كنا نكتب الشفرات على النحو التالي:
<!-- HTML 4-style code -->
<div id="wrapper">
<div id="header">
<h1>My super duper page</h1>
<!-- Header content -->
</div>
<div id="main">
<!-- Page content -->
</div>
<div id="secondary">
<!-- Secondary content -->
</div>
<div id="footer">
<!-- Footer content -->
</div>
</div>بعض ظهور HTML5 أصبح العديد يكتبونها على النحو التالي:
<!-- Don’t copy this code! It’s wrong! -->
<section id="wrapper">
<header>
<h1>My super duper page</h1>
<!-- Header content -->
</header>
<section id="main">
<!-- Page content -->
</section>
<section id="secondary">
<!-- Secondary content -->
</section>
<footer>
<!-- Footer content -->
</footer>
</section>وهو أمر خاطئ لأنه وبكل بساطة لا يعتبر عنصر <section> أداة تغليف wrapper، حيث أنه يتم استخدام هذا العنصر مع الأجزاء الدلالية للصفحة لبناء مخطط واضح المعالم لها، كما أنه من الواجب أن يحتوي على ترويسة heading. إن كان كل ما ترغب في القيام به هو إضافة نمط style لصفحتك فحاول أن تنفذه مباشرة على عنصر <body> ، أما لو احتجت عناصر إضافية للنمط الذي تود تنفيذه فعليك استخدام <div> في هذه الحالة وهو العنصر الأنسب لما يكون كل ما تحتاجه هو أداة لتنفيذ الأنماط.
بناء على ما سبق ذكره فإن الطريقة الصحيحة لكتابة الشفرة السابقة باستخدام HTML5 وبعض وظائف ARIA (ملاحظة: قد تحتاج إلى عنصر <div> واحد فقط بناء على التصميم الذي ترغب فيه) هو على النحو التالي:
<body>
<header>
<h1>My super duper page</h1>
<!-- Header content -->
</header>
<div role="main">
<!-- Page content -->
</div>
<aside role="complementary">
<!-- Secondary content -->
</aside>
<footer>
<!-- Footer content -->
</footer>
</body>إذا لم تكت تعلم ما هي العناصر التي يجب عليك استخدامها فيُمكنك الاستعانة بالصورة التالية التي ستسهل عليك الاختيار
لا تستخدم عنصر header ما لم يكن هناك حاجة إليه
ملاحظة: في المقال الأصلي تم الحديث عن عنصري header و hgroup، وبما أنه تم التخلص من هذا الأخير من مواصفات HTML5 فلم أقم بتضمينه في الترجمة.
لا توجد أية معنى لإضافة عناصر إضافية إلى صفحتك ما لم يكن هناك حاجة لها، لكن رغم ذلك عادة ما نلحظ استخدام عنصر <header> لما لا تكون هناك أية حاجة إلى استخدامه. يُمكنك معرفة كيفية استخدام هذا العنصر بقراءتك لهذا المقال والذي يُمكن تلخيصه في أن العنصر <header> يلعب دور عنصر مساعد أو مقدم لمحتوى الجزء الذي يحتويه.
وبما أنه يُمكن استخدام عنصر <header> أكثر من مرة واحدة في نفس الصفحة فإنه عادة ما تتم إساءة استخدامه على النحو التالي:
<!-- Don’t copy this code! No need for header here -->
<article>
<header>
<h1>My best blog post</h1>
</header>
<!-- Article content -->
</article>إن كان عنصر header الذي تستخدمه لا يحتوي سوى على عنصر رأسي heading element واحد فمن الأفضل تجنب استخدامه، حيث أن عنصر article سيضمن تضمين هذا العنصر الرأسي في مُخطط الصفحة document outline. وبما أنه سيحتوي عنصرا واحدا فقط (عكس ما تشير إليه مواصفات العنصر) فإنه من الأفضل كتابة الشفرة بشكل مبسط على النحو التالي:
<article> <h1>My best blog post</h1> <!-- Article content --> </article>
لا تُغلف كل قوائم الروابط باستخدام nav
لم يعد من السهل -مع كل العناصر الجديدة التي تمت إضافتها إلى HTML5- اختيار العنصر الأنسب لكثرة الاختيارات المتاحة، لكنه في المقابل لا يجب علينا أن نُفرط في استخدام العناصر الدلالية الجديدة وهو أمر عادة ما نلاحظه مع العنصر nav والذي تنص مواصفاته على التالي:
يُمثل عنصر nav قسما من الصفحة تقوم بالربط إلى صفحات أخرى أو إلى أجزاء أخرى من نفس الصفحة.
ملاحظة: لا يجب أن تكون كل مجموعات الروابط داخل عناصر <div>، يجب اقتصار استعمال هذا العنصر على كتل التصفح Navigation blocks الرئيسية فقط. فعلى سبيل المثال عادة ما يحتوي أسفل الصفحات footers على قوائم قصيرة لروابط لمختلف صفحات الموقع مثل قواعد استخدام المواقع، صفحة البداية وصفحة حقوق الملكية الفكرية. في مثل هذه الحالات يكفي استخدام عنصر footer لكنه يبقى استخدام عنصر nav ممكنا رغم أنه غير ضروري.
الكلمة المفتاحية في هذه المواصفات هي "الرئيسية"، قد نختلف فيما تعنيه هذه الكلمة على وجه التحديد، لكنه عادة ما يُقصد بها:
- روابط تصفح الموقع الرئيسية
- محرك بحث الموقع
- روابط تصفح الموقع الثانوية
- روابط التنقل داخل الصفحة الواحدة (خاصة في الصفحات والمقالات الطويلة).
بالرغم من أنه يصعب تمييز الصحيح من الخطأ في الكثير من الحالات إلا أنه يبدو بأنه من الأفضل تجنب استخدام nav في الحالات التالية:
- ترقيم الصفحات
- الروابط الاجتماعية (قد يكون لهذا الأمر استثناءات خاصة إذا ما كانت هذه الروابط جزءا أساسيا في الصفحة مثلما هو الحال مع موقعي about me و flavours)
- الوسوم أو التصنيفات في التدوينات
- الروابط الثانوية
- أسفل الصفحات (footers)
إن لم تعرف ما إذا كان بإمكانك استخدام عنصر nav اسأل نفسك، هل الروابط التي تنوي تغليفها داخل عنصر nav هي وسيلة أساسية للانتقال داخل الصفحة أو داخل الموقع؟ يمكنك الاستعانة بالنقطتين التاليتين للإجابة على هذا السؤال:
- لا تستخدم nav ما لم تعتقد بأنه يُمكن استبدال الأمر بعنصر <section> باستخدام عنصر hx
- هل كنت ستضيف عنصر "اذهب مباشرة إلى" للوصول إليها لتحسين قابلية وصول الموقع؟
إن كانت إجابتك بالنفي فإنه من الأجدر بك عدم استخدام عنصر nav.
أخطاء شائعة مع عنصر figure
ليس من السهل إتقان استخدام عنصر figure (وعنصر figcaption الذي يلازمه). إليكم بعض الأخطاء الشائعة التي يقع الكثيرون لدى استعمالهما.
لا تستعمل figure مع جميع الصور
كما سبق وأن أشرنا إليه ، لا توجد أية فائدة من كتابة شفرات إضافية ما لم يكن هناك داع لها، وهو نفس الأمر الذي يتكرر مع هذا العنصر أيضا. هناك من يقوم بتحويل جميع الصور إلى figure رغم أننا في غنى عن تغليف كل صورة في هذا العنصر، كلما تقوم به لدي قيامك بهذا الأمر هو إضافة شفرات إضافية لا تقدم أية إضافة للصفحة.
تحدد مواصفات HTML5 عنصر figure على النحو التالي:
some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.
بعبارة أخرى figure عبارة عن محتوى قائم بذاته يحتوي وصفا يتم إضافته إلى محتوى الصفحة رغم أنه ليس جزءا أساسيا فيها.
وهنا يبرز جمال عنصر figure حيث أنه بالإمكان تغيير مكانه في الصفحة إلى القائمة الجانبية sidebar مثلا دون الإخلال بمحتوى الصفحة.
إن كان ما تحاول وضعه داخل figure عبارة عن محتوى جمالي فقط لا يقدم أية إضافة للمحتوى، وإن لم يكن بالإمكان الإشارة إليه في محتوى صفحتك فإنه من المحتمل جدا أن لا يكون العنصر الواجب استخدامه هو figure. يُمكنك أيضا أن تسأل نفسك "هل هذه الصورة (أو غيرها) أساسية لفهم محتوى الصفحة" إن لم يكن جوابك بالإيجاب فقد لا يكون figure هو العنصر الأنسب لك (فكر في استخدام aside حينها). أما لو أجبت بالإيجاب فاسأل نفسك "هل يمكنني تغيير مكان هذه الصورة إلى ملف ملحق appendix ؟" إن كانت إجابتك بالنفي هنا أيضا فقد لا يكون عنصر figure هو الأنسب لك أيضا.
لا تستخدم figure مع شعار موقعك
لا يصح أيضا استخدام figure مع شعارات المواقع أيضا. عادة ما نشاهد مثل هذه الشفرات الخاطئة في بعض المواقع:
<!—Don't copy this code! It's wrong! -->
<header>
<h1>
<figure>
<img src="/img/mylogo.png" alt="My company" />
</figure>
My company name
</h1>
</header>
<!—Don't copy this code! It's wrong! -->
<header>
<figure>
<img src="/img/mylogo.png" alt="My company" />
</figure>
</header>ليس لدينا ما نقوله هنا سوى أن استخدام figure للشعارات هو استخدام خاطئ. يجب عليك تجنب استخدام figure ما لم تتم الإشارة إلى المحتوى المراد تغليفه في هذا العنصر داخل الصفحة. وبما أنه من السهل أن نجزم بأنه لن تتم الإشارة إلى شعار موقعك في أي جزء من أجزاء صفحتك، فإن كل ما تحتاجه هو:
<header> <h1>My company name</h1> <!-- More stuff in here --> </header>
لا يقتصر استخدام figure على الصور فقط
الاعتقاد السائد هو أن استخدام عنصر figure يقتصر على الصور فقط وهو اعتقاد خاطئ حيث أنه من المُمكن استخدام figure مع الفيديوهات، الملفات الصوتية، الرسوم البيانية (على هيأة SVG مثلا)، الاقتباسات، الجداول، الشفرات المصدرية وغيرها. يعني أي محتوى يساعد على فهم المحتوى الرئيسي للصفحة وإعطاء تفاصيل إضافية حوله يصلح أن يكون داخل عنصر figure.
يُمكن معرفة المزيد حول عنصر figure بقراءتك لهذا المقال.
استخدام خاصية type غير الضرورية
استخدام خاصية type شائعة جدا ما بين المبرمجين، رغم أنه ليس خطأ في حد ذاته، إلا أنه من الأفضل تجنبه.
ليس من الضروري لدى استخدام HTML5 التصريح بنوع عنصري script و style. قد لا يكون من السهل التخلص من الأمر خاصة إن كان إضافة هذه الخاصية يتم بشكل آلي خاصة لدى استخدام أنظمة إدارة المحتوى إلا أنه لا توجد أية حاجة ماسة لاستخدامها لما تقوم بكتابة كامل شفرة تطبيقك بشكل يدوي لأنه وبكل بساطة تتوقع جميع المتصفحات أن تكون السكربتات التي تستخدمها من نوع javascript وكل الأنماط من نوع css، وعليه فإنك لن تحتاج إلى كتابة التالي:
<!-- Don’t copy this code! It’s attribute overload! --> <link type="text/css" rel="stylesheet" href="css/styles.css" /> <script type="text/javascript" src="js/scripts.js"></script>
بل كل ما تحتاجه هو
<link rel="stylesheet" href="css/styles.css" /> <script src="js/scripts.js"></script>
كما أننا لم نعد في حاجة إلى كتابة الكثير للإشارة إلى نوعية الترميز المستخدم في الصفحة character set إضافة إلى أمور أخرى لم يعد هناك حاجة إليها ستجدها مشروحة بشكل مفصل في هذا المقال.
استخدامات خاطئة لبعض خصائص النماذج
كما سبق وأن أشرنا إليه، يوفر HTML5 خصائص عديدة للنماذج، ويرافق استخدام هذه الخصائص أخطاء يجب تجنبها:
الخصائص المنطقية
العديد من الخصائص الجديدة في نماذج HTML5 هي خصائص منطقية، ونعني بذلك بأنه تتم إضافة سلوك معين للنموذج أو لعنصر ما بمجرد إضافة هذا العنصر إليه، ومن بين هذه الخصائص المنطقية نجد كلا من autofocus، autocomplete و required.
قد لا يكون هذه المشكل كثير الشيوع، إلا أن هناك من يستخدم هذه الخصائص المنطقية (عنصر required مثلا) على النحو التالي:
<!-- Don’t copy this code! It’s wrong! --> <input type="email" name="email" required="true" /> <!-- Another bad example --> <input type="email" name="email" required="1" />
لكن ماذا لو أردت "العبث" بالشفرة السابقة قليلا وأعطيت قيمة false لخاصية required، ما الذي تتوقع أن يقوم به المتصفح في هذه الحالة؟
<!-- Don’t copy this code! It’s wrong! --> <input type="email" name="email" required="false" />
على غير ما تتوقع فإن المتصفح وبمجرد أن يلاحظ وجود خاصية required فإنه يقوم بجعل العنصر الذي تمت إضافته إليه ضروريا رغم أنك أعطيت الخاصية قيمة false.
هناك 3 صيغ لاستخدام الخصائص المنطقية مع HTML5 (يتم استخدام الصيغتين الثانية والثالثة مع XHTML):
required required="" required="required"
وأفضل طريقة لكتابة الشفرة السابقة هي على النحو التالي:
<input type="email" name="email" required />
خلاصة
استعرضنا في هذا المقال بعضا من الأخطاء الأكثر شيوعا مع HTML5. بطبيعة الحال فإنه يستحيل حصر كل هذه الأخطاء، وبالتالي إن كانت هناك أخطاء أخرى سبق وأن شاهدتها أكثر من مرة فلا تتردد في مشاركتها معنا في التعليقات.
ترجمة -وبتصرف- للمقال Avoiding common HTML5 mistakes لصاحبه Richard Clark
تم التعديل في بواسطة يوغرطة بن علي
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.