در قسمت اول این مجموعه، نقص هایی را که منجر به عناصر ساختاری HTML5 می شود، پوشش دادیم، در این قسمت دوم به طور مفصل به عواقب این نقص ها خواهیم پرداخت.

من چندین بار گفته ام که HTML5 یک روش جدید برای ساختار یک وب معرفی می کند pageو احتمالاً از خود می‌پرسید که واقعاً چیست. دقیقاً در مشخصات وجود دارد که مفهوم “بخش بندی محتوا” را معرفی می کند‘: محتوای بخش بندی محتوایی است که محدوده سرفصل ها و پاورقی ها را مشخص می کند. هر عنصر محتوای بخش بندی به طور بالقوه دارای یک عنوان و یک طرح کلی است.

مشخصات رویکرد خود را به سرفصل ها، بخش ها و خطوط کلی تا مفهوم روشن شود. خوب، برای کسانی که باید این قابلیت را در مرورگرها پیاده سازی کنند، واضح است. برای درک عناصر ساختاری HTML (بخش، مقاله، پیمایش، کنار، و عناصر مرتبط با آنها سرصفحه و پاورقی) و این مفهوم مبهم «بخش بندی محتوا» یا «طرح کلی»، باید کمی در تاریخچه HTML سفر کنیم.

طرح یک مفهوم قدیمی

مفهوم طرح کلی معرفی شده در HTML5 را می توان تا سال 1991 دنبال کرد و در مشخصات بدبخت و بن بست XHTML 2.0 گنجانده شد و در نهایت در HTML5 روشنایی روز را دید… فقط به قدری ضعیف ارتباط برقرار کرد که این ایده تقریبا مرده است روی ورود

قبل از HTML5، ساختار سلسله مراتبی a page توسط عناصر عنوان تعیین شد – دوستان قدیمی ما از h1 تا h6. ما می توانیم ساختار a page با گفتن page عنوان h1 است، عنوان مقاله ممکن است h2 باشد، و شاید عنوان های فرعی در مقاله ممکن است h3 و h4 باشد، و به همین ترتیب روی.

این برای یک سند ساده خوب است، اما با استفاده از برچسب‌های عنوان برای ایجاد یک سلسله مراتب منطقی یا “طرح کلی سند” برای یک وب پیچیده و مدرن page بسیار دشوار است بخشی از مشکل عدم وجود راهی برای تعیین مکان a page بخش شروع و متوقف می شود. به عنوان مثال، فرض کنید ما سندی را که قبلاً ذکر شد با h1 برای آن داشتیم page عنوان، h2 برای عنوان مقاله، h3 برای عنوان‌های فرعی، اما سپس می‌خواستیم عنوان بخش‌های نوار کناری خود را با عنوان‌های h3 نیز علامت‌گذاری کنیم.

طرح کلی سندی که چنین ساختاری ایجاد می کند چیزی شبیه به این خواهد بود:

<h1>My Old Blog</h1>
 <h2>My Latest Blog Post</h2>
 <h3>My Blog Post Sub Heading</h3>
 <h3>My Blog Post Sub Heading</h3>
 <h3>About Me</h3>
 <h3>Archives</h3>
 <h3>Social Links</h3>

در اینجا، عناصر h3 متعلق به h2 بالای آنها هستند، حتی اگر چندان منطقی نباشد. البته، ما این موارد را با چیزی مانند div برای مقاله و div برای نوار کناری تقسیم می‌کنیم، اما اینها توسط عوامل کاربر (مانند صفحه‌خوان‌ها) که تعیین می‌کنند نادیده گرفته می‌شوند. page طرح کلی با ساختار سرفصل به تنهایی.

با گره زدن page سلسله مراتبی که مستقیماً به سطوح سرفصل ارائهی هستند، ما در روش ساختار a محدود هستیم page.

تلاشی تازه برای یک هدف قدیمی

