RichStyle: The Angel is in The Detail.
صورة غلاف مجردة فيها أيقونات للاحتياجات الخاصة.

بين خطوط الأيقونات ورسومات SVGالدليل الكامل لأيقونات الويب القابلة للوصول

تمهيد

يطرح كثير من مصممي ومطوري الويب هذه الأيام صيغة الصور الشعاعية المتدرجة SVG كحل بديل لتقنية الخطوط المستخدمة لتمثيل الأيقونات في عالم الويب. فإلى أي حد يعد هذا القرار حكيماً وصائباً؟

هذا ما تحاول هذه المقالة الإجابة عنه.

بداية، ننطلق في دراستنا هذه من فرضيتين اثنتين:

مصطلحات

الأداء Performance

نقصد به —في سياق هذه المقالة— قلة عدد طلبات HTTP عند تحميل الأيقونات. عملياً، يتمثل الأداء المثالي باقتصار عملية استدعاء الأيقونات على طلب HTTP وحيد.

جدول المحارف الخاصة Private Use Area (أو PUA اختصاراً)

أحد جداول محارف الترميز الموحد Unicode، ويقع ضمن المجال U+E000-F8FF، وهو مخصص للسماح لمطوري الخطوط بإدراج رموز غير قياسية.

ثمة أيضاً جدولين آخرين لذات الغرض:

  • الجدول الإضافي A للمحارف الخاصة: Supplementary Private Use Area - A، ويقع ضمن المجال U+E0000-FFFFF.
  • الجدول الإضافي B للمحارف الخاصة: Supplementary Private Use Area - B، ويقع ضمن المجال U+100000-10FFFF.
حاوية SVG (أو SVG Container)

أيُّ صيغة من صيغ الملفات تسمح بتخزين مجموعة من أيقونات ورسومات SVG في ملف واحد.

خانة محرف Code Point

أيُّ قيمة ضمن نطاق Unicode codespace؛ أي ضمن نطاق الأعداد الصحيحة من 0 إلى 10FFFFhex (أي في النظام السداسي العشري). تمثل هذه القيمة الوحدة الأولية للسلسلة النصية.

لا تقترن جميع خانات المحارف Code Points بمحارف Characters بالضرورة. وإنما ثمة سبع فئات أساسية لخانات المحارف Code Points في معايير Unicode:

  1. رسومية Graphic (الاستخدام الأكثر شيوعاً): تخزن خانة المحرف Code Point صورة لحرف Glyph، وهو تمثيل بصري لمحرف (محرف من قبيل حرف أو رقم أو علامة ترقيم أو رسم رمز بصري Pictograph).
  2. تنسيق Format.
  3. تحكم Control.
  4. استخدام خاص Private-Use.
  5. بديل Surrogate.
  6. غير محرفي Noncharacter.
  7. محجوز Reserved.
رسومات الأحرف Glyphs في خانات الأحرف Code Points: مقارنة بين خطي Libration Sans و Libration Serif font.
الفرق الرئيسي بين خط وآخر: اختلاف الرسم glyph في الخانة الواحدة code point.
رمز تعبيري Emoji

رمزٌ symbol مشفر (مفهرس) رسمياً ضمن معيار Unicode. وهو ملون عادة. ويمكن أن تكون صيغة الجمع له emoji أو emojis، بيد أن منظمة Unicode تستخدم الكلمة emoji كصيغة للجمع.

يمكن أن يكون الرمز التعبيري تعبيراً انفعالياً emotional expression، أو فعلاً، أو كائناً، أو حتى رمزاً مجرداً.

يعرض الجدول التالي نبذة مختصرة حول الرموز التعبيرية.

نبذة مختصرة حول الرموز التعبيرية
النحت المصدر المعنى بالانجليزية الوصف المبتكِر السنة مثال
Emoticon emot + icon emotion + icon رمز انفعالي عمودي مدوَّن باستخدام مزيج من أحرف لوحة المفاتيح الاعتيادية. Scott Fahlman ١٩٨٢ :-)
Kaomoji kao + moji face + character رمز انفعالي أفقي مدوَّن باستخدام مزيج من أحرف لوحة المفاتيح الاعتيادية. Kim Tong Ho ١٩٨٦ ^_^
Pictograph رمز Symbol مشفر (مفهرس) رسمياً ضمن معيار Unicode. ١٩٩٣
Emoji e + moji picture + character نسخة ملونة من رسم مصوَّر pictograph. Shigetaka Kurita ١٩٩٩ 🙂

