مرحبا يا هبر! أقدم إليكم ترجمة المقال "HTML لم يكن لدينا من قبل " لسيرجي كوشروف.
يصادف هذا العام مرور 30 عامًا على بدء Berners-Lee في تطوير HTML. منذ ذلك الحين ، قطعنا شوطًا طويلًا ، بدءًا من الإعجاب بالتكنولوجيا الجديدة ، وانتهاءً بمعالجة إدمان الإنترنت والرقابة. ما هي المشاكل التي لم يجلبها الإنترنت لنا ، اخترق كلمات المرور ، وسرقة الهوية ، وفيروسات الكمبيوتر ، والديدان ، وحتى الآن فيروسات الفدية. هل تساءلت يوما لماذا لا تزال الشبكة غير مستقرة وضعيفة؟ في مكان ما على هذا الطريق الطويل تحولنا إلى الطريق الخطأ؟ هيا بنا
لم يتضمن HTML 1.0 ، المنشور في عام 1993 ، سوى 13 عنصرًا (عدا العناصر التي نجت حتى يومنا هذا):
a, address, base, dd, dir, dl, dt, h1..h6, li, p, plaintext, title, ul
أهمها ، بالطبع ، هو "مرساة" (أ). هو الذي يحدد الوظيفة المسؤولة عن أول حرفين في العنوان القياسي - النص التشعبي. بدون نقاط ربط (أو روابط) ، سيكون HTML مجرد لغة ترميز نصية أخرى. هذه هي القدرة على إرسال المستخدم إلى أي مستند في العالم باستخدام محدد موقع الموارد (URL) ، وقد تم إنشاء هذه الظاهرة المذهلة المسماة الشبكة العالمية. بعد ذلك بعامين ، تمت إضافة العديد من العناصر المفيدة إلى HTML: html ، head ، body ، وكذلك عناصر لإنشاء النماذج والجداول والصور.
العنصر الأخير ، ربما لعبت الدور الأكثر أهمية في تاريخ الإنترنت. من خلال منح المستعرض القدرة على عرض ليس فقط النص ، ولكن أيضًا الصور ، جعلنا التكنولوجيا الجديدة جذابة ليس فقط لمجموعة صغيرة من العلماء والمتحمسين ، ولكن أيضًا لملايين المستخدمين العاديين. يمكننا أن نقول بأمان أن هذا الابتكار دفع حتى الصناعة إلى زيادة سرعة الإنترنت وسهولة الوصول إليها للمستخدم الشامل. ومع ذلك ، هناك ميزة أخرى لعنصر HTML هذا لها أهمية تاريخية. انظر هنا:
<img src="http://ibm.com/ibm-logo.gif" />
نظرًا لأنه يتعذر تضمين صورة ثنائية في ملف نصي (على الأقل في ذلك الوقت) ، فإن عنصر img مزود بسمة تشير إلى المكان الذي يمكن للمتصفح العثور على الملف المطلوب فيه. هذه الفكرة البسيطة كانت مفتاح اختراع عظيم.
المفتاح الذي لم نتحول أبدا.
تم نشر HTML 2.0 في نوفمبر 1995. كان الجميع مسرورًا بالميزات الجديدة ، وربما لماذا لم يكن لدى أحد فكرة عما يقترحه: لماذا لا نسمح لجميع عناصر HTML الأخرى باستخدام هذه السمة أيضًا؟ تخيل هذا:
<h1 src="/website/info/title"> </h1>
هذا الرمز يعني أنه ينبغي تحميل محتوى الرأس من عنوان URL هذا. قد لا يكون من المنطقي لمثل هذا العنصر الصغير ، ولكن ماذا عن div أو article ؟
<article src="/parts/article/blog1298" />
حسنًا ، هل هذا منطقي الآن؟ أعلم أنه في عام 1993 ، لم تكن سرعة الإنترنت عالية كما هي الآن. احتلت الميزات الجديدة بالفعل معظم النطاق الترددي الحالي ، ولم يكن HTTP على قدم المساواة. ومع ذلك ، لم يكن هناك سبب لمنع مثل هذا الاحتمال في المعيار.
ربما تفكر الآن في التأثير الذي يمكن أن تحدثه هذه السمة على مستقبل WWW؟ في حد ذاته ، ربما ليست كبيرة جدا. لكن إذا أضفنا فرصة أخرى إليها ، فقد تكون النتيجة مختلفة تمامًا عما لدينا الآن. عندما يعرض المستعرض الصفحة ، فإنه يترجم رمز HTML إلى نموذج كائن مستند (DOM) الموجود في الذاكرة. يبقى هذا النموذج بدون تغيير حتى يتلقى المستعرض طلبًا لاستبداله بمستند HTML آخر. حتى في عام 1993 ، لم يعمل البرنامج بشكل أساسي. في تلك السنة ، عندما حل Netscape Navigator محل متصفح Mosaic ، كان Lotus 123 يبلغ من العمر عشر سنوات وكان VisiCalc أكبر. كانت فكرة حساب حالة المستند كدالة للبيانات التي أدخلها المستخدم معروفة جيدًا وبسيطة التنفيذ. لسوء الحظ ، لم يجرؤ أحد على تطبيقه على المتصفحات. تخيل ما يمكن أن يحدث إذا كانت HTML 2.0 هذه الفرصة:
<div id="name">George</div> <h1>Welcome, $name</h1>
إذا كان في جدول البيانات يمكنك الرجوع إلى محتويات الخلايا الأخرى ، فيمكن أن يسمح مستند HTML باستخدام المتغيرات التي تشير إلى قيم العناصر الأخرى. على سبيل المثال ، سيتم عرض الكود أعلاه كرأس ترحيب ، جورج . يمكن أن تكون المتغيرات أكثر فائدة في عناوين URL:
<article src="http://server.com/blog/$name"></article>
سوف يقوم الرمز أعلاه بتنزيل محتويات المقالة من عنوان URL http://server.com/blog/George . وإذا تغيرت قيمة عنصر name ، فسيقوم المستعرض بتحديث محتويات هذا العنصر الوحيد. كما هو الحال الآن ، فإن الخادم مسؤول عن منطق وتوليد كود HTML. في هذه الحالة ، ليست هناك حاجة لاستخدام AJAX و JavaScipt. هذه الوظيفة الجديدة ، التي ما زال لم يقترحها أي شخص ، ستجعل من السهل تنفيذ مربع بحث يحتوي على تلميحات ديناميكية:
<input list="find" type="text" id="term" /> <datalist id="find" src="http://server.com/search/$term" />
من الواضح أن تقييم التعبيرات أكثر أمانًا من تنفيذ تعليمات برمجية مضمنة للبرنامج ، والتي يصعب التنبؤ بنتائجها. لجعل HTML أكثر توافقًا مع جداول البيانات ، تحتاج إلى إضافة القدرة على استخدام الوظائف:
@CONCATENATE(first,", ",last);
ليست هناك حاجة JavaScript أو الظل DOM أو وظائف باهظة الثمن وغير آمنة للغاية. يقوم المتصفح تلقائيًا بحساب التغييرات في DOM بناءً على إدخال المستخدم. اليوم نسميها البرمجة التفاعلية. من العار أن الأمر استغرقنا 26 عامًا للتوصل إلى هذا. هل فات الأوان لمحاولة تنفيذه الآن؟
يمكنك افتراض أن أحدث إصدارات HTML5 + CSS3 + JS كافية لتلبية الاحتياجات الحديثة. لا أعتقد ذلك. ما زلنا نكافح من أجل إنشاء واجهة مستخدم بسيطة ، ونضطر إلى استخدام مكتبات JS مربكة مثل Angular. ماذا عن مكونات الويب؟ هل سيكونون قادرين على جعل برمجة الويب أسرع وأسهل وأكثر أمانًا؟ ربما. أو ربما لا. كل ما أعرفه هو أن المكونات سهلة التنفيذ للغاية بالإضافة إلى معيار HTML الذي لم نحصل عليه من قبل. اسمح لي بتقديمك إلى عنصر التعريف:
<head> <define tag=“login” src=“http://server.com/components/login”> <define tag=“footer” src=“http://server.com/components/footer”> </head> <body> <login toremember="yes" /> ... <footer /> </body>
هذا كل شيء. المورد الذي تم تحميله على العنوان المحدد في عنوان URL للمكون هو ملف HTML عادي. قد تحتوي على متغيرات ووظائف ، وكذلك روابط لمكونات أخرى. يمكن استخدام مكونات الويب هذه بسهولة ليس فقط على موقع ويب واحد ، ولكن أيضًا كمكتبة قياسية على الإنترنت. يقدم بروتوكول HTTP / 2 العديد من الميزات المفيدة التي تسمح لـ HTML الجديد بالعمل بكامل إمكاناته. يمكن ترك جافا سكريبت ، لكن في معظم الحالات لن تكون هناك حاجة إليها. متى كانت آخر مرة احتجت فيها لاستخدام ماكرو في جدول بيانات؟