در تلاش برای حل این مشکل، HTML5 مفهوم «عناصر بخش‌بندی» را معرفی می‌کند، یعنی عناصر ویژه‌ای که بخش‌ها را تقسیم می‌کنند. page تا – حدس زدید – بخش‌ها، و آن بخش‌ها سطح تودرتوی سرصفحه‌ها و در واقع سلسله مراتب یا «طرح کلی» را تعیین می‌کنند. page.

یعنی سلسله مراتب page از عناصر عنوان جدا شده است، و در عوض این عناصر بخش بندی جدید تعیین می کنند که یک عنصر عنوان در واقع در چه سطحی است.

در پیش نویس اول مشخصات XHTML 2.0، بخش بندی با یک عنصر بخش و یک عنصر هدر h عمومی کار می کند. هنگام نوشتن HTML، ما مشخص نمی‌کنیم که از چه سطحی می‌خواهیم استفاده کنیم، به سادگی به مرورگر اجازه می‌دهیم سطح تودرتو برای یک عنوان مشخص را تعیین کند. ما می‌توانیم عناصر بخش را در عمق 99 سطح قرار دهیم و یک عنصر h در سطح 99 معادل یک عنصر h99 است. به این ترتیب، بدون نگرانی در مورد اینکه چگونه می توانیم از عناصر محدود h1-h6 استفاده کنیم، می توانیم اسناد خود را به صورت منطقی ساختار دهیم.

(این ایده واقعاً به سال 1991 برمی گردد: به عنوان جرمی کیت اشاره کرد، تیم برنرز لی ایده بخش و عنصر h را برای ساختار a مطرح کرد page در پایان این ایمیل اکتبر 1991.)

هیکسون تلاش کرد همین مفهوم را در HTML5 معرفی کند، اما با درجه ای از دشواری: او می خواست سازگاری با عقب را حفظ کند، و برخی از معنای جدید را برای “ساده کردن نوشتن” به بوت معرفی کند. بنابراین، به جای اینکه فقط یک عنصر بخش در HTML5 داشته باشیم، یک مقاله، ناو و عنصر کناری نیز داریم که همگی همان کار را با بخش انجام می‌دهند، اما با نام‌های متفاوت، برای استفاده به روش‌های مختلف.

مشخصات در مورد این عناصر چه می گوید؟ من شما را تشویق می کنم مشخصات را خودتان بخوانید، اما در اینجا یک طعم وجود دارد:

<بخش>

عنصر بخش پایه و اساس برش برای ایجاد طرح کلی سند است.

عنصر بخش نمایانگر بخش عمومی یک سند یا برنامه است. یک بخش، در این زمینه، یک گروه بندی موضوعی از محتوا است که معمولاً یک عنوان دارد.

نمونه‌هایی از بخش‌ها می‌تواند فصل‌ها، صفحات مختلف زبانه‌دار در یک کادر محاوره‌ای زبانه‌دار یا بخش‌های شماره‌دار پایان‌نامه باشد. خانه یک وب سایت page می تواند به بخش هایی برای معرفی، اخبار و اطلاعات تماس تقسیم شود.

یک یادداشت در مشخصات می گوید که این عنصر نباید صرفاً برای اهداف استایلی استفاده شود – یک div در آنجا بهتر است، و قابل درک است، زیرا بخش هایی که خواه ناخواه برای یک ظاهر طراحی شده اند، یک طرح کلی سند بسیار شکسته ایجاد می کند.

یادداشت می رود روی برای گفتن “یک قانون کلی این است که عنصر بخش تنها در صورتی مناسب است که محتوای عنصر به صراحت در طرح کلی سند فهرست شود” و این واضح ترین عبارت در مورد عنصر بخش در مشخصات است.

هنگامی که مفهوم برش و طرح کلی را درک می کنیم، گنجاندن عنصر بخش منطقی است. این در تحقیقات ارزش های کلاس رایج ظاهر نشد، اما در XHTML 2.0 ظاهر شد و از نظر مفهومی به سال 1991 باز می گردد.

<مقاله>

