طی سال های گذشته توسعه دهندگان وب از سمت توسعه ساختار وب سایت های بر پایه ی Table به سمت طراحی وب سایت هایی بر پایه ی Div حرکت کرده اند . عجب ! حتماً میگید چه کاره خوبی ! اما صبر کنید. آیا توسعه دهندگان میدونند دلیلشون برای اینکار چیه و اصلاً چطور باید اینکار رو انجام بدن؟ اغلب به نظر میرسه ملت دارن از جهنمی به اسم Table دور میشن فقط برای اینکه به جهنم جدیدی به اسم Div وارد بشن.
در این مقاله در مورد مشکلات معمول در طراحی ساختار صفحات وب صبحت میکنیم . اول با یکسری مثال میخوایم ببینیم Table و Div چه کوفتی هستند اصلاً ؟ بعدش ببینیم چجوری یه کد تمیز و خوانا بنویسیم و در آخر مشخص کنیم انتظار میره کدوم یکی از این قابلیت ها در آینده بیشتر مورد استفاده قرار بگیرن! پس خواهش میکنم در این سفر از جهنم تا بهشت با ما همراه باشید.
جهنم Table
وقتی وب سایت شما برای اهداف طراحی از جداول استفاده میکنه شما در جهنمی به اسم table هستید. Table ها به طور کلی باعث افزایش پیچیدگی ، سخت تر شدن نگهداری ، کاهش انعطاف پذیری برای انطباق با رسانه های مختلف(مثل دستگاه های موبایل و غیره) و طراحی عناصر مختلف در صفحات وب میشن.
MAMA یک موتور جستجو از نرم افزار Opera هست که در صفحات وب میخزه و نتایجی رو با شرح ساختار صفحات ارائه میده. اگر به کلید های جستجوی MAMA توجه کنیم متوجه میشیم که عنصر Table در 80 درصد ساختار صفحات وب وجود داره.
در این خصوص اگه ساده بخوام توضیح بدم : Table برای نگهداری داده های جدولی (مثل لیست کالاهای یک انبار) استفاده میشه نه برای اهداف طراحی و ایجاد ساختار صفحات وب.
سهولت استفاده
استفاده از جداول برای طراحی ساختار، کاملاً بصری و قابل درکه . ما روزانه داده های جدولی زیادی می بینیم و مفهمومش رو به خوبی میشناسیم. از طرفی وجود صفات جدولی ، یادگیری رو نسبتاً ساده میکنه چون دیگه توسعه دهنده مجبور نیست از یک StyleSheet جداگانه استفاده کنه. اما در Div هیچ صفت آماده ای وجود نداره و توسعه دهنده مجبوره در زمان طراحی ، Style های جدیدی رو ایجاد کنه. در Table ها وقتی محتوا خیلی طولانی باشند خط شکسته نمیشه . مثل Div ستون ها زیر ستون های دیگه فشرده نمیشن و در کل باعث میشه احساس کنید Table ها امن و بدون دردسر تر هستن.
نگهداشت پذیری
Table دارای تگ های متفاوتی هست. خود تگ table به عنوان یک روپوش استفاده میشه. Tr برای ایجاد سطر ها و Td برای ایجاد ستون ها استفاده میشن. تگ های thead و tbody برای اهداف ساختاری استفاده نمیشند چون به محتوا خاصیت معنایی میدن. برای خوانایی بیشتر معمولاً هر تگ با رعایت تو گذاری (Tab) در یک خط نوشته میشه. ضمناً باید توجه داشت که خواص colspan و rowspan کد رو پیچیده تر هم میکنن.
|
1
2
3
4
5
6
7
8
9
10
11
12
13 |
<table cellpadding="0" cellspacing="0" border="0"> <tr> <td colspan="3" height="120px">....td> tr> <tr> <td valign="top">...td> <td valign="top">...td> <td valign="top">...td> tr> <tr> <td colspan="3">...td> tr> table> |
|
1
2
3
4
5 |
|
همونطور که در مثال بالا میبینیم ، کدهای بیشتری برای قالبی که با Table ایجاد شده نسبت به Div نوشته شده. حالا فرض كنيد همچنان كه كد بزرگتر ميشه اين تفاوت در اندازه، ثابت باقي بمونه . در ساختاری بر پایه Div هم میشه بی خیال menu div شد و در عوض از یک لیست نا مرتب (ul) به عنوان ظرف استفاده کرد.
جداول باعث میشن نتونید یک کد تمیز بنویسید و تا زمانی که بحث نگهداری داده های جدولی (مثلاً لیست اجناس یک انبار) مطرح نباشه ، استفاده از اونها برای طراحی صفحات هیچ معنایی نداره . مشکل دیگه Table ها اینه که باعث میشن جداسازی طراحی از محتوا سخت بشه. با توجه به نتایج MAMA ، خواص border ، width ، cellpadding و cellspacing در 90% از صفحاتی که از Table استفاده کرده بودند وجود داشته و این یعنی به جای اینکه خواص و استایل ها در style sheet ها قرار بگیرند ، مستقیماً در صفحه Html نوشته شده اند.
کدهای اضافی طراحی رو کند میکنن و باعث افزایش هزینه های نگهداری میشن. ضمناً در آینده باعث میشه درک کد شما برای دیگران و حتی خودتون سخت بشه. به یاد داشته باشید برای تعدادی خطوطی که یک برنامه نویس در طول ساعت میتونه بنویسه محدودیت وجود داره.
هرچی تعداد خطوط کد شما بیشتر بشه معنیش اینه که فایل بزرگتری هم خواهید داشت و متعاقباً زمان بیشتری برای بارگزاری صفحه نیازه. همچنین یک کد بزرگ نسبت به یک کد کم حجم ، باگ های بیشتری خواهد داشت. از طرفی توسعه دهندگان همیشه باید رسانه های جدید رو هم مد نظر داشته باشن. مثل دستگاه موبایل که معمولاً پهنای باند پایینی دارن.
انعطاف پذیری با رسانه ها
در یک جهان ایده آل، از یک نشانه گذاری مشابه برای همه چاپگر ها استفاده میشه. استفاده از جداول برای ساختار صفحات، کمترین انعطاف پذیری رو داره. کاربران شما ممکنه بخوان جدول های کناری رو به بالای صفحه منتقل کنن و یا مثلاً یک نمای چاپ، از سند در اختیار داشته باشند که در صورت استفاده از جداول، نتایج برای چاپ شدن، به صفحات اضافی جداگانه ای نیاز خواهند داشت و بر خلاف صفحات مبتنی بر Div که طراحی رو از محتوا جدا میکنن، استفاده از جداول برای اهداف طراحی، یعنی بالا رفتن هزینه توسعه و نگهداری کد.
نویسنده : Geir Wavik – گردآوری و ترجمه : مهران رسا
مطالب مرجع و تخصصی در زمینه سیستم عامل ویژه دانشجویان و محققین علوم کامپیوتری
فهرست اصلي
فهرست موضوعی
لینکستان
دانشجویان کامپیوتر دانشگاه آزاد
جامعه برنامه نویسان ایران
انجمن تخصصی ASP.NET
انجمن برنامه نویسی NET.
شبکه اجتماعی متخصصان
باشگاه مهندسان ایران
مرجع متخصصین ایران
مرکز توسعه نرم افزار
انجمن تخصصی فلش
باشگاه طراحان ایران
ادوبی فلش پلتفرم
کامپوننت و ابزارها
سورس و راهنما
آموزش فلش
آخرين نوشته ها
درباره سیستم عامل
ارتباط با پورت سریال در C#
addon domain در plesk
استیو جابز هم رفت!
آخرین رکورد بازبینی شده
مشکل نصب SQL Server 2005
سمینار درگاه پرداخت آنلاین
تفاوت متد های get و post
امنیت فایل های اجرایی NET.
نکاتی که در برنامه نویسی باید/میتوانند رعایت شوند
Tableدر برابر Div
سخنان طلایی برنامه نویسان بزرگ
رمزگذاری فایلها
کارگاه آموزش سیستم حروفچینی لاتک و زی پرشین
کتاب آموزش لاتک Latex
مقایسه دستورات DELETE و TRUNCATE
با Cloudflare امنیت و سرعت سایت خود را افزایش دهید
کتاب آموزش برنامه نویسی اسمبلی
چیست؟ nhibernate
معرفي فايل Web.Config
Eval شرطی
واکشی تعداد رکوردهای تمام جدولهای دیتابیس
واکشی نام تمام جدولهای دیتابیس
طرح روی جلد کتاب سیستم عامل سیلبر شاتس
کتاب برنامه نویسی و زبان اسمبلی - پیتر ایبل
کتاب آموزش ActionScript 3.0
حقیقت آزمایش !
افزونه های Reflector
جایگزین Reflector
sem چیست ؟
DESIGNED BY