از طریق منوی جستجو مطلب مورد نظر خود در وبلاگ را به سرعت پیدا کنید
حقیقت تلخ در مورد معناشناسی ساختاری HTML5 (قسمت 1)
سرفصلهای مطلب
حقیقت تلخ در مورد معناشناسی ساختاری HTML5 (قسمت 1)
عناصر ساختاری HTML – مقاله، بخش، ناوبری و کنار – در نگاه اول، برخی از سادهترین بخشهای مشخصات HTML5 برای درک و پیادهسازی هستند. با این حال، آنها در واقع برخی از ضعیفترین بخشهایی هستند که مشخصشدهترین، ضعیفترین و ضعیفترین بخشهای HTML5 اجرا شدهاند.
خودسرانه ایجاد شد؛ آنها سعی می کنند یک روش کاملاً جدید برای ساختاربندی صفحات وب معرفی کنند. آنها اصول طراحی خود HTML را نقض می کنند. آنها به دسترسی برخی از کاربران آسیب می رسانند. و شما نباید از آنها استفاده کنید.
بله، من با این بخش خاص از HTML5 مخالفت می کنم، اما لطفاً تصور نکنید که من “ضد HTML5” هستم. من کتابی در مورد HTML5 نوشته ام، من عاشق وب باز هستم، دوست دارم خوب استانداردهای وب، و من عاشق این واقعیت هستم که پس از یک دهه رکود، نوآوری در فناوری های وب اکنون با سرعتی کاملاً تاول آور اتفاق می افتد. با این حال، این بدان معنا نیست که ما باید هر چیزی را که به ما داده شده است بپذیریم. ما مجبور نیستیم همه چیز را بخوریم روی بشقاب HTML5، حتی اگر قسمت هایی از ظرف را واقعاً خوشمزه بدانیم. برخی از قطعات احتمالاً باید به سرآشپز بازگردانده شوند.
بخشهای خوب و بدی در مشخصات بسیار عظیم HTML5 وجود دارد، و ما میخواهیم به طور انتقادی در مورد یک بخش بسیار خاص از مشخصات فکر کنیم: بخشبندی یا عناصر ساختاری که HTML5 معرفی میکند. پس بیایید کلاه های کارآگاهی خود را بگذاریم روی و به این نگاه کنید که این عناصر جدید واقعاً از کجا آمدهاند، چگونه قرار است از آنها استفاده شود، و چگونه ما، جامعه طراحی وب، اساساً آنها را اشتباه درک کردهایم و اساساً مشخصات را از بین بردهایم. ما اساس این عناصر را زیر سوال خواهیم برد، و در طول مسیر، چند افسانه در مورد آنها را از بین خواهیم برد.
عناصر ساختاری HTML5 از کجا آمده اند؟
بیایید یک افسانه را که در مورد این عناصر تکرار شده است، از بین ببریم: این ایده که آنها بر اساس آن هستند. روی تحقیق در مورد اینکه چگونه ما، جامعه وب، اسناد خود را علامت گذاری می کردیم. این افسانهای است که سالهاست در کتابها، وبلاگها و گفتگوها تکرار میشود و درست نیست. از کجا بدانم؟ من پرسیدم.
وقتی در حال تحقیق در مورد ریشههای این عناصر بودم، تصمیم گرفتم از ویرایشگر مشخصات HTML5، Ian Hickson بپرسم که این عناصر از کجا آمدهاند. او پاسخ داد:
من و سایر مشارکت کنندگان WHATWG (آنها را اضافه کردیم)، (در) سال 2004، زیرا آنها عناصر واضحی بودند که باید پس از مشاهده روش استفاده نویسندگان از HTML4 اضافه شوند. ما بعداً (اواخر سال 2005 اوایل 2006) تحقیقات عینی انجام دادیم تا بفهمیم ده کلاس برتر HTML کدامند و معلوم شد که آنها اساساً دقیقاً با عناصری که ما اضافه کرده بودیم مطابقت دارند که راحت بود.
بیایید این را تجزیه کنیم: اول، هیکسون و اعضای WHATWG این عناصر را اضافه کردند قبل از انجام هر تحقیقی. شما می توانید در آرشیو لیست پستی WHATWG (خوشبختانه عمومی) شیرجه بزنید و بحث های اولیه در مورد این عناصر را برای خود کشف کنید. به عنوان مثال، می توانید ببینید که هیکسون در نوامبر 2004 درباره آنها بحث می کند، با نظراتی مانند این یکی:
بله، من قصد دارم مواردی مانند (عناصر معنایی) را در برنامه های وب قرار دهم. وایت برد در دفتر من در حال حاضر فهرستی از عناصر تحت عنوان “HTML5 BLOCK LEVEL ELEMENTS” دارد، و من سعی می کنم روش عملکرد آنها را به خوبی بررسی کنم (عناصر مورد نظر در حال حاضر در پیش نویس ذکر شده اند، اما پیش نویس هدرها را به هیچ وجه خوب مدیریت نمی کند). من هنوز به نشانه گذاری درون خطی نگاه نکرده ام، اما همین است روی کارت ها را نیز
به نظر میرسد معناشناسی ساختاری HTML5 چگونه به وجود آمد: یک مرد، یک تخته سفید و مقداری ورودی از سایر اعضای WHATWG. (WHATWG یا گروه کاری فناوری کاربردی ابرمتن وب، توسط نمایندگان مرورگر در پاسخ به کنار گذاشتن HTML توسط W3C برای ایده آل آرمان شهر XHTML 2.0 تشکیل شد).
به نظر میرسد عناصری که میلیونها سندی که در مورد آنها بحث و گفتگو کردهایم، بهطور خودسرانه ایجاد شدهاند. روی هوس ویرایشگر HTML5 در سال 2004. (و با یک نقد زیرکانه و برخی پیشبینیهای متأسفانه دقیق تقریباً بلافاصله.)
پشت سر جمعی
تانتک اصرار کرده است روی فرمتهای پژوهشی-پیش از-مشخص کردن- جدید برای مدت طولانی در زمینه میکروفرمتها، و در نهایت مشخصات WHATWG به طور مشابه با دادههای واقعی طراحی میشوند، به جای اینکه ما چیزها را از پشت سر جمعی خود بیرون بکشیم. – ایان هیکسون
این ما را به نکته دوم می رساند. در دسامبر 2005 – یک سال یا بیشتر بعد از این عناصر جدید را ارائه کرد—هیکسون (یکی از کارمندان Google) در مورد چگونگی تألیف اسناد با استفاده از پایگاه داده گسترده اسناد گوگل تحقیقاتی انجام داد. این تحقیق “تجزیه و تحلیلی از نمونه ای متشکل از کمی بیش از یک میلیارد سند، استخراج اطلاعات در مورد نام کلاس های محبوب، عناصر، ویژگی ها و ابرداده های مرتبط بود.” شناسنامه در تحقیق لحاظ نشده است. این یافته ها توسط گوگل به عنوان منتشر شده است آمار تألیف وب (2005).
بخش مهم تحقیق، تا آنجا که به عناصر ساختاری HTML مربوط می شود، این بود یافته های کلاس ها، که با وجود استفاده از نمونه ای که در آن حدود 900 میلیون از 1 میلیارد سند ظاهراً هیچ کلاسی نداشتند، حاوی کلاس های رایجی بود که مطمئنم همه ما قبلاً در پروژه های خود استفاده کرده ایم: پاورقی، منو، عنوان، کوچک، متن. ، محتوا، هدر، ناوبری، حق چاپ، دکمه، اصلی و غیره روی.
سپس هیکسون چرخش خود را فراهم می کند روی دادهها، نشان میدهند که این کلاسها در واقع به خوبی به عناصری که در HTML5 پیشنهاد میشوند (نقشهبرداری میشوند) و جدولی را ارائه میکند که یافتههای تحقیق و عناصر جدید در HTML5 را مقایسه میکند: پاورقی کلاس در تحقیق است، الف پاورقی عنصر در HTML5 است. الف هدر کلاس در تحقیق است، الف هدر عنصر در HTML5 است. کلاس ها متن، محتوا، اصلی، بدن در حال تحقیق هستند و اشتباه… مقاله در HTML5 است که همانطور که خواهیم دید، اصلا مطابقت ندارد. بخش به هیچ وجه یافت نمی شود، که همچنین شایان ذکر است.
با توجه به ارزش اسمی، این همه به اندازه کافی معقول است. من از فوتر استفاده می کنم، شما از فوتر استفاده می کنید، فوتر در HTML5 است. مشکل چیست؟
مشکل این است که اگر واقعی را بخوانید مشخصات HTML5، عناصر در HTML5 به گونه ای تعریف شده اند که ارتباط چندانی با روش استفاده سنتی ما از آنها ندارد.
از یک طرف، Hickson یک مفهوم کاملاً جدید از ساختار وب را معرفی کرده است page در HTML5 با عناصر برش. از سوی دیگر، هیکسون عناصر برشبندی HTML5 خود را با کلاسهایی که در طبیعت استفاده میشوند مقایسه میکند، بدون اینکه بفهمد آن کلاسها واقعاً برای چه چیزی استفاده میشوند. یک مثال کلاسیک “هدر” است که بیشتر ما از آن برای ناحیه بالای سر استفاده می کنیم page، اما مشخصات HTML5 نشان می دهد که می توانید از آن برای این کار استفاده کنید هدر از هر نظر روی الف page. واقعا فقط به این دلیل که کلاس ها در تحقیق و عناصر در HTML5 نام یکسان دارند، به این معنی نیست که کاربرد آنها یکسان است.
حال، اگر به صراحت گفته می شد که عناصر جدیدی با هدف جدید و منطق روشن معرفی شده اند، آنقدرها هم بد نبود. اما این چیزی نیست که به ما گفته شده است.
اینجاست هیکسون در سال 2009، در پاسخ به سؤالی در مورد هدف بخش، ناو، مقاله، کنار و موارد دیگر:
آنها کم و بیش متداول ترین درخواست های توسعه دهندگان وب را پر می کنند روی رایج ترین مقادیر مشخصه class=”” چیست؟ هدف اصلی آنها ساده کردن تألیف و سبک است.
متأسفانه، به نظر می رسد که این موردی است که ویرایشگر HTML5، با وجود تمام کارهای خوبش در جمع کردن مشخصات، فراموش کرده است (بیایید سخاوتمند باشیم) چرا این عناصر را به چیزی که اساساً مشخصات او است اضافه کرده است. شاید این تفاوت زمانی بین سال های 2009 و 2004 باشد، چه کسی می داند. اما ما این را می دانیم: عناصر بخش HTML5 به هیچ وجه برای پر کردن “متداول ترین درخواست های توسعه دهندگان وب” اضافه نشده اند. از کجا بدانیم؟ ما فقط می توانیم به لیست نگاه کنیم و ببینیم که اساسی ترین عناصر اضافه شده، مانند عنصر بخش (و مقاله مرتبط و عناصر کناری)، به هیچ وجه در تحقیقات ویژگی های کلاس رایج ظاهر نمی شوند.
اگرچه Hickson ممکن است فراموش کرده باشد که چرا این عناصر اضافه شدهاند، اما خوشبختانه هنوز میتوانیم مشخصاتی را بخوانیم که هدف آنها را مستند میکند.
اما وقتی به طراحان و توسعهدهندگان وب میگویید نگران نباشند، چه اتفاقی میافتد، این عناصر فقط جایگزین کارهایی میشوند که قبلاً انجام میدهید، و سپس این عناصر را به روشی مشخص کنید که مطمئنا نه طراحان و توسعه دهندگان وب چه کار می کردند؟ شما آنها را قرار دهید روی سفر یک طرفه به شهر سردرگمی
این بدترین نوع تحقیق است: تفسیر تنبلی از دادهها که برای توجیه تصمیمهایی که قبلا گرفته شدهاند انجام میشود. یک اصل طراحی مکرر HTML5 این است کهگاوچران ها را هموار کنید“، یعنی “وقتی رویه ای از قبل در بین نویسندگان رواج یافته است، به جای منع یا اختراع چیز جدید، آن را اتخاذ کنید.” و بنابراین با این عناصر ساختاری جدید به نظر می رسد: بخش، مقاله، ناوبری، و کنار (و سرصفحه و پاورقی) – مطمئناً اینها فقط «مسیر گاوچران را هموار می کنند»؟
این تصوری است که بسیاری از ما داریم، همانطور که به ما گفته شده است که آنها اینطور هستند.
در واقع، نزدیک به پنج سال پیش، زمانی که ما برای اولین بار یک پیش نمایش HTML5، به نظر می رسید که این عناصر به سادگی می توانند جایگزین div های «غیر معنایی» شوند که ما به استفاده از آنها عادت داشتیم. چی بود div id = “سرصفحه” در بالای page اکنون فقط می تواند تبدیل شود هدر; div id=”footer” اکنون فقط می تواند تبدیل شود پاورقی، و div ما فقط می تواند مقاله باشد. ساده است، درست است؟
ما مشخصات را چنگال کردیم
متأسفانه، با وجود انجام کاری که به ما گفته شد (یعنی فقط swap یکی برای دیگری)، ما در واقع این عناصر را به گونه ای پیاده سازی کرده ایم که در مشخصات HTML5 منعکس نشده است. یعنی وقتی نوبت به ساختار HTML5 میرسد، ما اساساً مشخصات را حذف کردهایم. در حال حاضر دو روش برای ساختار HTML5 وجود دارد – تفسیر جامعه، که در مقاله A List Apart در سال 2007 (و تعداد بیشماری دیگر) منعکس شده است. و مشخصات واقعی HTML5، که یک روش کاملاً جدید برای ساختار یک وب را معرفی می کند page طرح ریزی نامیده می شود.
این تناقض در دل معناشناسی ساختاری HTML است. از یک طرف، ما ویرایشگر را داریم که به ما می گوید عناصر جدید مبتنی هستند روی تحقیق در مورد آنچه قبلاً انجام می دادیم، و بنابراین قصد داریم تا نوشتن را کمی آسان تر کنیم. و روی از سوی دیگر، ما آنچه را ویرایشگر واقعاً در مشخصات HTML5 ایجاد کرده است، داریم، که روشی جدید برای ساختن یک وب است. page به گونه ای که الف را ایجاد می کند طرح کلی سند با استفاده از عناصر برش.
انتخاب روشنی در اینجا وجود داشت. اصول طراحی HTML5 را زیر پا بگذارید و چیز جدیدی را معرفی کنید، یا به سادگی از شیوه های نگارش واقعی پیروی کنید و عناصر را به گونه ای مشخص کنید که منعکس کننده تمرین طراحی وب باشد. هیکسون سعی کرد اولی را انجام دهد و آن را دومی نامید، و ما اکنون یک آشفتگی بزرگ داریم روی دست ما
گرسنه برای بیشتر؟ قسمت دوم این مقاله اکنون در دسترس است و کتاب لوک “حقیقت درباره HTML5” برای مدت محدودی از طریق سایت خواهر ما در دسترس است. MightyDeals.com با 50% تخفیف شگفت انگیز
آیا با عناصر ساختاری HTML5 کار می کنید؟ آیا آنها را مفید یا مانعی می دانید؟ در نظرات به ما اطلاع دهید.
تصویر/تصویر کوچک ویژه، موارد استفاده تصویر ساختار از طریق Shutterstock.
(برچسبها برای ترجمه )page
منتشر شده در 1403-10-06 03:18:03
منبع نوشتار