عناصر ساختاری دیگری که HTML5 معرفی می‌کند – آنهایی که ظاهراً در تحقیق منعکس شده‌اند – تا آنجا که به طرح کلی سند مربوط می‌شود، دقیقاً همان کار عنصر بخش را انجام می‌دهند. آنها همچنین سلسله مراتب را ایجاد می کنند pageو بنابراین طرح کلی سند.

برای مثال عنصر مقاله را در نظر بگیرید. بسیاری از مردم تصور می کنند که این فقط برای مقالاتی مانند این است. اما اصلاً این نیست. این «مقاله» به معنای «یک کالای لباس» است. بهتر است به عنوان “اقلام” مانند “یک مورد از لباس” در نظر گرفته شود، زیرا تعریف آن بسیار گسترده است.

وقتی عناصر مقاله تو در تو هستند، عناصر مقاله داخلی نشان دهنده مقالاتی هستند که اصولاً با محتوای مقاله بیرونی مرتبط هستند. به عنوان مثال، یک ورودی وبلاگ روی سایتی که نظرات ارسال شده توسط کاربر را می پذیرد، می تواند نظرات را به عنوان عناصر مقاله تو در تو در عنصر مقاله برای ورودی وبلاگ نشان دهد.

در HTML5، نظرات کاربران، مقاله مناسب، پست‌های انجمن و حتی «ویجت‌ها و ابزارهای تعاملی» همگی مقاله هستند. این تعریف به قدری گسترده است که بی فایده است – معناشناسی قرار است معنا را منتقل کند، اما استفاده از یک اصطلاح جمعی برای چنین طیف گسترده ای از موارد، عنصر را بی معنی می کند.

این یکی از نمونه‌هایی است که ما مشخصات را جدا کرده‌ایم – چند نفر به درستی مشخصات را دنبال می‌کنند و تقریباً همه چیز را به یک مقاله تبدیل می‌کنند (خلاصه پست‌های وبلاگ، پست‌های وبلاگ، نظرات، ویجت‌ها، پست‌های انجمن و غیره)، در حالی که دیگران فقط آن را حفظ کرده‌اند. برای مقاله اصلی روی الف page، که تنها بخشی از تعریف گسترده آن است. ممکن است فکر کنید که به هیچ وجه مهم نیست و تا حد زیادی حق با شماست. اما به همه آن خدمات خواندن فکر کنید که هدفشان تجزیه محتوای اصلی است page. کدام اجرای مشخصات را باید دنبال کنند؟ آیا باید آنچه را که مشخصات واقعاً می‌گوید دنبال کنند، یا باید اجرای عمومی جامعه را که معمولاً فقط یک «مقاله» متعارف وجود دارد، دنبال کنند. روی الف page?

این یک فرصت از دست رفته است، و چه اتفاقی می‌افتد وقتی که مشخصات واقعاً ناکام باشد مشخص کنیدو ویرایشگر و، انصافاً، جامعه، نمی توانند آنچه را که مشخصات واقعاً می گوید، بیان کنند.

تصور کنید اگر از مقاله برای نظرات نیز استفاده نمی شد. تصور کنید مثلاً نظرات عنصر خاص خود را داشته باشند و پذیرش گسترده شود. سازندگان مرورگر می توانند یک تابع “بی صدا کردن نظرات” را اضافه کنند که به راحتی می تواند نظرات را پنهان کند (یا در غیر این صورت تجزیه کند). روی صفحات وب اما هیکسون دارد به طور خاص درخواست عنصر نظر را رد کرد. در HTML5، مقاله‌ها به پایان می‌رسند.

<کنار>

Aside عنصر دیگری است که در هیچ کجای تحقیقات نام کلاس هیکسون دیده نمی شود و تعریف بسیار عجیبی برای راه اندازی دریافت می کند:

عنصر کناری نشان دهنده بخشی از a است page که شامل محتوایی است که به طور مماس با محتوای اطراف عنصر کناری مرتبط است و می تواند جدا از آن محتوا در نظر گرفته شود. چنین بخش هایی اغلب به عنوان ستون های کناری در تایپوگرافی چاپی نشان داده می شوند.

