البحث في الموقع

وقعتُ أخيرًا بالصدفة على اقتباس من مطور في مشروع Mozilla عن التوتر الكامن في إنشاء المعايير القياسية: ابقِ هذه المقولة في عقلك، ولنشرح كيف أصبحت HTML5 على ما هي عليه. أنواع MIME هذه السّلسلة تتحدث حول HTML5، وليس عن إحدى إصدارات HTML السابقة أو أي إصدارٍ من XHTML، لكن لفهم تاريخ HTML5 والدوافع خلف إنشائها تمامًا، فعليك أن تستوعب بعض التفاصيل التقنية أولًا، تحديدًا أنواع MIME. في كل مرة يطلب فيها متصفح الويب صفحةً، فسيُرسِل الخادوم "ترويسات" (headers) قبل أن يرسل شيفرة الصفحة نفسها، وهذه الترويسات غير ظاهرة عمومًا على الرغم من توفر أدوات تطويرية تمكنك من رؤيتها إن كنت مهتمًا بها. لكن الترويسات مهمة لأنها تُخبر المتصفح كيف يُفسِّر الشيفرات الموجودة في الصفحة، أحد أهم تلك الترويسات هو Content-Type وهو يبدو كما يلي: Content-Type: text/html "text/html" يدعى "Content Type" أو نوع المحتوى أو نوع MIME، هذه الترويسة هي الشيء الوحيد الذي يُحدِّد طبيعة المورد المُحدَّد وكيف يجب عرضه. فالصورة لها أنواع MIME خاصة بها (image/jpeg لصور JPEG، و image/png لصور PNG، وهلمَّ جرًا)؛ ولملفات JavaScript نوع MIME خاص بها، وكذلك الأمر لصفحات الأنماط CSS، فلكل شيء في الويب له نوع MIME خاص به. وبالطبع الواقع معقَّد أكثر من هذا، فالجيل الأول من خواديم الويب (وهنا أتكلم عن خواديم الويب في 1993) لم تكن تُرسِل ترويسة Content-Type لأنها لم تكن موجودةً في ذاك الوقت (إذ لم تُستعمَل إلا في 1994)، وكانت بعض المتصفحات الشهيرة تتجاهل ترويسة Content-Type في بعض الظروف لأسبابٍ لها علاقة بالتوافقية (وهذا يسمى "content sniffing")، لكن كقاعدة عامة، كل شيء يمكنك الحصول عليه على الويب (كصفحات HTML، والصور، والسكربتات، والفيديو، وملفات PDF، وكل شيء له رابط URL) يجب أن يُخدَّم بإضافة نوع MIME المناسب في ترويسة Content-Type. خزِّن المعلومات السابقة في عقلك، وسنعود إليها لاحقًا. شرح مسهب لكيفية إنشاء المعايير لماذا لدينا عنصر <img>؟ لن تسمع مثل هذا السؤال كل يوم. بكل تأكيد أنشأه أحدهم، إذ لم تظهر تلك الأشياء من العدم، فكل عنصر وكل خاصية (attribute) وكل ميزة من ميزات HTML التي استخدمتها من قبل قد أنشأها أحدهم وقرر كيف يجب أن تعمل وكتب كل ذلك، هؤلاء الأشخاص الذين كتبوا المعايير ليسوا خارقين وإنما مجرد بَشَر ولكنهم أذكياء. أحد الأشياء الرائعة عن المعايير هي أنها طُوِّرَت على الملأ، أي أنَّك تستطيع العودة في الزمن والإجابة عن ذاك النوع من الأسئلة؛ إذ أنَّ النقاشات كانت تُجرى في القوائم البريدية، التي أُرشِفَت وأصبحت متاحةً للعموم كي يبحثوا فيها؛ لذلك قررت أن "أنقِّب" في رسائل البريد الإلكتروني كي أحاول الإجابة عن السؤال السابق: "لماذا لدينا عنصر <img>؟"، كان علي البدء في حقبةِ قبل إنشاء منظمة باسم "رابطة الشبكة العالمية" (World Wide Web Consortium اختصارًا W3C)، ذهبت إلى الأيام الأولى للويب، حيث كنتَ تستطيع عدّ صفحات الويب على أصابع اليدين. في 25 شباط/فبراير من عام 1993، كتب Marc Andreessen: كانت صيغتا Xbm و Xpm صيغتَا رسوميات شهيرتان في أنظمة يونكس. "Mosaic" كان من أوائل متصفحات الويب ("X Mosaic" كان الإصدار الذي يعمل على أنظمة يونكس)، عندما كتب Marc Andreessen رسالته في بدايات 1993، لم يكن قد أسس الشركة التي جعلته مشهورًا (شركة Mosaic Communications Corporation)، ولم يكن بدأ العمل على المنتج الرائد في تلك الشركة: "Mosaic Netscape" (ربما تعرفها بأسمائها الحديثة "Netscape Corporation" و "Netscape Navigator"). عبارته "ربما أنواع MIME" كانت تُشير إلى ميزة Content negotiation في HTTP، حيث يُخبر العميل (أي متصفح الويب) الخادوم (أي خادوم الويب) ما هي أنواع الوسائط التي يدعمها (مثل image/jpeg) ومن ثم سيُرسِل الخادوم الوسائط إلى العميل بالصيغة التي يُفضلِّها. عُرِّفَت الصيغة الأصلية من HTTP في 1991 (وهي النسخة الوحيدة التي كانت موجودةً في شباط/فبراير 1993) ولم تكن توفِّر طريقةً للعملاء لأن يخبروا الخواديم ما هي صيغ الصور التي يدعموها، وهذه هي المعضلة التي واجهها Marc. بعد عدِّة ساعات، ردِّ Tony Johnson: Midas هو متصفح آخر من فترة بدايات الويب، وكان منافسًا لمتصفح X Mosaic، وكان متعدد المنصات، إذ كان يعمل على أنظمة يونكس و VMS. أما "SLAC" فهي تُشير إلى Stanford Linear Accelerator Center التي أصبح اسمها الآن "SLAC National Accelerator Laboratory" التي استضافت أول خادوم ويب في الولايات المتحدة (وفي الواقع، أول خادوم ويب خارج أوروبا). عندما كتب Tony هذه الرسالة، كانت SLAC من المحاربين القدامى في الشبكة العالمية، التي استضافت خمس صفحات على خادوم الويب الخاص بها لمدة 441 يومًا. أكمل Tony قائلًا: قصد ببروتوكول "HTTP2" بروتوكول HTTP الأساسي المُعرِّف في 1992، الذي لم يُطبَّق تطبيقًا كاملًا في بدايات 1993، وعُرِفَت المسودة باسم HTTP2 ثم أصبحت معيارًا قياسيًا باسم "HTTP 1.0" (بالرّغم من أن الأمر قد تم ذلك بعد ثلاثة أعوام)، تضمَّن بروتوكول HTTP 1.0 ترويسات طلبات لتحديد صيغة المحتوى (request headers for content negotiation)، أي أنواع MIME. أكمل Tony: لم يُطبَّق اقتراحه أبدًا، إلا أنَّ فكرة توفير نص إن لم تتوفر الصورة هي تقنية مهمة لتسهيل الوصول التي كانت ناقصة من اقتراح Marc الأولي لوسم <IMG>. استعملت هذه الميزة في خاصية <img alt>، التي أساء متصفح Netscape معاملتها باعتبارها تلميحًا (tooltip). بعد عدِّة ساعات من إرسال Tony لرسالته، ردَّ Tim Berners-Lee عليها: لم يُطبَّق هذا الاقتراح مطلقًا، لكن خاصية rel ما زالت موجودةً. أضاف Jim Davis: لم يُطبَّق هذا الاقتراح قط، لكن أضاف متصفح Netscape لاحقًا دعمًا لتضمين عناصر الوسائط المتعددة باستعمال عنصر <embed>. سأل Jay C. Weber: ردَّ Marc Andreessen: أجاب Jay C. Weber له قائلًا: أدركنا بعد فوات الأوان أنَّ مخاوف Jay كان لها أساسٌ من الصحة لكن ذلك استغرق فترةً طويلةً، فقد أضافت HTML5 أخيرًا عنصرَيّ <video> و <audio>. ردًا على رسالة Jay الأصلية، قال Dave Raggett: لاحقًا في 1993، اقترح Dave Raggett معيار HTML+‎ الذي كان تطويرًا لمعيار HTML. لكن لم يُطبَّق اقتراحه مطلقًا، ثم حلَّت HTML 2.0 محله التي أعطت طابعًا رسميًا للميزات شائعة الاستعمال: "هذا المعيار يضفي توضيحًا وطابعًا رسميًا لمجموعة من ميزات HTML التي كانت شائعة الاستعمال قبل حزيران/يونيو عام 1994". كتب Dave لاحقًا معيار HTML 3.0 المبني على مسودة HTML+‎ التي كتبها سابقًا، وذلك خارج إطار W3C للمعايير (المسمى Arena)؛ لكن لم تُطبَّق HTML 3.0 أبدًا، وحلَّت محلها HTML 3.2، التي رسَّمَت الميزات كالإصدار السابق HTML 2.0: "أضافت HTML 3.2 الميزات شائعة الاستخدام مثل الجداول، و applets والتفاف النص حول الصور، بالإضافة إلى توافقيتها مع معيار HTML 2.0". شارك Dave لاحقًا بوضع معيار HTML 4.0، وطوَّر HTML Tidy، وشارك في المساعدة بتطوير XHTML، و XForms، و MathML، وغيرها من معايير W3C الحديثة. بالعودة إلى 1993، رد Marc على Dave: Intermedia هو مشروعٌ من جامعة Brown، طوِّر من عام 1985 إلى 1991 وكان يعمل على نظام A/UX، الذي هو نظام شبيه بِيونكس (Unix-like) لحواسيب ماكنتوش في ذاك الوقت. راجت فكرة "لغة لتوصيفِ الرسومات ذاتُ غرضٍ عام"، وذلك بدعم المتصفحات الحديثة لصيغة SVG (لغة توصيفية يمكن دمج السكربتات معها)، و <canvas> (واجهة برمجية [API] إجرائية [procedural] مباشرة)، على الرغم من أن الأخيرة بدأت كإضافة مملوكة (proprietary extension) قبل أن يتم ترسيمُها من WHATGW. ردBill Janssen: "Andrew" هو إشارة إلى Andrew User Interface System (إلا أنه كان يسمى في ذاك الوقت Andrew Project). في ذاك الحين، وجد Thomas Fine فكرةً مختلفةً: "Display Postscript" هي تقنية لعرض Postscript على الشاشة طوِّرَتها كل من Adobe و NeXT. لم يُطبَّق هذا الاقتراح أبدًا، لكن الفكرة أنَّ أفضل طريقة لحل مشاكل HTML هي استبدال شيءٍ ما آخر بها ما زالت تظهر من وقتٍ لآخر. قال Tim Berners-Lee في الثاني من آذار/مارس عام 1993: HyTime كان نظام مستندات قديم مبني على SGML، وقد أثَّرَ كثيرًا في النقاشات الأولية للغة HTML، ولاحقًا لغة XML. لم يُطبَّق اقتراح Tim لوسم <INCLUDE> مطلقًا، لكنك تجده صداه واضحًا في عناصر <object> و <embed> و <iframe>. في النهاية، قال Marc Andreessen في الثاني عشر من آذار/مارس عام 1993: ترجمة -وبتصرّف- لفصل A Quite Biased History of HTML5 من كتاب Dive Into HTML5 لمؤلفه Mark Pilgrim. اقرأ أيضًا المقال التالي: نظرة على تاريخ HTML - الجزء الثاني المقال السابق: خمسة أشياء عليك معرفتها عن HTML5 النسخة الكملة لكتاب نحو فهم أعمق لتقنيات HTML5