ملاحظات إضافية:

  • الرمز الانفعالي Emoticon: ظهرت رموز الانفعالات/المشاعر Emoticons عملياً على نظام الحاسب PLATO IV عام ١٩٧٢.
  • الرمز الانفعالي الأفقي Kaomoji: نَسَبَ Kim Tong Ho هذا الابتكار لنفسه، ألا أن البعض يرى أنه لا يملك دليلاً كافياً على زعمه.
  • الرمز المصوَّر Pictograph: حينها، أي في عام ١٩٩٣، لم يكن ثمة سوى بضعة رموز مصوَّرة pictographs عندما تم إصدار Unicode 1.1.
  • الرمز التعبيري Emoji: لم يجرِ تشفير الرموز التعبيرية (فهرستها في جداول يونيكود) حينها، وإنما جرى تشفيرها رسمياً كرموز تعبيرية Emoji اعتباراً من عام ٢٠١٠، عندما تم إصدار Unicode 6.0.
صورة المحرف البديل Replacement Glyph

صورة حرف glyph تُستخدم لعرض حرف يتعذر عرضه بصورته الصحيحة في خط معين، وغالباً ما يظهر كمستطيل مفرَّغ أو مصمَت. يُعرف أيضاً بالاسم missing glyph، أي صورة المحرف المفقود.

مصطلحات يونيكود
صورة مجمَّعة Spritesheet

ملف صورة يمثل حاوية لمجموعة من الصور المرصوفة جنباً إلى جنب، بحيث تشكل بمجموعها صورة واحدة مجمَّعة من مجموعة صور.

يمكن أن تكون هذه الصورة نقطية؛ بصيغة PNG أو JPG أو GIF، أو شعاعية؛ بصيغة SVG، إلا أن الغالب في الصور المجمَّعة أن تكون نقطية.

لقطة لملف أيقونات غوغل القديمة كصورة مجمَّعة Spritesheet.
أيقونات غوغل القديمة مجمَّعة في ملف صورة وحيد بصيغة PNG
قابلية الصيانة Maintainability

نقصد بها —في سياق هذه المقالة— القدرة على تعديل الشيفرة البرمجية من خلال محرر نصوص بسيط أو محرر صور بسيط، دون الحاجة لبرامج وأدوات إضافية خاصة.

قابلية الوصول (أو سهولة المنال) Accessibility

تعني بالنسبة للأيقونات القدرة على التعبير عن الأيقونة بسلسلة نصية ذات دلالة على طبيعة الأيقونة ووظيفتها. في رموز يونيكود، يتمثل النص ذو الدلالة بالوصف المرافق للرمز في جداول يونيكود الرسمية، أما في ملفات SVG فيمكن أن يتمثل بمعرفات الأجزاء Fragment Identifiers في الصورة المجمَّعة Spritesheet، أو بمحتوى الوسم <title> في ملف SVG المفرد.

تساعد قابلية الوصول للأيقونة المستخدمين ذوي الاحتياجات الخاصة (ذوي الإعاقة البصرية تحديداً) على التعرف صوتياً على فحوى الأيقونة ودلالتها بالاستعانة ببرمجيات تدعى قارئات الشاشة، مخصصة لهذه الفئة من المستخدمين، كما تساعد محركات البحث على فهم فحوى الأيقونة ودلالتها، الأمر الذي يجعل من مسألة الدلالة تلك مسألة في غاية الأهمية —كما هو معلوم— بالنسبة لأصحاب المواقع الالكترونية.

ولك أن تتخيل محركات البحث كفئة من المستخدمين ذوي الاحتياجات الخاصة، لكن على أن متطلباتها تنتمي إلى فئة متطلبات المطور لا المستخدم عملياً، لأن محرك البحث ليس مستخدِماً بشرياً، وليس ثمة ما يلزمك بتلبية متطلباته سوى حرصك على جذب المستخدمين الحقيقيين والنهائيين إلى موقعك.

تمثل قابلية تكبير حجم الأيقونة Scalability جانباً آخر من جوانب قابلية الوصول للأيقونات، حيث تساعد المستخدمين ذوي الاحتياجات الخاصة (الذين يعانون من ضعف البصر تحديداً) على رؤية الأيقونات بحجم أكبر.

نموذج مبسط لقابلية الوصول لصفحات الويب Web Accessibility
نموذج قابلية الوصول لصفحات الويب
Web Accessibility Model
[مصممو الأيقونات]
قابلية تغيير الحجم Resizibility

نقصد بها —في سياق هذه المقالة— القدرة على تغيير حجم الصورة من خلال:

