نظرة على تاريخ HTML - الجزء الأول - HTML

وقعتُ أخيرًا بالصدفة على اقتباس من مطور في مشروع 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:

اقتباس
"أود أن أقترح وسم HTML جديد اختياري:

IMG

يتطلب وسيطًا (argument) هو SRC="url"‎.

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

مثالٌ عنها:
<IMG SRC="file://foobar.com/foo/bar/blargh.xbm"‎>
(لا يوجد وسم إغلاق لها).

يمكن جعل الصورة تشير إلى رابط، وعندها سيمكن الضغط عليها مثل الروابط النصية العادية.

يجب على المتصفحات أن تكون مرنة في دعمها لصيغ الصور، ومن المستحسن على سبيل المثال دعم الصيغتين Xbm و Xpm؛ وإن لم يتمكن المتصفح من تفسير صيغة معيّنة من الصور، فيمكن أن يضع ما يشاء بدلًا منها (سيضع متصفح X Mosaic صورةً بديلةً افتراضيةً).

هذه وظيفة مطلوبة في X Mosaic، ولقد عملنا على تطبيقها وسنستخدمها محليًا على الأقل. أنا منفتحٌ حاليًا لأيّة اقتراحات حول كيفية التعامل مع ذلك في HTML، فإن كانت عندك فكرة أفضل مما قدمته، فرجاءً أعلمني بها، أنا أعلم أنَّ هذه ليست صيغة مثالية للصور، لكنني لا أجد بديلًا عن قول "دع المتصفح يفعل ما يستطيع" وانتظار الحل المثالي لكي يأتي في المستقبل (ربما أنواع MIME)."

كانت صيغتا 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 2.0 (نستخدمه هنا في SLAC، وسيُنشَر للجميع خلال أسابيع)، عدا أنَّ جميع الأسماء مختلفة، وهنالك وسيطٌ إضافيٌ اسمه NAME="name"‎، وله نفس الوظيفة تقريبًا لوسم IMG الذي اقترحتَه:
<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
الفكرة في معامل name هي السماح للمتصفح بأن يكون لديه مجموعةٌ من الصور المُضمَّنة داخليًا فيه، فإن طابق الاسمُ صورةً مضمنةً داخليًا، فسيَستعمِل تلك الصورة بدلًا من تنزيل الصورة المُحدَّدة، يمكن لخاصية name أن تصبح "تلميحة" لمحتوى الصورة للمتصفحات السطرية (أي تلك المتصفحات التي تعمل من سطر الأوامر) حيث ستضع رمزًا ما مكان الصورة.

لا أهتم كثيرًا بأسماء الخاصيات أو الوسوم، لكني أظن أنه من المناسب أن نوحد التسميات. ولا أهتم أيضًا بالاختصارات (لِمَ لا نستخدم IMAGE=‎ و SOURCE=‎ على سبيل المثال)، وأنا أفضِّل ICON لأنه يعني أن الصورة يجب أن تكون صغيرة، لكن أليست كلمة ICON مستعملة كثيرًا؟"

Midas هو متصفح آخر من فترة بدايات الويب، وكان منافسًا لمتصفح X Mosaic، وكان متعدد المنصات، إذ كان يعمل على أنظمة يونكس و VMS. أما "SLAC" فهي تُشير إلى Stanford Linear Accelerator Center التي أصبح اسمها الآن "SLAC National Accelerator Laboratory" التي استضافت أول خادوم ويب في الولايات المتحدة (وفي الواقع، أول خادوم ويب خارج أوروبا). عندما كتب Tony هذه الرسالة، كانت SLAC من المحاربين القدامى في الشبكة العالمية، التي استضافت خمس صفحات على خادوم الويب الخاص بها لمدة 441 يومًا.

أكمل Tony قائلًا:

اقتباس
"لمّا كنّا نتباحث في موضوع إضافة وسوم جديد، فلدي وسمٌ آخرٌ ذو وظيفةٍ مشابهةٍ أود أن أضيف دعمًا له في متصفح Midas 2.0، كما يلي:
<INCLUDE HREF="...">
الغرض منه هو تضمين مستند آخر ضمن المستند الأول في مكان ورود الوسم، ويمكن أن يكون ذاك المستند من أي نوع، لكن الغرض الأساسي منه هو السماح بتضمين الصور (بحجمها الطبيعي) في المستندات، أذكِّر مرةً أخرى أن الغاية منه ستظهر بشكلٍ جلي عندما يسمح بروتوكول HTTP2 بتحديد صيغة المستند المُضمَّن بشكل منفصل."

قصد ببروتوكول "HTTP2" بروتوكول HTTP الأساسي المُعرِّف في 1992، الذي لم يُطبَّق تطبيقًا كاملًا في بدايات 1993، وعُرِفَت المسودة باسم HTTP2 ثم أصبحت معيارًا قياسيًا باسم "HTTP 1.0" (بالرّغم من أن الأمر قد تم ذلك بعد ثلاثة أعوام)، تضمَّن بروتوكول HTTP 1.0 ترويسات طلبات لتحديد صيغة المحتوى (request headers for content negotiation)، أي أنواع MIME.