این عنصر را می توان برای جلوه های چاپی مانند نقل قول ها یا نوارهای جانبی، برای تبلیغات، برای گروه های عناصر ناوبری، و برای سایر محتوایی که جدا از محتوای اصلی در نظر گرفته می شود، استفاده کرد. page.

چه کسی می‌داند که چرا باید هم نقل‌قول‌های کششی، ستون‌های فرعی، تبلیغات و گروه‌های عناصر ناوبری را پوشش دهد، اما بخش‌های جدیدی در طرح کلی سند ایجاد می‌کند. این به این معنی است که نقل‌قول‌های کششی نقطه گلوله خود را در طرح کلی سند می‌گیرند، که مثلاً «عجیب» به نظر می‌رسد. باز هم، استفاده تصادفی از آن توسط طراحان وب با نیت خوب، خطوط کلی اسناد شکسته زیادی ایجاد کرده و خواهد کرد.

به نظر می‌رسد که عنصر nav واضح‌ترین عنصر در بین عناصر تقسیم‌بندی است، و خوشبختانه این تعریف فراتر از شکستن کشیده نشده است.

عنصر nav نمایانگر بخشی از a است page که به صفحات دیگر یا به بخش هایی در داخل پیوند می دهد page: بخشی با پیوندهای ناوبری.

که خوب است، و می‌تواند مزایای تئوری دسترسی داشته باشد (یک عامل کاربر می‌تواند از لینک‌های ناوبری عبور کند یا به آن بپرد – آنها این کار را نمی‌کنند، اما می‌توانند).

مشکل این است که با روحیه «ساده‌سازی تألیف» و جایگزینی div با عنصر nav، استایل ناوبری را برای زیرمجموعه دیگری از کاربران منفجر می‌کنیم. کاربران از IE6-8 با جاوا اسکریپت خاموش (تحقیقات یاهو نشان می دهد 1-2٪ از همه کاربران جاوا اسکریپت را خاموش کرده اند) قربانی این مشکل هستند. با خاموش بودن جاوا اسکریپت، شیم HTML5 مبتنی بر جاوا اسکریپت که به IE6-8 کمک می کند تا عناصر HTML5 را درک کند، کار نمی کند، بنابراین مرورگر به عناصر HTML5 استایل نمی دهد. این ممکن است تنها بر تعداد کمی از کاربران تأثیر بگذارد، اما چرا اصلاً آنها را تحت تأثیر قرار می دهد؟

و

عناصر سرصفحه و پاورقی یک مورد کلاسیک برای استفاده از اصطلاحات رایج و استفاده از آنها بسیار متفاوت است.

این مشخصات بیان می‌کند که هیچ یک از این عناصر بخش‌های جدیدی را در طرح کلی سند ایجاد نمی‌کنند، علی‌رغم این واقعیت که اغلب به‌عنوان روی همتراز با بخش، ناو، مقاله و کنار. در واقع آنها اصلاً کاری انجام نمی دهند. آنها فقط برای مشخص کردن مناطق یک بخش خاص در طرح کلی سند گنجانده شده اند.

در اینجا مشخصات در مورد هدر می گوید: عنصر هدر نشان دهنده گروهی از کمک های مقدماتی یا ناوبری است.

توجه: یک عنصر هدر معمولاً حاوی عنوان بخش (یک عنصر h1–h6 یا یک عنصر hgroup) در نظر گرفته شده است، اما این مورد نیاز نیست. عنصر هدر همچنین می تواند برای بسته بندی فهرست مطالب یک بخش، فرم جستجو یا هر لوگوی مرتبط استفاده شود.

و پاورقی: عنصر پاورقی نشان دهنده پاورقی برای محتوای برش یا برش اجدادی نزدیکترین آن است root عنصر پاورقی معمولاً حاوی اطلاعاتی درباره بخش خود است، مانند اینکه چه کسی آن را نوشته است، پیوندهایی به اسناد مرتبط، داده‌های حق چاپ و موارد مشابه.