قابلية تكبير حجم الصورة Scalability

القدرة على تكبير حجم الصورة دون أن تتعرض للتشوه. وتمثل أحد جوانب قابلية الوصول للأيقونات.

معرف الأجزاء Fragment Identifier

سلسلة نصية داخل الصورة المجمَّعة Spritesheet بصيغة SVG، تستخدم لتعريف جزء من الصورة الكلية (صورة فرعية) بشكل فريد.

يتمثل معرف الأجزاء في ملفات SVG إما بالوسم <view> أو بالخاصية ID أو بكليهما معاً.

نظرة تاريخية

ثمة فئتين من الحلول لتمثيل الأيقونات على الويب:

الحلول القديمة: الصور النقطية Raster Images

من أكثر صيغها شيوعاً PNG و JPG و GIF، ومؤخراً الصيغة WebP. العيب الرئيسي لهذا النوع من الصور أنها ثابتة الحجم لا يمكن تكبيرها دون تشوهها. ويمكن استخدام هذا النوع من الصور بطريقتين:

الحلول الحالية: الصور الشعاعية Vector Images

وهي صور صالحة للتكبير scalable، ولها صيغتان رئيسيتان:

بلا شك، سنستبعد هنا فئة الحلول القديمة التي تعتمد على الصور النقطية ثابتة الحجم Rasters، ونحصر دراستنا في الفئة الثانية من الحلول: الحلول الدارجة، والتي تحقق التزاماً أفضل بمتطلبات قابلية الوصول؛ ممثلة بالخطوط، وبحاويات SVGs.

فئات الأيقونات

قبل الخوض في الحلول المتاحة والمفاضلة بينها، دعونا نحاول فرز الإيقونات والرموز المتداولة في عالم الويب حالياً وفق ما تنطوي عليه من خصائص وسمات وما تؤديه من وظائف ومهام.

وظيفياً، يمكن تقسيم الأيقونات إلى ثلاث فئات:

ومن حيث الخصائص والسمات، يعنينا عاملان اثنان:

وعليه، يمكن تصنيف فئات الأيقونات على النحو التالي:

فئات أيقونات الويب
المعيارية تعدد الألوان
أيقونات واجهة الاستخدام UI
الشعارات التجارية
أعلام الدول

فالشعارات التجارية، خلافاً لأيقونات واجهة الاستخدام وأعلام الدول، تخضع لما تخضع له المنظمات التجارية التي تقف وراءها من تغيير وتبديل وصعود وأُفول واندماج، فلا يرجى لها أصلاً أن تكون مدرجة في جداول يونيكود.

من جهة أخرى، تظل الفئة الأولى (فئة أيقونات واجهة الاستخدام) الفئةَ الوحيدة التي يملك المصمم فيها حرية التلوين من عدمه، أما الشعارات التجارية وأعلام الدول، فلا يملك المطور من حيث المبدأ التدخل في تصميم أي منها أو التعديل عليه، بل يظل محكوماً بإرادة الجهة التي صممت الشعار أو العَلَم أصلاً.

أما تمثيل أعلام الدول بواسطة محارف يونيكود، فيجري عادة من خلال استخدام رموز الدول وفق معيار ISO-3166، كالرمز US للولايات المتحدة، والرمز DE لألمانيا… الخ، ولكن بالاستعانة بمحارف تدعى Regional Indicator Symbol Letters بدلاً من محارف ASCII المألوفة، وتقع ضمن النطاق U+1F1E6-1F1FF، فيشار للولايات المتحدة عندئذ بالرمز 🇺🇸، ولألمانيا بالرمز 🇩🇪… وهلم جراً. أما عن كيفية تحويل هذه الرموز إلى أعلام للدول فسنتكلم عنها لاحقاً.

لقطة من برنامج GNOME Character Map لمجموعة المحارف Regional Indicator Symbol Letters
مجموعة المحارف Regional Indicator Symbol Letters

لمعاينةٍ مثلى لطريقة عرض أعلام الدول وفق هذه الطريقة استعن بنسخة حديثة من Firefox لاستعراض الصفحة التالية: Color.TypeKit.com/#Flags

إذا كان الخط Noto Emoji مثبتاً على جهازك، فستلاحظ أن رمز كل من الولايات المتحدة وألمانيا قد تحولا فعلاً إلى صورة العلم الموافق، ولكن دون تلوين، أما إن كان الخط Noto Color Emoji مثبتاً، فسيظهر العلمان ملونَين (باستخدام فيرفوكس حتى لحظة كتابة هذه السطور). يَستخدم الخطان Noto Emoji و Noto Color Emoji لهذا الغرض تقنية الواصلات Ligatures التي سنتطرق إليها لاحقاً.