أكمل Tony:

اقتباس
"بديلٌ عمّا سبق هو:
<A HREF="..." INCLUDE>See photo</A>
لا أفضِّل إضافة المزيد من الوظائف إلى وسم <A> لكن الفكرة هنا هي الحفاظ على التوافقية مع المتصفحات التي لا تراعي المعامل INCLUDE، فالغاية هي أنَّ المتصفحات التي تفهم المعامل INCLUDE ستُبدِّل النص (في هذه الحالة "See photo") وتضع بدلًا منه المستند (الصورة)، بينما المتصفحات الأقدم أو الأقل كفاءة ستتجاهل INCLUDE تمامًا."

لم يُطبَّق اقتراحه أبدًا، إلا أنَّ فكرة توفير نص إن لم تتوفر الصورة هي تقنية مهمة لتسهيل الوصول التي كانت ناقصة من اقتراح Marc الأولي لوسم <IMG>. استعملت هذه الميزة في خاصية <img alt>، التي أساء متصفح Netscape معاملتها باعتبارها تلميحًا (tooltip).

بعد عدِّة ساعات من إرسال Tony لرسالته، ردَّ Tim Berners-Lee عليها:

اقتباس
"لقد تخيلت أنَّ طريقة تمثيل الصور هي:
<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
حيث قيم الخاصية REL تعني:

EMBED – التضمين هنا عند العرض

PRESENT – اعرضها كلما عُرِضَ مصدر المستند

لاحظ أنك تستطيع استعمال تركبيات مختلفة من القيم السابقة، ولن يتعطل المتصفح إن لم يدعم إحداها.

أرى أنَّ استعمال الطريقة السابقة للأيقونات التي يمكن النقر عليها يعني تشعّب وسوم <a>؛ مممممم، لكن لم أُرِد وسمًا خاصًا."

لم يُطبَّق هذا الاقتراح مطلقًا، لكن خاصية rel ما زالت موجودةً.

أضاف Jim Davis:

اقتباس
"أظن أنَّ من الجيد وجود طريقة لتحديد نوع المحتوى، أي:
<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>
لكنني مستعد للتعايش مع وجوب تحديد نوع المحتوى عبر امتداد الملف."

لم يُطبَّق هذا الاقتراح قط، لكن أضاف متصفح Netscape لاحقًا دعمًا لتضمين عناصر الوسائط المتعددة باستعمال عنصر <embed>.

سأل Jay C. Weber:

اقتباس

"على الرغم من أنَّ الصور في أعلى قائمة أنواع الوسائط التي أود أن تُضمَّن في متصفحات الويب، لكن لا أظن أنَّ علينا إضافة طرق مختلفة لكل نوع من أنواع الوسائط على حدة؛ فما الذي حدث لحماسنا تجاه استعمال أنواع MIME؟"

ردَّ Marc Andreessen:

اقتباس

"ما سبق ليس بديلًا عن استعمال MIME كآلية قياسية لتضمين المستندات، لكنه يُوفِّر تطبيقًا بسطيًا وضروريًا لوظيفة منفصلة عن MIME."

أ جاب Jay C. Weber له قائلًا:

اقتباس

"لننسَ مؤقتًا أنواع MIME إن كانت ستؤثر على وضوح المشكلة. اعتراضي على نقاش "كيف يمكن أن ندعم تضمين الصور" وليس "كيف يمكن أن ندعم تضمين الكائنات لمختلف أنواع الوسائط المتعددة".

وإلا، فسنجد أحدهم يقترح "لنضع وسمًا جديدًا هو <AUD SRC="file://foobar.com/foo/bar/blargh.snd"‎> لتضمين الصوت".

لا أظن أنَّ استعمال شيءٍ عام وشامل سيكلفنا الكثير."

أدركنا بعد فوات الأوان أنَّ مخاوف Jay كان لها أساسٌ من الصحة لكن ذلك استغرق فترةً طويلةً، فقد أضافت HTML5 أخيرًا عنصرَيّ <video> و <audio>.

ردًا على رسالة Jay الأصلية، قال Dave Raggett:

اقتباس

"هذا صحيح! أريد دعمًا لمختلف أنواع الصور، مع إمكانية تحديد النوع المُفضَّل لدى المتصفح. وأرى أنَّ ملاحظة Tim عن دعم النقر على مناطق في الصورة مهمة."

لاحقًا في 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 بهذه الإمكانيات؟

Intermedia هو مشروعٌ من جامعة Brown، طوِّر من عام 1985 إلى 1991 وكان يعمل على نظام A/UX، الذي هو نظام شبيه بِيونكس (Unix-like) لحواسيب ماكنتوش في ذاك الوقت.

راجت فكرة "لغة لتوصيفِ الرسومات ذاتُ غرضٍ عام"، وذلك بدعم المتصفحات الحديثة لصيغة SVG (لغة توصيفية يمكن دمج السكربتات معها)، و <canvas> (واجهة برمجية [API] إجرائية [procedural] مباشرة)، على الرغم من أن الأخيرة بدأت كإضافة مملوكة (proprietary extension) قبل أن يتم ترسيمُها من WHATGW.

