المحتوى عن 'section'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • مقالات عامة
  • التجارة الإلكترونية

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 1 نتيجة

  1. عادة ما يرتكب القادم الجديد إلى عالم 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 ممكنا رغم أنه غير ضروري. WHATWG HTML spec الكلمة المفتاحية في هذه المواصفات هي "الرئيسية"، قد نختلف فيما تعنيه هذه الكلمة على وجه التحديد، لكنه عادة ما يُقصد بها: روابط تصفح الموقع الرئيسيةمحرك بحث الموقعروابط تصفح الموقع الثانويةروابط التنقل داخل الصفحة الواحدة (خاصة في الصفحات والمقالات الطويلة).بالرغم من أنه يصعب تمييز الصحيح من الخطأ في الكثير من الحالات إلا أنه يبدو بأنه من الأفضل تجنب استخدام nav في الحالات التالية: ترقيم الصفحاتالروابط الاجتماعية (قد يكون لهذا الأمر استثناءات خاصة إذا ما كانت هذه الروابط جزءا أساسيا في الصفحة مثلما هو الحال مع موقعي about me و flavours)الوسوم أو التصنيفات في التدويناتالروابط الثانويةأسفل الصفحات (footers)إن لم تعرف ما إذا كان بإمكانك استخدام عنصر nav اسأل نفسك، هل الروابط التي تنوي تغليفها داخل عنصر nav هي وسيلة أساسية للانتقال داخل الصفحة أو داخل الموقع؟ يمكنك الاستعانة بالنقطتين التاليتين للإجابة على هذا السؤال: لا تستخدم nav ما لم تعتقد بأنه يُمكن استبدال الأمر بعنصر <section> باستخدام عنصر hxهل كنت ستضيف عنصر "اذهب مباشرة إلى" للوصول إليها لتحسين قابلية وصول الموقع؟إن كانت إجابتك بالنفي فإنه من الأجدر بك عدم استخدام عنصر nav. أخطاء شائعة مع عنصر figureليس من السهل إتقان استخدام عنصر figure (وعنصر figcaption الذي يلازمه). إليكم بعض الأخطاء الشائعة التي يقع الكثيرون لدى استعمالهما. لا تستعمل figure مع جميع الصوركما سبق وأن أشرنا إليه ، لا توجد أية فائدة من كتابة شفرات إضافية ما لم يكن هناك داع لها، وهو نفس الأمر الذي يتكرر مع هذا العنصر أيضا. هناك من يقوم بتحويل جميع الصور إلى figure رغم أننا في غنى عن تغليف كل صورة في هذا العنصر، كلما تقوم به لدي قيامك بهذا الأمر هو إضافة شفرات إضافية لا تقدم أية إضافة للصفحة. تحدد مواصفات HTML5 عنصر figure على النحو التالي: بعبارة أخرى 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