شاید تا کنون HTML را نادرست به کار می‌بردید! – بخش دوم

بی‌نهایت Class و DIV، بیهوده و بی‌کاربرد

این مورد دست به دست با بخش قبلی پیش می‌رود، در این بخش نیز دروغ‌های بسیار، عملکردهای بد، و نادانی مطلق باعث کدهایی non-semantic و متورم می‌شود که دسترسی‌پذیری را از بین می‌برند.

بی‌خود DIVها را روانه‌ی کد خود نکنید. دست کم نخست تلاش کنید تا تگ‌های موجود را style بدهید. اگر دیگر tableها را برای یک section به کار نمی‌برید – مانند گالری تصاویر – از قرار دادن DIV برای ایجاد rowها دست بکشید، اجازه دهید. float wrapping/inline-block یا ;flex-wrap:wrap وظیفه‌ی ساخت rowها را به عهده گیرد. Span خالی را در شرایطی به کار نبرید که محتوای تولید شده می‌تواند همان کار را انجام دهد. بله، bootcrap با شیوه‌ی احمقانه‌ات برای ایجاد یک آیکون همبرگر، من به تو اشاره می‌کنم.

همین قضیه برای classها نیز وجود دارد. هم اکنون این دروغ آشکار گسترش یافته است – که حتی به نظر می‌رسد Google نیز آن را باور کرده است – که پر کردن هر المانی با classها، نسبت به زمانی که selectorهای CSS را به کار ببرید به شکلی جادویی در «render» یک صفحه «سریع‌تر» عمل خواهد کرد.

چیزی که از این مطلب یک دروغ می‌سازد این است که هر چه classها بیش‌تر باشند، فهرست classها و المان‌های دارای classای که مرورگر باید نگه‌داری کند بیش‌تر است. markup بزرگ‌تر باعث می‌شود صفحه زمان بیش‌تری برای load کد صرف کند، باعث می‌شود سرور سخت‌تر کار کند تا کد گفته شده را ارائه دهد، و باعث می‌شود کار parser زمان بیش‌تری ببرد.

در نتیجه همین دلیلی است که چرا چیزهای بی‌معنایی مانند BEM و ریختن classها به هر المانی، راه‌حل نیست. در بهترین حالت در یک وبسایت واقعی نه سودی دارد و نه ضرر.

و واقعا وقتی یک 486/66 با 8 مگابایت RAM و اجرای IE5 روی Win 3.x می‌تواند از پس Selectorها بربیاید، اعتراض به اینکه selectorهای تگ و combinatorها در CSS «کند» هستند، آن هم در عصر پردازنده‌هایی چند هسته‌ای و چند گیگاهرتزی، ادعایی مزخرف است. خنده‌دار است که مشابه این گونه بهانه و ادعای بی‌پایه‌ای را دیوانه‌هایی پراکنده می‌کنند که «tableها هیولا هستند و هرگز نباید آن‌ها را به کار ببرید».

طوفان

مثالی عالی از همه‌ی کاربردهای نابه‌جا و نادرستی که در بالا گفته شد را می‌توانید به خوبی در هر کدی که Bootstrap را به کار می‌برد مشاهده کنید، یا Bootcrap، آنگونه که برخی از ما آن را می‌خوانیم.

Bootstrap تا زانو در گِل فرو رفته و کاربردهای نادرست را شخم می‌زند، و همان‌گونه که از یک دهه‌ی پیش تا کنون گفته‌ام، تنها چیزی که می‌توانید از Bootstrap بیاموزید، این است که چگونه یک وبسایت را نسازید!

نمی‌خواهم تنها به Bootstrap اشاره کنم، بلکه چنین شکستی را می‌توان در هر فریمورکی از HTML یا CSS یافت. Tailwind ،w3.css، و غیره و غیره.

مثالی ساده را در نظر بگیرید، مانند «pricing»:

https://getbootstrap.com/docs/4.5/examples/pricing/
و به چنین گوهری از نادانی برخواهید خورد:

<div class="pricing-header px-3 py-3 pt-md-5 pb-md-4 mx-auto text-center">
  <h1 class="display-4">Pricing</h1>
  <p class="lead">Quickly build an effective pricing table for your potential customers with this Bootstrap example. It’s built with default Bootstrap components and utilities with little customization.</p>