در HTML5 عنصر بدنه در واقع همان است root عنصر بخش، بنابراین یک سرصفحه و پاورقی کلی برای توصیف آن در نظر گرفته شده است root بخش بدن هر بخش می تواند یک سرصفحه و/یا یک پاورقی داشته باشد – همانطور که ممکن است ما فرض کرده باشیم آنها فقط برای سرصفحه ها و پاورقی های کلی در نظر گرفته نشده اند. برای مثال، نظرات فردی می توانند هر کدام یک سرصفحه و پاورقی داشته باشند. در واقع همانطور که لمس کردیم روی قبلاً، این مشخصات در واقع نمونه‌ای از فوتر استفاده شده در یک نظر بالای محتوای نظر واقعی را نشان می‌دهد. درست است، نظرات در HTML5 مقالات هستند و می توانند یک پاورقی برای سرصفحه داشته باشند و این در مشخصات واقعی است. آیا یک عنصر پاورقی برای سرصفحه نظرات خود می خواستید؟ نه؟ خوب، شما یکی را دارید.

باز هم، اینجا جایی است که HTML5 اصطلاحات رایج را می‌پذیرد، و از آنها به روش‌هایی استفاده می‌کند که برای نویسنده معمول وب غیرقابل تشخیص است.

این بخش بندی است، چه چیزی کم است؟

اما چیزی وجود دارد که ما در اجرای بخش‌بندی HTML به آن توجه نکرده‌ایم. متوجه شدی؟ ما عناصر برش را داریم، اما عنصر h عمومی نداریم. نگران نباشید، راه حل این است در مشخصات:

بخش ها ممکن است حاوی سرفصل های هر رتبه ای باشند، اما نویسندگان به شدت تشویق می شوند که یا فقط از عناصر h1 استفاده کنند یا از عناصری با رتبه مناسب برای سطح تودرتوی بخش استفاده کنند.

HTML5 می‌خواهد با عقب سازگار باشد، بنابراین WHATWG تصمیم گرفت که یک عنصر h را معرفی نکند (علیرغم معرفی مجموعه‌ای از عناصر بخش‌بندی جدید)، و در عوض می‌خواهد عنصر h1 را به عنوان عنصر h عمومی تغییر کاربری دهد. از h1 در همه جا استفاده کنید، و اجازه دهید الگوریتم طرح کلی HTML5 سطح واقعی آن را تعیین کند… یا اینطور تئوری پیش می رود.

این یک ایده وحشتناک به چند دلیل است، دو مورد اصلی دسترسی و استایل است.

دسترسی

استفاده از h1 در همه جا برای دسترسی بسیار بد است. کاربران نابینا به شدت متکی هستند روی ساختار عنوان یک سایت برای همه ما مهم است که به ما یادآوری کنیم که ساختار سرفصل برای اهداف دسترسی چقدر مهم است. به عنوان مثال، یک دسامبر نظرسنجی سال 2008 از بیش از 1000 کاربر صفحه‌خوان انجام شده توسط WebAIM نشان داد که 76 درصد از کاربران نابینا و کم بینا «همیشه یا اغلب» زمانی که در دسترس بودند، بر اساس سرفصل‌ها پیمایش می‌کردند. و یک نظرسنجی در ماه مه 2012 نشان داد که 82.1٪ از سطوح عنوان هنگام پیمایش در وب “بسیار مفید” یا “تا حدودی مفید” هستند. page. (این یک تحقیق خوب و عملی است، پس توجه داشته باشید.)

وجود h1s در همه جا، پیمایش سایت ها را برای کاربران نابینا سخت تر می کند. در تئوری، صفحه‌خوان‌ها از الگوریتم ترسیم HTML استفاده می‌کنند و با استفاده از طرح کلی سند پیمایش می‌کنند، اما با توجه به روشی که به نویسندگان گفته شده است که عناصر برش‌بندی را پیاده‌سازی کنند، ترسیم کردن طرح‌ریزی یک آشفتگی است، و تلاش برای پیمایش طرح‌های کلی سند که هیچ فکری به حال آن نشده است. برای کاربران نابینا حتی بدتر باشد.