تقنية الخطوط

يحتج منتقدو عملية استخدام الخطوط لتمثيل الأيقونات بأنها مجرد حيلة تقنية Trick لا ترقى لصفة الممارسة المعيارية، وبأن بحسبنا دليلاً على ذلك تفشي ظاهرة المستطيلات الفارغة عند انتظار تحميل الخط أو الفشل في تحميله.

مستطيلات فارغة في شاشة تسجيل الدخول إلى تويتر.
ظاهرة المستطيلات الفارغة قبل اكتمال تحميل صفحة الويب.

ولقد كان لهم في ذلك كل الحق قبل بروز ظاهرة الرموز التعبيرية (الإيموجي Emoji) ودعم معيار يونيكود المتنامي لها، أما اليوم، فيكفي أن يكون المصمم حريصاً على استخدام العناوين الصحيحة لتلك الرموز في الخط المستخدم، وفق معيار يونيكود، ليضمن بذلك المطابقة بين الأيقونات من طرف المزود ومقابلاتها من طرف الزبون.

صفحة ويب تستخدم أيقونات الخطين Noto Emoji و UniFont.
أيقونات محلية (قبل تحميل خط RichStyle من المزود)
الصفحة ذاتها تستخدم أيقونات الخط RichStyle.
الأيقونات من طرف المزود (خط RichStyle)

إذ قد تنطوي بيئة المستخدم Client-side على خط يمثل هذه الأيقونات حتى قبل تحميل الخط من طرف المزود Server-side أو عند الفشل نهائياً في تحميله.

فإن كان خط من قبيل Symbola أو Noto Emoji أو Unifont على سبيل المثال مثبتاً مسبقاً على جهاز المستخدم، فستظهر لدى المستخدم حينها الأيقونات المثبتة لديه على جهازه أولاً، ريثما يتم تحميل الخط المطلوب من المزود، تماماً كما هو الحال عند عرض صفحة ويب باستخدام أحد الخطوط المحلية ريثما يتم تحميل الخط المخصص (التابع للموقع) من المزود.

بيد أن المتصفحات الحديثة باتت تمنع —بسلوكها الافتراضي— ظهور الخطوط المحلية كخطوط احتياطية في مثل هذه الحالة، إذ يرى البعض في ذلك السلوك اختطافاً لتجربة المستخدم وتشويهاً —ولو مؤقتاً— لصورة الصفحة التي يجري تحميلها، في حين يرى آخرون —وأنا منهم— ظهور نص صالح للقراءة، بأي خط كان، خيراً من لا شيء.

يعبر المصممون عن الحالة الأولى، التي تمنع ظهور أي خط احتياطي قبل تحميل الخط المخصص، بالعبارة ”Flash of Invisible Text“ أو FOIT (بالعربية: ”ومضة النص غير المرئي“)، ويعبرون عن الحالة الثانية، التي يظهر فيها خط احتياطي مؤقت قبل تحميل الخط المخصص، بالعبارة ”Flash of Unstyled Text“ أو FOUT (بالعربية: ”ومضة النص غير المنسَّق“). يوضح الفيديو التالي الفرق بين الحالتين بصورة حية.

الفرق بين FOIT و FOUT

ونقول ”بسلوكها الافتراضي“ لأن معايير CSS باتت تسمح لك بالمقابل بتعديل هذا السلوك وتجاوزه. بوسعك الاطلاع على تفاصيل الخاصية font-display المنوط بها هذه المهمة في الصفحة font-display | CSS-Tricks.

ولعل الرسم التوضيحي التالي لـ Monica Dinculescu يمثل أفضل تصوير لقيم الخاصية font-display ولسلوك هذه القيم عبر خط الزمن.

رسم بياني يبين قيم الخاصية `font-display` وسلوك هذه القيم عبر خط الزمن.
قيم font-display

وباختصار، أعتقد أن الخيار الأفضل لتحميل خطوط الأيقونات الملتزمة بمعايير يونيكود هو القيمة fallback كما هو مبين أدناه.

@font-face {
    font-family: 'RichStyle';
    src: …;
    font-display: fallback;
}

حيث تسمح لك القيمة fallback بحجب الخط الاحتياطي —إن وُجد في حاسوب المستخدم— بصورة مؤقتة أملاً بظهور الخط المخصص مباشرة دون المرور بمرحلة التشوه المؤقت لتصميم الصفحة والتي قد يتسبب بها الخط الاحتياطي، فإن تأخر ظهور الخط المخصص، ظهر الخط الاحتياطي بصورة مؤقتة أيضاً ريثما يكتمل تحميل الخط المخصص ويظهر في ثنايا الصفحة.