</div><div class="container">
  <div class="card-deck mb-3 text-center">
    <div class="card mb-4 shadow-sm">
      <div class="card-header">
        <h4 class="my-0 font-weight-normal">Free</h4>
      </div>
      <div class="card-body">
        <h1 class="card-title pricing-card-title">$0 <small class="text-muted">/ mo</small></h1>
        <ul class="list-unstyled mt-3 mb-4">
          <li>10 users included</li>
          <li>2 GB of storage</li>
          <li>Email support</li>
          <li>Help center access</li>
        </ul>
        <button type="button" class="btn btn-lg btn-block btn-outline-primary">Sign up for free</button>
      </div>
    </div>

عجب افتضاحی! بی‌نهایت DIV بیهوده‌ی بی‌کاربرد، بی‌نهایت class بیهوده‌ی بی‌کاربرد، کاربرد سراسر بی‌معنا و بی‌مفهوم از headingها، کاربرد button برای چیزی که به نظر می‌رسد باید anchor باشد زیرا که نه درون یک form است و نه کارکرد آن وظیفه‌ی JavaScript.

چهار DIV نخست، کاری را انجام می‌دهند که یک tag به تنهایی برای آن کافی است، sectionها با یک H4 آغاز شده‌اند که از دید semantic بی‌معنا است، همان‌گونه که کاربرد یک H1 به عنوان جفت آن بی‌معناست. تگ‌ها زیرمجموعه‌ی کلاس‌های بسیار مناسبی هستند، اما چرا برای هر heading ،list، و buttonای classها را سرازیر می‌کنند؟ - باری دیگر – به وضوح آشکار است که کسانی که bootstrap را ساخته و نگه‌داری کرده‌اند، شایستگی نوشتن یک خط HTML یا CSS را ندارند.
این فهرستی فاجعه‌بار از شیوه‌هایی است که نباید یک وبسایت را بسازید! همه‌ی کدهای بالا کاری را می‌کنند که کد زیر انجام می‌دهد:

<section id="pricing">
 <h2>Pricing</h2>
 <p>
  Quickly build an effective pricing table for your potential customers with this Bootstrap example. It’s built with default Bootstrap components and utilities with little customization.
 </p>
 <div class="cards">
  <section>
   <h2>Free</h2>
   <ul>
    <li><strong>$0 <span>/mo</span></strong></li>
    <li>10 users included</li>
    <li>2 GB of storage</li>
    <li>Email support</li>
    <li>Help center access</li>
   </ul>
   <a href="#">Sign Up For Free</a>
  </section>

Semantic مناسب و کد کمتر. حالا دوباره به من بگویید که چقدر فریمورک‌هایی مانند Bootstrap برای کار کردن «ساده‌تر» هستند. اگر بخواهم خیلی رک باشم باید بگویم که اگر شما بر این عقیده استوار باشید – که به کار بردن فریمورک‌ها کار را آسان می‌کند - به اندازه‌ی کافی HTML و CSS را نمی‌دانید که بخواهید یک وبسایت بسازید، چه برسد به اینکه یک فریمورک انتخاب کنید.

نبود semantic مناسب در مثال‌های آن‌ها و همه‌ی کسانی که از آن‌ها پیروی می‌کنند، به کاربرانی که نیازمند دسترسی‌پذیری هستند می‌گوید که بروند رد کارشان. این باعث می‌شود که کار کردن با HTML سخت‌تر شود، باعث می‌شود که سرور برای ساختن HTML گفته شده سخت‌تر کار کند، و در بیش‌تر موارد – همان‌گونه که در rewrite مثال «آلبوم» اثبات کردم – اگر بیش‌تر نه، وادار به نوشتن همان میزان کدی می‌شوید که بدون به کار بردن فریمورک باید بنویسید.

چگونه نوشتن همان میزان کد، اگر بیش‌تر نه، «آسان‌تر» است؟ آشکار است که قطعا آسان‌تر نیست.

افرادی که می‌گویند این چیزها «آسان‌تر است» یا «برای مشارکت بهتر است»، باید سکوت کرده و یاد بگیرند که تا چه اندازه در اشتباه‌اند. این 100% یک خیال است، ساخته‌ی افراد که فریاد می‌زنند «واه واه، من نمی‌خوام HTML یاد بگیرم». این‌ها معمولا همان افرادی هستند که ادعا می‌کنند HTML «آسان» است و «یک زبان برنامه نویسی واقعی نیست».

