گرافیک و برندینگ

SVG: گرافیک برداری برای وب

viewBox و روش جاسازی SVG، نام قابل فهم، رنگ و پاک‌سازی فایل با نمونه کامل HTML برای یک نمودار برداری ساده.

1404/11/29 2 دقیقه مطالعه 1,875 بازدید

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

کار با SVG در وب فقط انتخاب گزینه export در نرم‌افزار طراحی نیست. اندازه، دسترس‌پذیری، روش جاسازی و اعتماد به منبع فایل بر نتیجه اثر دارند. فایل کوچکی که نام قابل فهم ندارد یا در اندازه کوچک جزئیاتش محو می‌شود، هنوز خروجی خوبی نیست. از طرف دیگر، SVG دارای ساختار پیچیده ممکن است از نسخه raster بزرگ‌تر شود. تصمیم را با نوع محتوا و شیوه مصرف شروع کنید تا قابلیت‌های فرمت به یک وعده کلی تبدیل نشوند.

ساختار تصویر را بشناسید

عنصر svg فضای تصویر را تعریف می‌کند و عناصر درون آن، شکل‌ها را می‌سازند. rect برای مستطیل، circle برای دایره و path برای مسیرهای عمومی به کار می‌روند. گروه‌بندی با g اجازه می‌دهد چند جزء با یک تنظیم مشترک مدیریت شوند. رنگ داخل شکل معمولاً با fill و خط دور آن با stroke کنترل می‌شود. این ویژگی‌ها می‌توانند در خود عناصر یا در CSS تعیین شوند. شناخت همین اجزای محدود، خواندن بسیاری از خروجی‌های ساده را ممکن می‌کند.

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

viewBox با اندازه صفحه فرق دارد

viewBox یک دستگاه مختصات داخلی تعریف می‌کند و چهار مقدار دارد: نقطه شروع افقی و عمودی، عرض و ارتفاع. برای نمونه، viewBox با فضای ششصد در صدوشصت می‌تواند در صفحه با عرض سیصد نمایش داده شود. مرورگر مختصات داخلی را با فضای نمایش تطبیق می‌دهد. width و height یا CSS اندازه بیرونی را تعیین می‌کنند. حذف viewBox از فایلی که باید تغییر اندازه دهد، می‌تواند رفتار مورد انتظار را مختل کند؛ قبل از پاک‌سازی، نقش هر ویژگی را بررسی کنید.

حفظ نسبت طول و عرض نیز مهم است. کشیدن یک نشان دایره‌ای برای پر کردن مستطیل، هویت شکل را تغییر می‌دهد. اگر فضای مقصد نسبت دیگری دارد، معمولاً بهتر است فضای خالی مدیریت شود یا ترکیب دیگری طراحی شود. preserveAspectRatio رفتار تطبیق را کنترل می‌کند، اما انتخاب مقدار آن باید بر اساس مقصد باشد. در مرجع viewBox رابطه مختصات و viewport توضیح داده شده است. اندازه واکنش‌گرا از یک ویژگی تنها به دست نمی‌آید؛ ظرف هم نقش دارد.

فایل مستقل یا inline؟

وقتی SVG با img نمایش داده می‌شود، مصرف آن به نمایش یک تصویر نزدیک است. می‌توانید برای تصویر معنادار alt بنویسید و فایل مستقل را در جاهای مختلف استفاده کنید. CSS صفحه به اجزای داخلی این فایل مانند یک SVG inline دسترسی معمول ندارد. اگر فقط نمایش یک لوگوی ثابت لازم است، همین محدودیت اغلب مسئله‌ای ایجاد نمی‌کند. برای آیکون‌های تکراری، هزینه نگهداری فایل و cache را هم در تصمیم لحاظ کنید، نه فقط کوتاهی markup صفحه را.

SVG inline بخشی از سند صفحه است و اجزای آن می‌توانند با CSS و JavaScript صفحه کنترل شوند. این روش برای نموداری که رنگ بخش‌هایش با وضعیت رابط تغییر می‌کند مناسب است، ولی تعداد عناصر سند را افزایش می‌دهد. شناسه‌های داخلی باید در تکرار مؤلفه یکتا باشند؛ دو gradient با یک id ممکن است ارجاع‌ها را مبهم کنند. شیوه جاسازی را قبل از طراحی API مؤلفه مشخص کنید. تغییر از فایل مستقل به inline فقط جابه‌جایی مسیر فایل نیست.

معنای تصویر را به کاربر برسانید

برای SVG معنادار، یک نام قابل فهم لازم است. در نمونه inline این مقاله، title نام کوتاه و desc توضیح تکمیلی دارد و aria-labelledby آن‌ها را به تصویر متصل می‌کند. title باید مفهوم تصویر را بگوید، نه نام فایل یا عبارت عمومی «تصویر». توضیح طولانی‌تر می‌تواند رابطه اجزا را روشن کند. حمایت فناوری‌های کمکی و روش مصرف متفاوت است، بنابراین انتخاب markup باید با نقش تصویر هماهنگ باشد. خود عنصر title جای همه توضیحات صفحه را نمی‌گیرد.

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

نمونه کامل یک نمودار ساده

