نقاط انقطاع (Breakpoint) منطقی برای طراحی ریسپانسیو (Responsive Design) قسمت سوم
ادامه از قسمت دوم
طراحی بصورت عملی
هنگامی که چندین سال پیش طراحی ریسپانسیو عمومیت یافت ، ما ابتدا شروع به طراحی وب سایت در حالت دسکتاپ می کردیم و سپس با افزودن media query برای نمایشگرهای کوچکتر ، در layout تغییر بوجود می آوردیم . کمی بعد متوجه شدیم که این روش ، صحیح نیست . حالا متوجه شده ایم که اگر طراحی CSS ها را از نمایشگرهای کوچک آغاز کنیم بهتر است . بزرگ شدن آسان است – درخت ها بزرگ می شوند ، بچه ها بزرگ می شوند – اما کوچک شدن نه . تا بحال پرس شدن قطعات را زیر دستگاه دیده اید ؟ امکان پذیر است اما بسیار مشکل .
در بیشتر موارد ، شروع طراحی با صفحات نمایشگر کوچک منطقی است . هنگام بزرگ شدن صفحه نمایش فقط کافیست چند media query به صفحه اضافه کنیم تا وب سایت ، برای نمایشگرهایی با اندازه بزرگتر بهینه شود . اما من معتقدم امروزه نباید طراحی را از "نمایشگر کوچک" آغاز کنیم بلکه باید طراحی را از "نمایشگر پیش فرض" آغاز کنیم .
شروع از نمایشگر پیش فرض
اولین قدم در ایجاد شکل یک وب سایت ، لزوما طراحی استایل برای نمایشگرهای کوچک نیست بلکه طراحی استایل برای نمایشگر پیش فرض است و آن عبارتند از استایل هایی که بدون توجه به اندازه نمایشگر ، در صفحه وب استفاده می شود .این المانها عبارتند از : ارتباط میان اندازه فونت ها ، نحوه پراکندگی فضای خالی و استایل های مانند border ها و background ها . این استایل ها نباید داخل media query ها قرار بگیرند زیرا در تمامی نمایشگرها ، یکسان دیده می شوند .چیزی که لازم است داخل media query ها تعریف شود ، استثناء ها هستند ( مانند اندازه سایز کوچکتر ) و مواردی که لازم است به استایل های پایه اضافه شوند ( مانند ستون های جانبی ) .
با توضیح بالا مشخص می شود که در مورد نمایشگرهای کوچک ، فقط زمانی نیاز به media query داریم که المان هایی در اندازه های کوچک رفتار غیر عادی از خود نشان دهند . اگر کمی فکر کنید ، این مورد بارها اتفاق افتاده است . مثلا ، هدرهای پیج ، navigation ها و سایر اجزاء پیچیده سایت ، اغلب در سایز های کوچک بصورت اساسی تغییر شکل می دهند . در این گونه موارد بهتر است کدهای مربوط به این المان ها را در کوئری media max-width @ قرار دهید ، مانند مثال اولی که با هم انجام دادیم ، زیرا این موارد جزء استثناء ها هستند .
جزییات نهایی
مثالی که برایتان زدم خیلی ساده بود و زیاد در مورد جزییات آن توضیح ندادم . دو تا از این جزئیات بسیار مهم هستند ، آنقدر مهم که لازم است در اینجا در مورد آنها توضیحات کامل بدهم . اولی استفاده از واحد em در media query ها است و دیگر breakpoint ها .
دامنه شکست (Break ranges)
در این اواخر صحبت های زیادی در مورد عبارت “Breakpoint” گفته شده ، Mark Boulton و Ben Callahan معتقدند ، این نقاط را باید "نقاط بهینه سازی" (optimization points) بنامیم ، همچنین Jeremy Keith می گوید باید میان Breakpoint ها و Tweakpoint ها تفاوت قائل شویم . در این مقاله ، تمرکز من بر روی breakpoint ها است یعنی نقاطی که در آنها با افزایش و یا کاهش اندازه صفحه نمایش تغییرات عمده ای رخ می دهد . و حالا عبارت دیگری را برایتان توضیح می دهم ؛ " دامنه شکست " یا Break ranges .
ما از عبارت breakpoint برای media query هایی استفاده می کنیم که نمایش صفحه را تغییر می دهند . ما از این نقاط برای ایجاد تغییرات مستقیم استفاده می کنیم ؛ هنگامی که یک layout به عرض ماکزیمم خود می رسد ، بلافاصله به layout بعدی تبدیل می شود . اما اگر صفحه ما در این نقاط قبل از تغییر به layout بعدی با افزایش سایز ، کمی فضای سفید و خالی ایجاد کند و سپس به layout بعدی برود حرفه ای تر به نظر می رسد . برای مثال تغییر از layout تک ستونی به دو ستونی ، منجر به ایجاد یک ستون اصلی کوچک خواهد شد . به جای اینکه در یک نقطه ماکزیمم ناگهان تمام layout تغییر کند ، می توانیم یک تعلیق کوچک به این تغییر بدهیم . دقیقا مانند این مثال . این ، یک حقه کوچک است که باعث می شود layout ناگهان تغییر نکند .
( خوانندگان گرامی ، برای لمس این موضوع بهتر است حتما فایل CSS این مثال را بدقت بررسی کنند . منظور نویسنده فاصله بین 51 em و 58 em است که باعث ایجاد یک مارجین قبل از تغییر layout در media query ، 58 em می شود ).
استفاده از واحد em در media query ها
استفاده از واحد em در مدیا کوئری ها ممکن است عجیب و غریب باشد. احتمالا تصور می کنید که این واحدها به اندازه فونت تعریف شده در CSS واکنش نشان می دهند ، اما این تصور شما اشتباه است . استفاده از این واحد باعث واکنش ، نسبت به سایز فونت مرورگر کاربر می شود .اگر کمی در موردش فکر کنید آن را بدیهی می یابید . اگر media query ها نسبت به فونت تعریف شده CSS واکنش نشان می دادند ، شما می توانستید به سادگی یک مدیا کوئری را با افزایش سایز فونت در داخل خودش ، از کار بیاندازید .در اینصورت کد پایین باعث ایجاد یک loop بی پایان می شد :
استفاده از em
در صورتی که media query با سایز فونت تعریف شده در CSS واکنش نشان می داد ، هنگامی که ما به آرامی اندازه پنجره مرورگر را افزایش می دادیم چه اتفاقی می افتاد ؟ به محض اینکه اندازه پنجره مرورگر به 20 ems می رسید ، سایز فونت دو برابر می شد و این بدان معناست که عرض صفحه حالا 10 ems می باشد که باعث می شود مرورگر media query را نادیده بگیرد و منجر به ایجاد اندازه فونت کوچکتر می شود و دوباره باعث می شود media query فعال شود و دوباره و ... . این یک چرخه بی پایان است (Endless loop) .
این موضوع که اندازه em داخل مدیا کوئری از اندازه فونت پیش فرض مرورگر تاثیر نه فقط از لحاظ تکنیکی ، بلکه از کاربردی نیز منطقی است زیرا در صورتی که کاربران بصورت پیش فرض از فونت های بزرگتر استفاده کند ، layout همیشه بر اساس اندازه فونت بهینه شود . و این دقیقا همان هدفی است که تمام تلاشهای ما برای رسیدن به آن است . در عین حال این موضوع ، می تواند یک عامل گیج کننده برای افرادی مانند من باشد : اندازه em که مدیا کوئری استفاده می کند ، می تواند با مقدار تعریف شده برای em داخل همان media query کاملا متفاوت باشد و این کمی پیچیده است . در صورتی که اطلاعات بیشتری در این رابطه می خواهید به مقاله “The Ems Have It : Proportional Media Queries FTW!” مراجعه کنید .
موضوعی که همیشه مرا آزار می دهد اینست که ما نیاز به یک ابزار ساده برای تخمین تعداد کاراکترهای موجود در یک خط داریم . مثلا مرورگر WebKit به تازگی واحد “ch” را بکار می برد و احتمالا کمی زمان می برد تا این واحد و استفاده از آن متداول شود . یک ch برابر است با عرض یک 0 ( صفر ) با فونت پیش فرض . این ابزار برای طراحی ریسپانسیو به نظر فوق العاده می آید ، البته من تابحال از آن برای تعریف media query ها استفاده نکرده ام اما بزودی این کار را می کنم .
مخلص کلام
در حالت ایده آل ، ایجاد grid های مختلف برای نمایشگرهایی با سایز های متفاوت فقط بر اساس محتوا انجام می شود . اما بعضی اوقات ، المان هایی از جمله بنرها و ... معیار اصلی برای تعیین عرض محتوا هستند . حتی در اینگونه موارد ، تئوری خوانایی به کمک ما می آید به اینصورت که می توانیم با افزایش و کاهش سایز فونت ، به عرض صفحه ایده آل دست پیدا کنیم. فقط ! سایز فونت را خیلی کوچک نکنید ، ملت می خواهند آن را بخوانند .
خوشبختانه ، غیر از موارد استثناء ، تئوری کلاسیک تایپوگرافی می تواند مقادیر منطقی breakpoint ها را برای وب سایت ریسپانسیو ما تعیین کند . همچنین می توانید برای سایت های چند زبانه layout های متفاوت تعریف کنید . از همه مهمتر با استفاده از تئوری های ارائه شده در این مقاله طراحی های بهتر و کاربردی تری برای نمایشگرهایی با سایزهای مختلف ایجاد کنید . مثالی که من زدم از یک سری grid های بسیار ساده استفاده کرده بود ، اما هنگام ترکیب با grid های پیچیده ، این تئوری layout منطقی و فوق العاده ای برای وب سایت ریسپانسیو ایجاد می کند .