اگر انقدر آسان است، چرا زحمت نمی‌کشند تا قوانین آن را یاد بگیرند و درست به کار ببرند؟!؟ واقعا آن‌هایی که طوطی‌وار، بیش‌تر از همه آن دو مورد را بیان می‌کنند، معمولا آن‌هایی هستند که نمی‌توانند HTML را درست بنویسند، حتی اگر جان‌شان به آن وابسته باشد.

چرا همه‌ی این‌ها انقدر بد است؟

برای تازه‌کاران به کار بردن فریمورک‌ها باعث می‌شود تا مفهومی که به عنوان «جدایی نمایش از محتوا» شناخته می‌شود نادیده گرفته شود. تفکیک نگرانی‌ها(separation of concern) همواره عملکردی خوب در برنامه‌نویسی است، اما در HTML و CSS، در مواردی سود می‌رساند که بسیاری از افراد تصور هم نمی‌کنند.

مانند کش کردن

HTML معمولا به میزان کمی در سمت کلاینت(client-side) کش می‌شود – اگر اصلا بشود – زیرا محتوا می‌تواند تغییر کند. هر چه بیش‌تر یک سایت به‌روز شود، این جمله درست‌تر است. اگر شما style را به markup منتقل کنید – مانند آن دروغ کاملا احمقانه درباره‌ی انتقال «above the fold style» به HTML – کم‌تر امکان دارد که کش بشود (above the foldبخشی از صفحه‌ی سایت است که نخست در پنجره‌ی مرورگر نمایش داده می‌شود، بدون اینکه اسکرول صورت گیرد). به همین دلیل است که نزدیک به 100% از مواردی که یک تگ <style> می‌بینید، و 99% از مواردی که ””=style را می‌بینید، شاهد نادانی توسعه‌دهنده آن هستید.

CSS برای کش کردن بسیار آسان‌تر است، بنابراین، هر چه بیش‌تر بتوانید از markup برداشته و به CSS منتقل کنید، به همان اندازه load، parse، و render سریع‌تری خواهید داشت. همچنین اگر برای هر نوع media، یک stylesheet یکپارچه را به کار ببرید، این مزیت می‌تواند در بین چندین صفحه گسترش پیدا کند.(چیزی که در ””=media در تگ Link قرار دارد، که اگر این attribute را حذف کنید یا برابر با ”media=”all قرار دهید، خراب کردید). این مورد چطور کمک می‌کند؟ شما می‌توانید ظاهر صفحه‌های فرعی را از پیش کش کنید(pre-cache)! به ازای مصرف کمی بیش‌تر از پهنای باند در نخستین load، می‌توانید هر صفحه‌ی دیگری را که افراد در سایت شما مشاهده می‌کنند، سریع‌تر load و render کنید!

در حقیقت بسیار سریع‌تر، به اندازه‌ای که با SPA و دیگر ترفندهای JavaScript رقابت می‌کند. من معمولا در مورد سایت‌های خودم، این پرسش را از افراد دریافت می‌کنم که می‌گویند:«اسکریپتی که loadها را مخفی می‌کند کجاست؟»، چون صفحه‌های فرعی تنها باید minimalist markup را بفرستند.

... یا دسترسی‌پذیری

برای باری دیگر، markup بدون semantic که بد یا نادرست یا خراب است، به هر قصد و نیتی که باشد، بی‌توجه‌ای نشان دادن به افرادی است که نمی‌توانند با بینایی خوب روبروی یک نمایشگر بنشینند. این اینترنت است، تنها چیزی که ما به عنوان web developer می‌توانیم به قطعیت بدانیم این است که ما نمی‌دانیم چه کسی و با چه نوع user-agentای قرار است سایت‌های ما را مشاهده کند.

از آن دسته از افراد ناخوشایندی نباشید که مرتب در مورد اینکه تجارت‌شان مجبور است برای سطح شیب‌دار ناتوانان هزینه کند غر می‌زنند، اما برای اینکه 1 متر را پیاده نروند در جاپارک ویژه‌ی معلولین پارک می‌کنند، یا حرف‌های از این قبیل می‌زند که «چرا نابینایان باید از اینترنت استفاده کنند؟» (نقل قولی واقعی از شخصی که به تازگی از کارش در یک alphabet soup” Federal Agency“ اخراجش کردم.)