مشخصات HTML5 راهی برای خروج ارائه می دهد: به استفاده از سطوح مناسب h1-h6 برای حفظ سازگاری با عقب ادامه دهید. اما اکنون ما دو طرح کلی سند را در یک سند حفظ می کنیم، و با توجه به مشکلاتی که نویسندگان در وهله اول حتی در بررسی طرح کلی سند داشته اند، این احتمال وجود دارد که هر کسی هم یک طرح کلی h1-h6 منطقی و هم یک طرح منطقی را به درستی حفظ کند. طرح کلی HTML5 بخش بندی شده در بهترین حالت دور از دسترس به نظر می رسد.

یک ظاهر طراحی شده

اما بدتر می شود. بیایید بگوییم که می‌خواهیم با یک طرح کلی HTML5 خالص اجرا کنیم، و از h1s در همه جا استفاده می‌کنیم. به یاد داشته باشید، در مشخصات HTML5، h1 فقط یک عنصر h عمومی است. سطح واقعی آن با عمق تودرتو در عناصر برش تعیین می شود.

پس چگونه آن را استایل کنیم؟ خوب، ما می‌توانیم نام کلاس‌ها را به تمام عناصر h1 خود اضافه کنیم تا بتوانیم آنها را انتخاب کنیم، اما این برخلاف هدف HTML5 برای ساده‌سازی نوشتن است. و همچنین ممکن است به h1-h6 پایبند باشیم (که همه آنها به عنوان عناصر h عمومی در طرح کلی HTML5 در نظر گرفته می شوند).

ما می‌توانیم آنها را از طریق آبشار طراحی کنیم، اما این به سرعت پوچ می‌شود نیکول سالیوان اشاره کرده است. در واقع، “پوچ” فقط شروع به توصیف آن می کند. وقتی ترکیب های ممکن بخش، مقاله، nav و کنار را در نظر می گیرید و می خواهید یک استایل عمومی برای عنوانی که مثلاً پنج سطح عمق دارد (یعنی معادل h5) ایجاد کنید، باید برای همه استایل بنویسید. ترکیبات ممکن، که می شود کاملا مسخره. در اینجا استایل عمومی برای عنصر h3 آمده است:

article aside nav h1, article aside section h1, 
 article nav aside h1, article nav section h1, 
 article section aside h1, article section nav h1, article section section h1, 
 aside article nav h1, aside article section h1, 
 aside nav article h1, aside nav section h1, 
 aside section article h1, aside section nav h1, aside section section h1, 
 nav article aside h1, nav article section h1, 
 nav aside article h1, nav aside section h1, 
 nav section article h1, nav section aside h1, nav section section h1, 
 section article aside h1, section article nav h1, section article section h1, 
 section aside article h1, section aside nav h1, section aside section h1, 
 section nav article h1, section nav aside h1, section nav section h1, 
 section section article h1, section section aside h1, section section nav h1, section section section h1 { 
 font-size: 1.00em; 
 }

با این حال این چیزی است که عناصر ساختاری HTML به ما می دهند. چه افتضاحی

گرسنه برای بیشتر؟ بخش سوم این مقاله اکنون در دسترس است و کتاب لوک “حقیقت درباره HTML5” برای مدت محدودی از طریق سایت خواهر ما در دسترس است. MightyDeals.com با 50% تخفیف شگفت انگیز

آیا از عناصر مقاله چندین بار در یک سند استفاده می کنید؟ آیا بخش ها مفید هستند یا باید از div ها استفاده کنیم؟ نظرات خود را در نظرات با ما در میان بگذارید.

تصویر/تصویر کوچک ویژه، موارد استفاده تصویر ساختار از طریق Shutterstock.