نمونه زیر یک فایل HTML مستقل است. آن را با نام process.html ذخیره کنید و در مرورگر باز کنید. کتابخانه، build یا فایل تصویری جداگانه لازم ندارد؛ تمام شکل‌ها و سبک‌ها در همان فایل هستند. نمودار سه مرحله تحویل یک نوشته را نشان می‌دهد و متن زیر آن همان ترتیب را به صورت معمولی بیان می‌کند. هدف نمونه آموزش ساختار SVG است، نه ساخت یک سامانه مدیریت محتوا. برای تکرار این مؤلفه در یک صفحه، شناسه‌های title و desc را یکتا کنید.

<!doctype html>
<html lang="fa" dir="rtl">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>سه مرحله آماده‌سازی نوشته</title>
<style>
body{font-family:system-ui,sans-serif;margin:2rem;line-height:1.8;color:#17324d;background:#f5f7fa}
main{max-width:48rem;margin:auto;background:white;padding:1.5rem;border:1px solid #b9c7d4;border-radius:1rem}
svg{display:block;width:100%;height:auto}text{font-family:system-ui,sans-serif;font-size:20px;fill:#17324d}
</style>
<main>
<h1>آماده‌سازی نوشته</h1>
<svg viewBox="0 0 600 160" role="img" aria-labelledby="process-title process-desc" xmlns="http://www.w3.org/2000/svg">
<title id="process-title">از پیش‌نویس تا انتشار</title>
<desc id="process-desc">ترتیب مراحل از راست به چپ است: پیش‌نویس، بازبینی، انتشار.</desc>
<g fill="#edf3f8" stroke="#46657d" stroke-width="2">
<rect x="410" y="35" width="170" height="90" rx="12"/>
<rect x="215" y="35" width="170" height="90" rx="12"/>
<rect x="20" y="35" width="170" height="90" rx="12"/>
</g>
<g fill="none" stroke="#46657d" stroke-width="3">
<path d="M405 80H391M398 73L391 80L398 87"/>
<path d="M210 80H196M203 73L196 80L203 87"/>
</g>
<g text-anchor="middle" direction="rtl">
<text x="495" y="87">پیش‌نویس</text><text x="300" y="87">بازبینی</text><text x="105" y="87">انتشار</text>
</g>
</svg>
<p>نوشته ابتدا به صورت پیش‌نویس تهیه می‌شود، سپس بازبینی می‌شود و در پایان به انتشار می‌رسد.</p>
</main>
</html>

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

رنگ، خط و جزئیات در اندازه کوچک

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

رنگ داخل SVG می‌تواند ثابت باشد یا از currentColor پیروی کند. انتخاب دوم برای آیکونی که باید با رنگ متن یک دکمه هماهنگ شود مفید است. برای لوگو، تغییر خودکار رنگ همیشه مجاز یا درست نیست. هر تصویر قرارداد مصرف خودش را دارد. در نمودار نیز رنگ نباید تنها راه تشخیص وضعیت باشد؛ برچسب، الگوی خط یا شکل می‌تواند رابطه را تقویت کند. موضوع کنتراست و خوانایی با انتخاب فرمت پایان نمی‌یابد.

پاک‌سازی بدون تخریب معنا

ابزارهایی مانند SVGO می‌توانند metadata غیرضروری، برخی تکرارها یا جزئیات اضافی مسیرها را کاهش دهند. تنظیم پیش‌فرض را تضمین بی‌خطر بودن برای همه فایل‌ها ندانید. حذف idهایی که CSS یا JavaScript به آن‌ها وابسته است، رفتار را می‌شکند. کاهش دقت مختصات نیز در بعضی شکل‌ها مرز یا اتصال را تغییر می‌دهد. خروجی بهینه را با مرجع بصری مقایسه کنید و اطلاعاتی را که برای دسترس‌پذیری یا تعامل نیاز دارید نگه دارید. کوچک‌تر شدن فایل به تنهایی معیار موفقیت نیست.

منبع SVG هم مهم است. فایل SVG می‌تواند ساختارهایی فراتر از خطوط ساده داشته باشد و فایل دریافتی از کاربر را نباید بدون سیاست مشخص وارد سند صفحه کرد. برای سرویس پذیرنده فایل، روش sanitization و نمایش را از طراحی امنیتی همان سرویس تعیین کنید. حذف چند رشته با جست‌وجوی ساده جای parser و سیاست معتبر را نمی‌گیرد. این موضوع با SVG ثابت و کنترل‌شده‌ای که تیم خودش نوشته فرق دارد؛ درجه اعتماد و مسیر مصرف را روشن ثبت کنید.

انتخابی متناسب با نگهداری

وقتی تصویر ساده، ساختارمند و قابل تغییر است، SVG می‌تواند انتخاب مناسبی باشد. وقتی تصویر پر از بافت و پیکسل‌های نامنظم است، فرمت raster را هم مقایسه کنید. نسخه اصلی طراحی، خروجی وب و قرارداد مؤلفه را جدا نگه دارید تا تغییر بعدی قابل پیگیری باشد. برای کاهش حجم، از فرایند مقایسه و فشرده‌سازی تصاویر کمک بگیرید. نتیجه خوب، فایلی است که در مقصد واضح، قابل فهم و قابل نگهداری باشد؛ پسوند svg به تنهایی این ویژگی‌ها را تضمین نمی‌کند.

واکنش به این مقاله

اشتراک‌گذاری این مقاله:
دیدگاه‌ها 0
۰ / ۲۰۰۰

هنوز دیدگاهی ثبت نشده

اولین نفری باشید که نظر می‌دهد!