به ویژه اکنون در زمانی به سر می‌بریم که الزامات قانونی، تحت قوانینی مانند ADA در US یا EQA در UK دیگر تنها به خدماتِ رفاهی عمومی، پزشکی، بانکی، و دولتی محدود نمی‌شود. به لطف دادگاه عالی US که از شنیدن و روی برگرداندن به پرونده‌ی Domino سر باز زد، اکنونی فصلی نو برای دادخواهی‌های دسترسی‌پذیری نسبت به وبسایت‌های خرده فروشی آغاز شده است.(پرونده‌ای که یک فرد نابینا، علیه سایت Domino به دلیل دسترسی‌پذیر نبودن، به دادگاهی عالی شکایت کرد.)

... یا بهینه‌سازی موتورهای جستجو

این نیز از مزایای semantic markup است، زیرا موتورهای جستجو چشم ندارند. یک ساختار مناسب برای document به آن‌ها کمک می‌کند تا صفحه‌ را هضم کنند، و به همین دلیل است که headingها معمولا رتبه‌ی بهتری نسبت به text دریافت می‌کنند. ترفند بهره بردن از آن این است که مرتبه‌های heading را درست به کار ببرید، وگرنه به جای بالا بردن رتبه‌ی سایت، سیلی‌ای به صورت‌تان خواهد بود.

در واقع semantic markup خوش‌ساخت و دارای ساختار درست، قطعاً روی دست ترفندهای به ظاهر خوب، اما نادرست و به‌دردنخور «کارشناس SEO» بلند می‌شود که در تلاش است تا به هر طریق آن‌ها را به خورد شما بدهد.

به ویژه در بلند مدت که ترفندهای به ظاهر خوبی که امروزه کار می‌کنند، مواردی هستند که Google و دیگر موتورهای جستجو در آینده از آن‌ها دست خواهند کشید. به همین دلیل است که افراد خل‌وضعِ دیوانه‌ی SEO هر بار که یک به‌روزرسانی تازه برای الگوریتم می‌آید، هم‌چون مرغ سربریده بی‌قرار می‌شوند، در حالی که توسعه دهندگانی مانند من، پاپ کورن به دست می‌نشینیم، به این احمق‌ها اشاره کرده و می‌خندیم.

گوشه‌ای از دلایلی که به مدت نزدیک به 14 سال تا کنون، وبسایتی نداشته‌ام که با به‌روزرسانی الگوریتم، تاثیر منفی روی ترافیک سایت داشته باشد. وقتی که ترفندهای به‌دردنخور را به کار می‌بری، در بهترین شرایط انتظار یک چک آب‌دار را از موتورهای جستجو داشته باش و در بدترین شرایط، فرو رفتن یک قوطی شستشو دهنده در حلقت. 

همه‌ی این‌ها برمی‌گردد به حرفی که Matt Cutts یک دهه و نیم پیش، هنگامی که به بخش Anti-abuse گوگل می‌رفت به ما گفت:

برای کاربر بنویسید، نه برای موتورهای جستجو.

و نوشتن برای کاربر یعنی نوشتن برای همه‌ی کاربران، نه تنها – باری دیگر – برای کسانی که با بینایی خوب روبروی یک نمایشگر نشسته‌اند.

به لحاظ بهینه‌سازی on-page، دو مورد از مهم‌ترین فاکتورها عبارت‌اند از:

1. نگارش خوش‌ساخت و منحصربه‌فرد محتوا
2. Semantic markup تا به user-agentها – مانند موتورهای جستجو – سرنخی بهتر از چیستی محتوا بدهد.

اغلب زمان‌هایی که می‌شنوید کارشناسان SEO دهان‌شان را به اعتراض به هر چیزی غیر از on-page باز می‌کنند، بیش از Ford Super De Luxe متعلق به Biff Tannen غرق در کثافت هستند.

آیا بیش از اندازه درباره‌ی اهمیت HTML اغراق نمی‌کنی؟