استُخدم وسم img لتزويد صفحات الويب بالصور، التي تضفي للموقع المزيد من التألق. وقد كان هذا الوسم مفيدًا وغير معقد الاستخدام، إذ يقوم وعبر الرابط المُمرَّر في الصفة src الملحقة بالـ img بطلب ملف الصورة، كما أُضيفت بعض التقنيات المساعدة للحالات البديلة التي لاتظهر فيها الصورة بالشكل الافتراضي، وبالتالي نستنتج أن وسم img يمتاز بالسرعة، الفعالية والسلاسة. لذلك أودّ التنبيه بأن هذه المقالة لم تأت للتقليل من أهمية وسم img ، وإنّما لإبراز الطرق الجديدة في استخدامها مع تصميم الويب المتجاوب Responsive Web Design (اختصارًا هو RWD). شهد تصميم صفحات الويب الكثير من المنافسة في السنوات السابقة، حيث كانت متصفحات الويب تعمل على تحسين أداء عرض الصور، من خلال تحسين التعامل مع الوسم الخاص بالصور img، والتي تمتاز بالوثوقية ولكن أيضًا قابليتها الضعيفة للتغيير. يمتاز تصميم الويب المُتجاوب RWD بأنه يعمل على بناء صفحات ويب مُتجاوبة مع أي طريقة عرض، وهي ميزة جميلة جدًا، ولكن الميزة الأكبر هي سعيه لإجياد تقنيات يمكنها التكيُّف مع أجهزة العرض المجهولة التي تظهر أمامها، ومحاولة إيجاد طريقة عرض جذابة تشابها، وسنختصر ذلك بالقول أن RWD يمتاز بالمرونة وأنه غير قابل للتنبؤ. من المهم هنا وقبل أن أبدأ بالتفصيل في موضوع الصور المُتجاوبة أن ألفت انتباهكم إلى أن صفحات الويب التي نفتحها عبر متصفحات الويب الموجودة في الأجهزة الخلوية، أي تلك الروابط التي تحوي على الحرف m متبوعًا بنقطة (ونسميها اختصارًا مواقع m-dot)، تطبّق الكثير من أفكار التصميم المتجاوب RWD، ولكنها لاتندرج تحت اسمه، إذ أنها تستخدم طرق أخرى تكيّف من خلالها البيانات الأساسية (الأصول) المتوافرة في صفحة الويب لتناسب الجهاز الذي تُعرض عليه وهذا مانسميه tailored assets. تكييف الأصول Tailored Assets بمجرد إضافة الإعداد max-width: 100% ضمن ملف CSS، ستظهر الصور بالشكل المناسب لشاشة العرض viewport، فمثلًا إذا كان لدينا صورة بعرض 300 بكسل ونريد عرضها على شاشة بعرض 200 بكسل فستُكبّر الصورة لتتناسب معها، والعكس أيضًا صحيح ففي حال كان العرض على شاشة بحجم صغير فستُصغّر الصورة للحجم المناسب، وهذا يعني هدر كبير في كلفة نقل الصورة، وذلك لأنه ستُنقل الصورة من مصدرها بحجمها الأصلي ثم ستُصَغّر عند العرض. أي أن عرض الصور عالية الدقة high resolution على شاشات منخفضة الدقة low resolution، يتسبب دومًا في كلفة عالية في عرض النطاق bandwidth cost بدون فائدة تعود على المستخدم من نقل هذه الحزم الكبيرة، بالإضافة إلى وقت أطول لمعالجة هذه البيانات ثم إظهارها. وقد كانت عملية النقل تتم بهذه الطريقة حتى في الأيام الأولى لاستخدام تصميم الويب المتجاوب RWD، لذلك كان من الشائع عرض أو إخفاء كتلة كاملة من المحتوى بالاعتماد على حجم وطريقة العرض viewport، ولكن هذه الطريقة أصبحت أقل شيوعًا. لكن للوسم img اعتبارات خاصة في عملية الإظهار بسبب خصوصية المحتوى الذي يحمله، وذلك لأن طريقة العمل في الويب هي تحليل وترجمة HTML كاملًا ثم تحليل CSS. وبما أن وسم img هو تابع للغة HTML ،ستُحمّل دومًا الصورة بحجمها الأصلي دون أي إمكانية لمعرفة حجم العرض المطلوب حتى لو استخدمنا السطر display:none في تعريف الوسم img أو القالب container الذي يحوي هذا الوسم، أي غالبًا سيكون هناك ضياع في عرض النطاق bandwidth من دون أي فائدة تعود على المستخدم. المحاولات الأولى كان انتشار مواقع m-dot في عام 2011 واسعًا على اعتباره أفضل حل عملي لعرض مواقع الويب على الأجهزة الخلوية، ولكن ظهر تصُّور في تلك المرحلة بأن استخدام التصميم المتجاوب قد يكون أيضًا حلًا عمليًا لبناء المناسبة لعرض الموقع على جميع أحجام الشاشات، وقد كانت مجرد فكرة صعبة التنفيذ إلى أن استُخدمت في إعادة تصميم موقع Globe، فانتشرت طريقة استخدام تصميم الويب المتجاوب RWD في المواقع الإخبارية الضخمة. كما كانت هناك محاولات لتطوير نقل صورة كبيرة للشاشات الكبيرة، وذلك من خلال الفكرة التي طُرحت بإمكانية أن تكون الصورة بحجم شاشة الموبايل مع الاحتفاظ بالصيغة الأساسية format للصورة الأصلية ثم نكبرها في حال كانت شاشة المستخدم أكبر، وبهذه الطريقة لن يكون عرض الصورة بنفس الجودة ولكننا حافظنا على فكرة عرض الصور المتجاوبة. أما الطريقة التقنية لتنفيذ هذه الفكرة فهي من خلال الحصول على عرض الشاشة باستخدام الجافا سكربت في قسم head الموجود في المستند، ثم نقل المعلومات إلى الخادم في الوقت المناسب وونؤجّل طلب الحصول على الصور إلى أسفل الصفحة، ثم وفي الوقت الذي تقوم به الجافا سكربت بتنفيذ الطلبات الموجودة في قسم body نكون قد أعددنا ملف تعريف الارتباط وحفظنا حجم شاشة العرض لدى المستخدم فيه وبهذا يمكن استخدام هذه المعلومات في نفس طلب تحميل الصورة من خلال الوسم img حيث تتم قراءة التعليمات المرفقة بملف تعريف الارتباط وتحديد ماهية البيانات التي يجب إرسالها في الرد. وقد كانت تعمل هذه الطريقة بشكل جيد ولكن سرعان ما استولى عليها المخترقون hackers وقاموا بتحليل السلوك بين الطلب والرد وفهموا محتواه جيدًا رغم أنه لم يكن معرَّفًا صراحة في أي من المواصفات المذكورة، وبالتالي لم يعد هناك جدوى من استخدام هذه الطريقة. تمّ بعد ذلك تطوير فكرة الجلب المسبق prefetching كما سميت أيضًا speculative preparsing، وقد كانت فكرة ضخمة جعلت المتصفحات تعمل بشكل أسرع وذلك لأن الفكرة في أساسيها هي أن يبدأ المتصفح بطلب البيانات الأساسية حتى قبل أن يبدأ عرض الصفحة، وبالتالي ستكون البيانات أقرب إلى الجاهزة عندما يحين وقت ظهور الصفحة. وقد قامت المتصفحات الرئيسية بعدة تغييرات رئيسية للتعامل مع الجلب المُسبَق، حيث كانت الفكرة "بما أنه طُلبت الصورة من مصدرها قبل فترة بالتالي سيكون لدينا فرصة لتنفيذ أي منطق مخصص نريده". وقد كانت المتصفحات تتنافس فيما بينها للوصول إلى أداء أفضل، وقد ساعدها في تنفيذ ذلك الجلب المسبق (كما هو موضح في المقالة improving load time by as much as 20 percent). منطقيًا إن أسرع تنفيذ طلب هو الطلب الذي لا يُنشأ أو يُعدّل عليه، وبالتالي فإن طلب صورة من خلال رابطها الموجود في src المُرفق بالوسم img هو أسرع طلب، ولكن غالبًا سيكون محتوى هذه الطلبات غير فعال منذ البداية بغض النظر عن السرعة التي ينجح المتصفح في طلبها وتحليلها وعرضها وذلك بسبب كبر البيانات الأساسية التي نحتاج إليها في أي وقت، لذلك وُجدت تقنية جديدة هي عبارة عن دمج الوسم noscript ديناميكيًا مع الوسم base ضمن document.write و eval، وبتحليل وعرض كل القسم المكتوب بـ HTML في صفحتنا ضمن عنصر head نكون قد تغلبنا على المشكلة السابقة. ولكن تعتبر هذه الطريقة صعبة التعامل معها دومًا لأنها تعتمد على طريقة عمل المتصفح وذلك أمر غير مُوثَّق وبالتالي غير موثوق به. نلاحظ أن الحلول التي طُرحت كانت دومًا حلولًا وسطية مع تنازلات كبيرة، فمرة لا تُعرض الصورة ويكون هناك هدر في طلبات الصور، ومرة تكون الصور المعروضة باهتة، وبالتالي لم يكن الحل المُنفَّذ باستخدام الجافا سكربت ذكيًا بما فيه الكفاية وذلك لأن التحسينات جميعها كانت تتم على مستوى المتصفح بدلًا من الاستفادة من تلك البيانات القادمة. وقد وُجد الحل الجذري لهذه المشكلة في HTML5 بما فيها من إمكانات. الحل الجذري يعد W3C المجتمع الأهم لمطوري الويب الذي يشاركون فيه اقتراحاتهم وأفكارهم لتطوير الويب. وفي نقاش كبير حول الصور المُتجاوبة والذي كان بعنوان "Responsive Images Community Groups" قدم Bruce Lawson اقتراحًا لتحديث طريقة تقديم الصور لتصبح ملائمة مع عناصر الوسائط المتعددة media التي أصبحت متنوعة وغنية في HTML5 وقد اقترح صيغة تشبه كثيرًا صيغة الوسم video حتى أنه استعار الصفة media منه، حيث كان الوسم الجديد المقترح لتوصيف الصور هو picture، والمميز في هذا الاقتراح هو أنه أبقى على الوسم img المعروف أساسًا بوثوقيته وعمل الوسم الجديد picture على تأطير –تغليف- الوسم السابق بالصيغة التالية: <picture> <source …> <img src="source.jpg" alt="…"> </picture> إنّ وجود وسم img داخل وسم img يؤمن لنا دعمًا احتياطيًّا قويًّا، فالوسم الجديد ليس أحد الوسوم المعيارية التي تحتم علينا أن ننتظر حتى يُدعم من قبل المتصفحات ثم نستطيع بعدها الاستفادة منه، وإنما يمكننا استخدامه مباشرة وستقوم المتصفحات التي لاتدعمه وبالتالي لاتفهم الموجود في عنصر picture و source بتجاهلهما وتنفيذ الوسم الداخلي img، أما المتصفحات اللواتي تدعم picture فستستخدم المعايير المرفقة في العنصر source لتحدد للوسم الداخلي img ماهو الملف الموجود في المصدر والذي نريد الحصول عليه. وبالتالي فنحن لانحتاج إلى بناء جميع الميزات الخاصة بالـ img ومن ثم إرفاقها بالعنصر الجديد picture، وذلك لأنها لم تقدم أي شيء جديد في حد ذاتها وإنما طوّرت أداء وإمكانية الوصول إلى الوسم img، ولكن مع المزيد من الأبحاث سنجد أن picture لا تقدم لنا جميع الخصائص التي تحتاجها الصورة في ظل التطور المستمر للويب المتجاوب وللطرق المتقدمة الجديدة المستخدمة في عرض الصور، ومع ذلك حصلنا على العديد من التحسينات لعنصر img منها خيارات جديدة للتعامل مع الشاشات عالية الدقة من خلال تغيير حجم الصورة ليناسب المكان المخصص، وتأمين صيغ بديلة للصورة لم نكن قادرين على الحصول عليها من قبل. ترجمة -بتصرّف- للمقال Responsive Images لصاحبه Mat Marquis