وبذلك يمثل هذا الخيار حلاً وسطاً يجمع بين الحالتين FOIT و FOUT.

تضمن هذه المطابقة أيضاً قابلية ممتازة للوصول للأيقونات Accessibility، والتي تعني القدرة على التعبير عن تلك الرموز والأيقونات والوصول إليها وإلى دلالتها بمحارف معيارية ذات دلالة، بدلاً من الأبعاد الرسومية التي تعتمدها تقنية الصور المجمَّعة Spritesheets، والتي لن تسمح لمحرك البحث أو لقارئ الشاشة باستخراج أي بيانات ذات دلالة منها.

وبما أننا نتكلم هنا عن حل لم يكن يسمح بتعدد الألوان حتى عهد قريب، فهو حل مقبول بالنسبة للفئة الأولى من الأيقونات: أيقونات واجهة الاستخدام.

نعم؛ المصمم ليس مضطراً لاستخدام الألوان هنا، أي في أيقونات واجهات الاستخدام، ولكن ماذا عن المستخدم؟ ما هي وجهة نظره: هل في صالحه أن تكون الأيقونات أحادية اللون أم متعددة الألوان؟

قد لا نملك جواباً علمياً إحصائياً على ذلك الآن، ولكن من وجهة نظرنا؛ الأيقونات أحادية اللون هي الأفضل.

وبيان ذلك أن هذه الأيقونات أصبحت مع الأيام، ومع التجربة والممارسة، أبجدية كأي أبجدية أخرى، الغاية منها القراءة العملية العابرة، لا التأمل والاستمتاع، لكنها أبجدية مصورة، كالأبجدية الهيروغليفية وغيرها من الأبجديات المصورة التي كانت تعتمد الرسوم والصور في تدوينها، والتي سادت في العصور الغابرة ثم بادت، بيد أن الذي أحياها من جديد عاملان اثنان:

صورة فوتوغرافية للوحة رموز في أروقة أحد المطارات.
لغة الرموز في المطارات

ولقد حاول عالم الاقتصاد السياسي Otto Neurath من فيينا بين عامي ١٩٢٠ و ١٩٤٠ تطوير لغة بصرية سماها IsoTypes، في محاولة لإحياء الكتابة التصويرية Pictographic Symbols من جديد، بيد أنها لم تلق رواجاً أو نجاحاً يذكر، ولعل سبب عدم انتشارها آنذاك هو أن استخدامها على مستوى الأفراد يتطلب مهارات لا بأس بها في الرسم اليدوي، في زمن لم تكن المنصات الرقمية قد ظهرت بعد، ولن تصلح تلك الرموز بذلك حينها إلا للاتصالات الجماهيرية، أي عبر وسائل الإعلام الجماهيرية التقليدية السائدة آنذاك، كالإعلانات الطرقية والصحف والمطبوعات والتلفزة والسينما، ذلك أن كتابة الأحرف ستظل حينها أسرع بالنسبة للأفراد من الرسم.

أما اليوم فتتكرر المحاولة من جديد من خلال الرموز التعبيرية Emoji، ولكن بقدر هائل من النجاح، لأن البيئة الرقمية قلبت المعادلة رأساً على عقب: فطباعة الرسومات على الشاشة اليوم باتت أسرع من كتابة الكلمات فيها!

وعلى الرغم من أن منظمة يونيكود لا ترى في الرموز التعبيرية لغة جديدة، فقد علَّمتنا الأبجدية المصورة اليوم أنه:

وهلم جراً.

هذا بالنسبة لأيقونات واجهة الاستخدام، ولكن هل ينطبق ذلك على الشعارات التجارية وأعلام الدول أيضاً؟

مبدئياً لا، وذلك:

ومع ذلك، يمكن الالتفاف على هاتين المشكلتين في الشعارات التجارية على النحو التالي:

الواصلات Ligatures

الواصلة Ligature هي خاصية تابعة لمحرف ما ضمن الخط تسمح باستدعاء ذلك المحرف ضمن نص ما باستخدام سلسلة محارف أخرى.

ولعل أبسط مثال على ذلك إسناد القيمة :) لخاصية الواصلات Ligatures في محرف الابتسامة (☺ U+263A WHITE SMILING FACE) ضمن خط معين؛ سيؤدي ذلك إلى تحويل تلك السلسلة النصية :)، حال ورودها في سياق نص معين يستخدم ذلك الخط، إلى رمز الابتسامة تلقائياً.