آه این مورد را همیشه از افرادی که چیزی نمی‌دانند می‌شنوم. خیر. HTML به دلایلی وجود دارد، در بسیاری از تجارت‌ها اگر آن دلایل را نادیده بگیرید عواقب قانونی دارد. HTML قواعد خودش را دارد. بر پایه‌ی هنجارهای(norm) نگارش حرفه‌ای بنا شده است. ناتوانی در پیروی از آن می‌تواند کاربران بالقوه را دور کند، نگه‌داری کد را سخت‌تر کند، تاثیر منفی در رتبه‌ی جستجو داشته باشد، و در کل بخش قابل توجه‌ای از دلیل شکست وبسایت‌ها در سال نخست آغاز به کارشان است.

مردم به دنبال میان‌بُرهایی می‌روند که به ظاهر خوب هستند و اما کورکورانه کدهای بد را کپی می‌کنند، زیرا فکر می‌کنند برای یاد گرفتن‌اش بسیار نادان هستند. اگر آن‌ها را به دنبال هر چه که می‌گوید «آسان است» بفرستید، خیال می‌کنند از چیزی که به نظر می‌رسد سخت‌تر است، اهمیتی هم ندارد که چه دروغ بزرگی باشد.

تبلیغاتِ چیزهایی مانند فریمورک‌ها که می‌گویند راه آن‌ها «آسان» است، در واقع اشاره می‌کنند که راه‌های دیگر «سخت» است. به شما می‌گویند که cross-browser development سخت است، و شما باور می‌کنید. آن‌ها با استفاده از انواع ادعاهای بی‌پایه‌ و پر زرق و برق تلاش کنند تا شما را در این ذهنیت فرو ببرند که بدون کمک آن‌ها برای انجام آن کار بسیار نادان هستید، یا بدون جادوی آن‌ها انجام آن کار «بسیار زمان‌بَر خواهد بود».

می‌دانی چیست؟ من چنین چیزی را درباره‌ی تو باور ندارم. بله، خود تو. فردی که اکنون دارد این را می‌خواند. در واقع من فکر می‌کنم تو انقدر باهوش هستی که همه‌ی این‌ها را یاد بگیری. و اگر یاد بگیری که چگونه HTML – و به دنبال آن CSS – را درست به کار ببری، خواهی دید که چگونه بیش‌ترِ چیزی که این صنعت به تو درباره‌ی web development می‌گوید، چیزی جز 100% دروغ نیست.

HTML پایه است، بنای کار شما. بدون آن ما یک web نداشتیم، و با کاربرد نادرست آن، شما یک بنای نااستوار خواهید داشت. شیوه‌ای که بیش‌تر مردم HTML را به کار می‌برند مانند ساختن غیر اصولی و نادرست زیربنای یک خانه است، بدون آزمودن زمین و شرایط آن. شگفت‌زده نشوید که اگر با وزش بادی بریزد، و سپس بارانی همه‌ی آن را با خود به چاه ببرد.

نتیجه‌گیری

برای وجود هر تگ HTML دلایلی آشکار وجود دارد، و این تگ‌ها بر پایه‌ی قواعد ساختاری رایج در هنجارهای نگارش بنا شده‌اند که – حداقل در آمریکا – در دوره‌ی پنجم(fifth grade) مدرسه در اوایل سال 80 پوشش داده شده است. قواعد، راهنمایی‌ها، و همه‌ی هدف HTML، دسترسی‌پذیر بودن برای بیش‌ترین تعداد کاربر ممکن است، هر کاری انجام می‌دهید – از روی ناآگاهی یا بی‌ادبی و احمق‌بودن تعمدانه - که در مقابل این هدف است، شما به سادگی مقصود ذاتی HTML را نقض می‌کنید.

از انتخاب تگ‌هاتان بر پایه‌ی ظاهر پیش‌فرض‌شان دست بکشید. از به کار بردن تگ‌ها برای جاهایی که معنا ندارند دست بکشید. از به کار بردن classها برای تکرار سبک احمقانه‌ی HTML3.2 دست بکشید. یاد بگیرید چگونه با شیوه‌های خوب، به درستی HTML را به کار ببرید، مانند progressive enhancement، تفکیک نگرانی‌ها، و همه‌ی دیگر کارهایی که شما قرار است با آن انجام دهید.

وگرنه به خودتان، سایت‌تان، و بازدیدکنندگان‌تان لطمه می‌زنید.

منبع