ردBill Janssen:

اقتباس

"أنظمة أخرى –التي فيها هذا المفهوم– علينا النظر إليها هي Andrew و Slate، إذا أنَّ Andrew مبني على "إدراج الأشياء"، فكلٌ نظامٍ منهما فيه نوعٌ من أنواع الإدراج، مثل النص، أو الصور النقطية، أو الرسومات، أو الرسوم المتحركة، أو الرسائل، أو جداول البيانات، إلخ. وتسمح أيضًا بتكرار الإدراج ضمن العناصر، أي أن أي نوع من الأشياء القابلة للإدراج يمكن إدراجها في أي شيء يقبل أن تُدرَج فيه الأشياء، على سبيل المثال، يمكن يمكن إدراج كائن ضمن أي مكان في مربع النص، أو في منطقة في لوحة الرسم، أو في أي خلية في الجدول."

"Andrew" هو إشارة إلى Andrew User Interface System (إلا أنه كان يسمى في ذاك الوقت Andrew Project).

في ذاك الحين، وجد Thomas Fine فكرةً مختلفةً:

اقتباس

"أنا أرى أنَّ أفضل طريقة لتضمين الصور في الويب هي استعمال أنواع MIME. أنا متأكد أنَّ صيغة postscript مدعومة كنوع من أنواع MIME، وهي تتعامل بشكلٍ رائعٍ مع دمج النصوص والصور.

لكنها غير قابلة للنقر؟ ربما أنتم محقون، لكنني أظن أن هنالك حلًا لذلك في Display Postscript، وذلك بتعريف أمرٍ ما يُحدِّد عنوان URL ويستخدم المسار (path) الحالي كمنطقة مغلقة للزر القابل للضغط. ولأن postscript تتعامل تعاملًا جيدًا مع المسارات، فإن الفكرة السابقة تجعل من السهل إضافة الروابط."

"Display Postscript" هي تقنية لعرض Postscript على الشاشة طوِّرَتها كل من Adobe و NeXT.

لم يُطبَّق هذا الاقتراح أبدًا، لكن الفكرة أنَّ أفضل طريقة لحل مشاكل HTML هي استبدال شيءٍ ما آخر بها ما زالت تظهر من وقتٍ لآخر.

قال Tim Berners-Lee في الثاني من آذار/مارس عام 1993:

اقتباس

"تسمح HTML 2 للمستند أن يتضمن أي نوع يستطيع المستخدم التعامل معه، وليس فقط أنواع MIME المُسجَّلة.

نعم، أنا أظن أن هنالك حالات يمكن استعمال postscript فيها مع النصوص الفائقة (hypertext)، لكن لا أعلم إن كان عرض postscript كافيًا، أنا أعلم أنَّ Adobe تحاول إرساء استخدام صيغة PDF المبنية على postscript التي يمكن أن أن تتواجد فيها الروابط؛ والقابلة للقراءة بمجموعة من عارضات الملفات الاحتكارية.

أظن أن لغة خاصة بإضافة الروابط (ربما مبنية على Hytime؟) قد تسمح بتطوير معايير النصوص الفائقة والرسوميات/الفيديو كلًا على حدة، مما يفيدهما معًا.

دع وسم IMG يصبح INCLUDE واجعله يشير إلى نوع مستندات عادي، أو EMBED أن بدت INCLUDE شبيهةً بعبارة include في لغة cpp، التي يتوقع فيها الناس توفير شيفرة SGML لكي تُفسَّر مباشرةً – وهذا بالطبع ليس الغرض منها."

HyTime كان نظام مستندات قديم مبني على SGML، وقد أثَّرَ كثيرًا في النقاشات الأولية للغة HTML، ولاحقًا لغة XML.

لم يُطبَّق اقتراح Tim لوسم <INCLUDE> مطلقًا، لكنك تجده صداه واضحًا في عناصر <object> و <embed> و <iframe>.

في النهاية، قال Marc Andreessen في الثاني عشر من آذار/مارس عام 1993:

اقتباس

"بالعودة إلى موضوع تضمين الصور في المستندات، اقتربتُ من إصدار Mosaic V0.10، الذي سيدعم تضمين صور GIF و XBM كما ذكرتُ سابقًا…

لسنا مستعدين لدعم INCLUDE/EMBED في هذه المرحلة… لذا سنستعمل <IMG SRC="url"‎> (وليس ICON، لأنه ليس من الضروري أن تكون كل الصور المُضمَّنة تعني أيقونات). حاليًا، لن يُحدَّد نوع الصورة (أي content-type)، لكننا نفكر في دعم ذلك (مع التكيف مع أنواع MIME)، وفي الحقيقة، آلية قراءة الصور التي نستعملها حاليًا تستطيع تحديد صيغة الصورة آليًا، لذا لن يكون امتداد الملف أيّة قيمة."