COLON + RIGHT PARENTHESIS + WHITE SMILING FACE
يمكن استخدام ميزة الواصلات Ligatures لاستبدال السلسلة :) برمز الابتسامة

تُسخدم الواصلات عادة لتمثيل التراكيب الخاصة لبعض الأحرف عند التقائها معاً، ومثال ذلك التقاء حرفي f و i الصغيرين في الخطوط ذات الزوائد Serif، حيث يتصلان كما ترى في الصورة أدناه.

LATIN SMALL LETTER F + LATIN SMALL LETTER I + LATIN SMALL LIGATURE FI
يُستخدم المحرف LATIN SMALL LIGATURE FI (خانته: U+FB01) لوصل الحرفين f و i في رمز glyph واحد
لقطة من برنامج FontForge للمحرف LATIN SMALL LIGATURE FI (خانته: `U+FB01`) في الخط Noto Serif.
يَستخدم الخط Noto Serif ميزة الواصلات Ligatures لوصل الحرفين f و i في رمز glyph واحد

وتتوسع الخطوط العربية جداً في استخدام هذه الخاصية. وهذه أمثلة على استخدام الواصلات في الأحرف العربية.

تفيدنا هذه التقنية في الشعارات التجارية على النحو التالي:

عندئذ، وعند استخدام شيفرة CSS التالية:

.wordpress-blog:before {
    content: 'wordpress';
}

لن تظهر على الشاشة عبارة ”wordpress“، بل سيظهر بدلاً منها شعار ووردبريس.

وبذلك نكون قد تمكنا من تمثيل شعار تجاري ليس له خانة code point نظامية ضمن جداول يونيكود، دون السطو على محارف الآخرين والتسبب بحالة من التضارب بين المحارف أولاً، ومن خلال سلسلة نصية ذات دلالة بالنسبة لذوي الاحتياجات الخاصة ولمحركات البحث ثانياً.

وفي حال فشل المتصفح في تحميل الخط، ستَظهر الواصلاتُ (العبارة wordpress في مثالنا) بدلاً من المربعات الفارغة.

ومع ذلك فيمكن الالتفاف أيضاً على ظهور الواصلات بمحاولة المطابقة بين الشعار وما قد يقابله أو يعبِّر عنه من رسوم في جداول يونيكود. على سبيل المثال:

وهلم جراً.

وستكون مخيَّراً عندئذ بين استخدام الواصلة أو الرمز الأصلي ضمن شيفرة CSS، فإما أن تكتب:

.twitter:before {
    content: 'twitter';
}

أو تكتب:

.twitter:before {
    content: '🐦';
}

بيد أن استخدام الرمز الأصلي سيعني إلى حد ما خسارة قابلية الوصول للأيقونة، فبدلاً من أن يعمد قارئ الشاشة لقراءة رمز تويتر —على سبيل المثال— على أنه Twitter؛ قد يقرأه على أنه Bird.

عموماً، أصبح لديك —كمطوِّر— شعار يمكن استدعاؤه برمجياً باستخدام نص صالح للقراءة والتعديل بيسر وسهولة من خلال لوحة المفاتيح المعيارية QWERTY، بدلاً من التعامل مع محرف يونيكود غير مألوف ولا سبيل للوصول إليه من خلال لوحة المفاتيح تلك، مع ظهور نص معبِّر (عبارة الواصلة Ligature) أو رمز مشابه للرمز الأصلي ويعبر عنه إلى حد ما، كحل بديل fallback في حال فشل المتصفح في تحميل الخط.

أخيراً، ثمة ملاحظتين في غاية الأهمية فيما يتعلق بالواصلات Ligatures:

التصميم المسطح Flat Design

أما فيما يتعلق بمسألة تعدد الألوان، فيلاحَظ أن الكثير من المنظمات التجارية وغير التجارية التي تقف وراء تلك الشعارات التجارية بدأت تتبنى مبدأ التصميم المسطح Flat Design، تماشياً مع الذوق والاتجاه الفني السائد في هذه الأيام، مستعينة بلونٍ واحد ومسطح (خالٍ من التدرجات اللونية) في شعاراتها، وهو ما يصب أيضاً في مصلحة أنصار خطوط الأيقونات التقليدية (غير الملونة).

فإن كان ثمة شعار واحد على الأقل متعدد الألوان، فلا مفر عندئذ من استخدام:

حاويات SVGs: النظرية

تشمل حاويات SVGs الخيارات التالية:

طريقة SVGs in SVG

يمكنك الاطلاع على أمثلة حية على هذه الطريقة في الصفحة Icon Methods.

طريقة SVGs in CSS (باستخدام DataURL)

المقارنة بين الطريقتين

نستبعد خياري الأيقونات المجمَّعة Spritesheet الأولَين؛ viewbox و predefined views في الطريقة الأولى، وذلك نظراً لصعوبة صيانتهما، الناجمة —بدورها— عن صعوبة رصف الأيقونات في الملف الواحد، أما خيار الأيقونات المكدسة SVG Stack فيستحق التجربة رغم أن ملف SVG الناتج لن يكون صالحاً للعرض من خلال برامج استعراض الصور الاعتيادية.

والعيب الرئيسي المشترك لكافة خيارات الطريقة الأولى SVGs in SVG هو أنه لا يمكن التحكم بحجم الأيقونة باستخدام خاصيتي height و width من خلال CSS مباشرة، بل لا بد من الغوص في شيفرة SVG لهذا الغرض كلما أردت تعديل حجم الأيقونة.

تعتمد الطريقة الثانية SVGs in CSS على تقنية تدعى الرابط البياني DataURL، تقضي بتضمين البيانات الفعلية للصورة مباشرة في حقل URL بدلاً من تضمين رابط إلى تلك الصورة.

ويمكن تخزين ملف SVG في هذه الحالة كـ:

ومما لا شك فيه أن الصيغة الثانية هي الأفضل، نظراً لقابلية صيانتها وقابلية الوصول فيها.

حاويات SVGs: التطبيق

إذن، وحتى الآن، فقد وقع اختيارنا —من بين حاويات SVGs— على الطريقة DataURL as XML لتكون ملاذاً:

الشعارات التجارية الملونة

بداية ننوه إلى أنه ينبغي عند استخدامها الحرص على:

وننصح بتخزين تلك الشيفرات في ملف CSS منفصل، وليكن svg-icons.css على سبيل المثال. لهذا الإجراء غايتان اثنتان:

مرة أخرى نقول: وبالرغم من هذه القيود، تبقى الطريقة DataURL as XML بتقديرنا، وبنظرة على الجدول الأخير حلول أيقونات الويب حسب التقنيات المتاحة، بمثابة الحل الأفضل على الإطلاق من بين حاويات SVGs.

تبقى نقطتان أخيرتان، وهما:

مؤثرات تمرير الماوس

تُستخدم الخاصية color بصورة رئيسية عادة لهذا الغرض في حالة الخطوط على النحو التالي:

.wordpress-blog:before {
    content: 'wordpress';
    color: gray;            /* Effect: monochrome. */

}
.wordpress-blog:hover:before {
    color: #464646;         /* Formal color. */
}

ولكن هذه الطريقة لن تفلح مع أيقونات SVG والخطوط الملونة، فما الحل؟

الحل يكمن في استخدام الخاصية mix-blend-mode التي يمكن استخدامها لتعطيل ألوان أي صورة أو كائن عند تطبيقها عليه. مثلاً:

.wordpress-blog:before {
    content: 'wordpress';
    mix-blend-mode: luminosity; /* Effect: monochrome */

}

.wordpress-blog:hover:before {
    mix-blend-mode: normal;     /* Formal color */
}

الشعارات التجارية غير الملونة: DataURL as XML أم الخطوط؟

بوسعنا القول إن ما يميز الطريقة DataURL as XML هو سهولة الصيانة والتعديل مقارنة بالخطوط، ذلك أن عملية توليد الخطوط تتطلب برمجيات خاصة —خاصة إذا كنا نتكلم عن الخطوط الملونة—، وتنطوي على ما يمكن اعتباره عملية ترجمة compile، في حين لا يتطلب تحديث الأيقونات وفق الطريقة DataURL as XML سوى النسخ واللصق داخل ملف CSS المستخدَم مع بعض التعديلات الطفيفة.

أما ملف الخط فيتميز على الأرجح بصغر حجمه مقارنة بحجم مجموع شيفرات SVG المخزنة داخل ملف CSS. بعبارة أخرى، يكون حجم ملف الخط الناتج أقل عادة على الأرجح من حجم حاوية SVG بصيغة DataURL as XML.

أعلام الدول

يمكن النظر إلى قائمة أعلام الدول على أنها مكون معياري مستقر، لا يخضع نسبياً للتغيير والتبديل بين ليلة وضحاها كالشعارات التجارية، إذ يمكن ربطها بسهولة برموز الدول وفق معيار ISO-3166، سواء باستخدام محارف ASCII المعهودة، أو باستخدام محارف Regional Indicator Symbol Letters.

بيد أن السؤال الآن:

الجواب أنه —وطالما أننا نتكلم عن مكون له معايير مستقرة— فينبغي توفيره، مع ميزة الاستبدال التلقائي، مسبقاً، ضمن المتصفحات.

أي أن أعلام الدول وربطها بالرموز ينبغي أن يكون مكوِّناً مبيَّتاً من طرف المستخدم Client-side لا المزود Server-side، ولن تكون الطريقة DataURL as XML فعالة هنا.

أدرج رمز الابتسامة ☺ ضمن الحقل Input في صفحة المعاينة المباشِرة على موقع EmojiOne .

لاحظ كيف يظهر الرمز في الحقل Output كصورة ملونة.

المطلوب بالنسبة لأعلام الدول توفير حل كهذا ضمن المتصفحات أو أنظمة التشغيل مسبقاً، بحيث يؤدي إدارج الرمز 🇺🇸 إلى ظهور علم الولايات المتحدة، وإدراج الرمز 🇩🇪 إلى ظهور علم ألمانيا… الخ.

وقد أصبح هذا الحل متاحاً مؤخراً في توزيعات لينكس الجديدة بفضل توفر الخط Noto Color Emoji من جوجل فيها، بيد أنه —حتى لحظة كتابة هذه السطور— يظل مقتصراً على بضعة أعلام فقط. كما أنه أصبح مدعوماً ومتاحاً في إصدارات Firefox الحديثة.

الخلاصة

يمكن تلخيص الحلول المثلى لمختلف فئات الأيقونات بالجدول التالي:

حلول أيقونات الويب حسب فئات الأيقونات
المعيارية تعدد الألوان الحل الأمثل
أيقونات واجهات الاستخدام Font emoji
الشعارات التجارية أحادية اللون Font PUA+Ligatures
الشعارات التجارية الملونة DataURL as XML
أعلام الدول Client-side (Built in browsers or OSs)

ويعرض الجدول التالي مقارنة مبسطة بين مختلف حلول تمثيل الأيقونات على الويب؛ المثلى منها وغير المثلى (التي استبعدناها من بحثنا):

حلول أيقونات الويب حسب التقنيات المتاحة
قابلية الصيانة
Maintainability
قابلية الوصول
Accessibility
قابلية تغيير الحجم
Resizibility
تعدد الألوان
Multi-colors
الأداء
Performace
الصور النقطية المفردة
الصور النقطية المجمَّعة
الخطوط التقليدية (أحادية اللون)
الخطوط الملونة
SVG Spritesheet (viewbox) ٥٠٪
SVG Spritesheet (predefined views) ٥٠٪
SVG Stack ٥٠٪ ٥٠٪
SVGs in CSS (DataURL as base64)
SVGs in CSS (DataURL as XML)

كلمة أخيرة

أعتقد أن أنظمة التشغيل، ومع مرور الوقت، وبمضي بضع سنوات، ستغدو مزودة مسبقاً بخطوط emoji ملونة، كمكون أصيل فيها. وإذا ما اقترنت وفرة هذا النوع من الخطوط حينها بدعم مختلف المتصفحات للخطوط الملونة، فسوف يعني ذلك على الأرجح، وبعد استثناء الشعارات التجارية، تحرر مطوري الويب من أعباء مسألة تطوير أيقونات الويب ومشكلاتها بصورة نهائية. ويكفي أن يكون المطور عندئذ قادراً على استخدام إحدى القيمتين monochrome و polychrome، اللتين نقترحهما كقيمتين جديدتين من قيم عائلة الخطوط العامة <generic-font-family> ضمن معايير الويب، للاختيار بين الأيقونات الملونة المتاحة (نمط عرض الرموز التعبيرية Emoji) والأيقونات غير الملونة (نمط العرض النصي، أو نمط الرموز المصوَّرة Pictographs)، وذلك كحل وسيط بدلاً من اللجوء للتبديل يدوياً بين معاملي التبديل variants selectors المسؤولَين عن التحكم بـ نمط عرض الرمز التعبيري (ملون أو أحادي اللون):

font-family: [ serif | sans-serif | cursive | fantasy | monospace ] [ monochrome | polychrome ]?

وأعتقد أن مثل هذه الخطوة ستسمح بظهور استخدامات جديدة لتلك الرموز، لتشمل على سبيل المثال لا الحصر: