أكثر الإثارة التي تصحب عادة الحديث حول HTML5 تدور عادة حول الواجهات البرمجية الجديدة ويتعلق الأمر بكل من Local Storage، Application Cache، WebWorkers، الرسم ثنائي الأبعاد وما شابه. لكن يجب علينا أن لا نتجاهل بأن HTML5 يحمل في طياته 30 عنصرا جديدا لتعليم mark up المُستندات والتطبيقات مما يرفع عدد العناصر المتوفرة بشكل كلي إلى أكثر من 100 عنصر.
باستثناء بعض الأمثلة والعروض الجوفاء، فإن أغلب التطبيقات المبنية بشكل أساسي على Javascript أو حتى التطبيقات المُغالية في مبادئ Web 2.0 ستحتوي على نصوص تحتاج أن يتم تعليمها بشكل حساس. دعونا نلقي نظرة على بعض العناصر الجديدة لتضمن بأن مشاريعك القادمة ستكون دلالية Sementic مثلما ستكون تفاعلية interactive.
ما ستلاحظه طيلة هذا المقال هو أنه تم تصميم دلالية HTML5 لتقوم بتمديد ما يستطيع HTML القيام به، مع إتاحة مستخدمي المتصفحات القديمة الوصول إلى المُحتوى . سنرى أيضا بأن التعليمات الدلالية Sementic Markup ليس أمرا "من الجيد القيام به" فحسب وإنما يُعتبر حجز الزاوية لما يتعلق الأمر بتطوير تطبيقات الويب لأنها الآلية التي تسمح بتعزيز قابلية الوصول (Accessibility)، القابلية للبحث (searchability)، التدويل (internationalization) والتشغيل البيني (interoperability).
اللغات البشرية كالإنجليزية وبالرغم من مفرداتها التي تُعد بالملايين فإنه لا يُمكنها أن تُعبر عن جميع الأفكار دون أن يكون هناك لُبس فيها، وبالتالي فإنه مع 100 مُفردة التي يُمكننا استخدامها في HTML فإننا سنجد أنفسها في حالات لا نعرف فيها على وجه اليقين أي عُنصر يجب علينا استخدامه لأي جزء من المُحتوى، في هذه الحالة كل ما عليك القيام به هو اختيار واحد واستخدامه بشكل متناسق في كامل الموقع.
بعض عناصر العرض لم يعد لها وجود
بعض عناصر العرض مثل center، font أو big أصبحت مهجورة في وقتنا الحاضر، حيث أنه تم استبدال أدوارها بـ CSS، لكن ذلك لا يعني بأنه يجب عليك أن تُسارع لإعادة كتابة كل تلك الصفحات القديمة التي كانت تستخدمها لأنه وبالرغم من كونها مهجورة ستقوم المُتصفحات بعرضها بشكل صحيح، حيث أن HTML5 دائما ما تهدف إلى توفير حلول جديدة دون أن تخل بالحلول الحالية.
ولنفس الأسباب تم التخلص من بعض خصائص العرض التي كانت متوفرة من قبل في بعض العناصر مثلما هو عليه الحال مع خاصية align في عنصري img وtable ، خاصية background في عنصر body وخاصية bgcolor في عنصر table.
العنصر "الشرير" frame أيضا مُغيب في HTML5 حيث أنه كان يُسبب مشاكل في قابلية الاستخدام وقابلية الوصول، لكن لو كانت لديك حاجة ماسة إلى استخدامه فكل ما عليك القيام به هو استخدام DOCTYPE أقدم لتبقى صفحاتك صحيحة من حيث البنية.
يُمكنك أن تجد قائمة كاملة بكل العناصر والخواص التي تم حذفها على موقع W3C.
تمت إعادة تعريف بعض عناصر العرض لتصبح دلالية
لم يتم التخلص من جميع عناصر العرض، خضع بعضها لبرنامج إعادة تأهيل شامل وخرجت منه بخواص دلالية جديدة. فعلى سبيل المثال لم يعد عنصر small يعني "استخدم حجم خط أصغر" رغم أنه سيتم عرضه على هذا النحو في ملفات الأنماط الخاصة بالمتصفحات، حيث أنه أصبح يُمثل تعليقات جانبية، مثل تعليقات Small Print:
يتم استخدام Small print في كل من تصريحات إخلاء المسؤولية، المحاذير، القيود القانونية وحقوق الملكية الفكرية، كما تستخدم أيضا لنسب الأعمال إلى أصحابها أو فيما يتعلق بالتراخيص.
بعض عمليات إعادة التعريف قد تبدو مبالغا فيها، فإن كان بإمكان تفهم إعادة تعريف عنصر <b>(أو عنصر <i>) والذي تم بشكل في غاية الدقة (والذي تشوبه بعض الغرابة)، إلا أن إعادة تعريف بعض العناصر كعنصر <u> قد تصيبك بالدوار:
The u element [now] represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.
يُمكن قراءة المزيد حول العناصر والخصائص التي تم تحديثها على موقع W3C.
عناصر دلالية جديدة وجذابة
كلنا سمعنا عن عنصري video و audio الشهيرين. عنصر canvas أيضا شهير خاصة بسبب سماحه بتصميم رسوم ثلاثية الأبعاد بالاستعانة بـ WebGL والتي تسمح لمصممي الألعاب بنقل ألعابهم إلى الويب. ومثل عناصر img فإن هذه العناصر الجديدة تقوم بتضمين مُحتوى من مصادر أخرى سواء كانت ملفات، بيانات أو JavaScript.
لكن على خلاف img فإن هذه العناصر لديها وسوم فتح وإغلاق مما يسمح بتوفير نوع من التراجع Fallback، وعليه فإنه سيكون بالإمكان توفير محتوى بديل للمتصفحات التي لا تدعم canvas ، ويُمكن لصورة مثلا أن تلعب دور التراجع لعنصر canvas، كما يُمكن لملف Flash أن يلعب دور التراجع لعنصر video وهذه التقنية تُسمى بتقنية "الفيديو للجميع".
عنصرا source و track هما عنصران فارغان (من دون أي وسم إغلاق) ويأتيان كذرية (children) لعنصري video أو audio.
يتم إعطاء عنصر source ملفات بتراميز مُختلفة، ويستعمل كل عنصر منها ملفا مختلفا (WebM، MP4، Ogg Theora) وسيقوم المتصفح بتشغيل أول هذه الملفات التي يُحسن التعامل معها:
<audio controls> <source src=bieber.ogg type=audio/ogg> <source src=bieber.mp3 type=audio/mp3> <!-- fallback content: --> Download <a href=bieber.ogg>Ogg</a> or <a href=bieber.mp3>MP3</a> formats. </audio>
في هذا المثال، سيقوم كل من Opera، Firefox وChrome بتحميل وتشغيل ملف Ogg ، في حين سيفضل Internet Explorer و Safari ملف MP3. يُمكن لمتصفح Chrome أن يُشغل كلا من Ogg وMP3 لكن المتصفحات ستقوم بتشغيل أول ملف تُحسن التعامل معه حسب الترتيب الذي وردت عليه. التراجع الذي نوفره هنا والذي يظهر قبل وسم الإغلاق يُوفر رابطا لتحميل الملف وتشغيله على جهازك باستخدام قارئ الصوتيات المُفضل لديك، كما أنه لا يظهر شوى على المُتصفحات التي لا يُمكنها قراءة الوسائط المُتعددة بشكل مُباشر.
أما فيما يخص الفيديوهات فإنه بإمكانك تضمين ملف Flash على Youtube كنوع من التراجع:
<video controls> <source src=best-video-ever.webm type=video/webm> <source src=best-video-ever.mp4 type=video/mp4> <!-- fallback content: --> <iframe width="480" height="360" src="http://www.youtube.com/embed/xzMUyqmaqcw?rel=0" frameborder="0" allowfullscreen> </iframe> </video>
بهذه الطريقة سيصبح بإمكان مستخدمي المُتصفحات القديمة مثل IE6-8 أن يُشاهدوا الفيديو على Youtube (إن كانت مُتصفحاتهم تدعم Flash)، وسيكون بمقدورهم الوصول إلى تلك الفيديو. في حين سيحصل مستخدمو المتصفحات الأحدث على النسخة المُضمنة في الموقع من الفيديو، وبالتالي سيحصل الجميع على المحتوى الذي قدموا من أجله إلى موقعك.
يُعتبر عنصر track إضافة جديدة إلى عائلة HTML5 وهو مدعوم على كل من Opera، Chrome وIE. يقوم هذا العنصر بالربط إلى ملف نصي يحتوي نصا وتوقيتا، يتم استخدامها لعرض الترجمة الفورية للفيديو وهي خاصية مفيدة جدا ليس فقط للذين يُعانون من مشاكل في السمع، بل أيضا للذين لا يتقنون اللغة التي تُعرض فيها الفيديو.
الدلالية والتدويل
قد يبدو هذا الأمر أقل أهمية من الوسائط المُتعددة لكن الأمر ليس كذلك بحكم أن الشبكة العنكبوتية العالمية ليس مُجرد محتويات باللغة الإنجليزية، بل أنها تستعمل أيضا أنظمة كتابة مُختلفة عن نظام الكتابة في اللغة الانجليزية.
فبعض اللغات كالعربية والعبرية هي لغات تكتب من اليمين إلى اليسار على عكس اللغات الأوروبية والتي تُكتب من اليسار إلى اليمين. قد لا يشكل هذا الأمر أي إشكال على الصفحات التي تحتوي نظام كتابة واحد، لكن الأمر مُختلف على الصفحات التي تحتوي نظامي الكتابة في آن واحد، حيث أنه يجب على المُتصفح أن يقرر أين يتوجب عليه أن وضع علامات التنقيط، أزرار القوائم وأرقامها وما إلى ذلك. عادة ما تُبلي المُتصفحات بلاء حسنا باستخدامها للخوارزميات ثنائية الاتجاه الخاصة بـ Unicode لكنها تخطئ في بعض الحالات، وهو ما يصعب من مهمة فهم المحتوى.
يوفر HTML5 عنصر bdi والذي يسمح للكتاب أن يقوموا بتجاوز الخوارزمية ثنائية الاتجاه آنفة الذكر لجعل نصوصهم أكثر سهولة للفهم. لوصف أوفى للمشكل ولمعرفة الطريقة التي يقوم العنصر bdi بحلها ألق نظرة على هذا المقال HTML5’s New bdi Element لكاتبه Richard Ishida المسؤول عن التدويل لدى W3C.
بعض اللغات لا تملك أبجديات تقليدية بالمرة، والتي تُعبر عن أفكار بدل الأصوات، في بعض الحالات سيحتاج الكاتب بهذه اللغات إلى إضافة تنبيهات لتسهيل قراءة الكلمات خاصة مع الكلمات الشاذة أو الأحرف الغريبة، ويتم ذلك عادة بتوفير نص موازٍ بخص صغير فوق الحرف المعني بالأمر. عادة ما كان يتم القيام بذلك في المطبوعات باستخدام خط صغير ذي حجم 5 نقاط يُسمى « ruby » ، ولهذا يُوفر HTML5 على 3 عناصر جديدة للقيام بذلك، ويتعلق الأمر بكل من ruby، rt وrp.
للمزيد من المعلومات حول الأمر، أقرأ المقال التالي: The HTML5 ruby Element in Words of One Syllable or Less
الدلالية الهيكلية
أغلب المُطورين على علم بأن HTML5 يوفر العديد من العناصر التي تسمح بوصف أجزاء مُختلفة من صفحات الويب مثل header، footer، nav، section، article، aside وغيرها. تم إنشاء هذه العناصر لأن المُطورين أمثالنا رغبوا في وجودها. قد تتساءل كيف عرف مطورو HTML5 العناصر التي نرغب فيها؟ كل ما في الأمر أن Google قامت سنة 2005 بتحليل مليار صفحة لمعرفة ما هي المُعرفات id والأصناف class التي كان المُطورون يستخدمونها مع عناصر div في تلك الصفحات. كما قامت Opera MAMA سنة 2008 بتحليل 3 ملايين URL لمعرفة أكثر أسماء الأصناف انتشارا والمعرفات الأكثر شيوعا على الإنترنت. كشفت هذه التحليلات بأن المطورين رغبوا في تعليم بعض أجزاء صفحاتهم لكن لم يكن لديهم خيار سوى استخدام عنصر div والذي أضافوا إليها أصنافا أو مُعرفات.
كما سبق ذكره فإننا لن نتعمق في جميع هذه العناصر في هذا المقال، لكن يُمكنكم أن تجدوا تفاصيل كثيرة حولها على موقع HTML5Doctor.
تم تصميم هذه العناصر الدلالية الجديدة لتوفر مبدأ التراجع الرشيق، فعلى سبيل المثال انظروا كيف يتم وصف عنصر figure في مواصفات HTML5:
اقتباسThe figure element represents some flow content, optionally with a caption, that is self-contained and is typically referenced as a single unit from the main flow of the document.
The element can thus be used to annotate illustrations, diagrams, photos, code listings, etc…
لم يأت هذا العنصر بأية أفكار جديدة حيث سبق لـ HTML3 أن اقترح عنصر fig لكنه لم يتم قبوله في مواصفات HTML3.2 والذي كان يُستعمل على النحو التالي:
<FIG SRC="nicodamus.jpeg"> <CAPTION>Ground dweller: <I>Nicodamus bicolor</I> builds silk snares</CAPTION> <P>A small hairy spider. <CREDIT>J. A. L. Cooke/OSF</CREDIT></P> </FIG>
هناك مُشكل كبير مع هذه الطريقة، حيث أنه وعلى المُتصفحات التي لا تدعم fig (ولا يوجد أي متصفح يدعمها) لن يتم عرض الصورة لأن المتصفحات ستقوم بتجاهل عنصر fig بشكل كامل، بل كل ما سيتم عرضه هو مُحتوى عنصر credit لأنه عبارة عن نص، وبالتالي ستحصل على وصف دون الصورة في المتصفحات القديمة.
لكن مع HTML5 الوضع مُختلف، حيث أننا سنقوم بكتابة نفس المثال على النحو التالي:
<figure> <img src="nicodamus.jpeg"> <figcaption> <p>Ground dweller: <i>Nicodamus bicolor</i> builds silk snares.</p> <p>A small hairy spider. <small>J. A. L. Cooke/OSF</small></p> </figcaption> </figure>
على خلاف عنصر HTML3 الذي لم يتم قبوله فإن الطريقة التي نكتب بها المثال باستخدام HTML5 متوافقة مع الإصدارات القديمة من المُتصفحات، حيث أن المتصفحات التي لا "تعرف" عنصر figure ستقوم بعرض الصورة والنص الموجود في العنصر figcaption (مثلما كان سيتم عرض مُحتوى عنصر credit). لاحظوا بأننا نستخدم في هذا المثال عنصر small الذي تمت إعادة تعريفه بدل استحداث عنصر credit جديد. تذكروا دائما أنه يتم استعمال عنصر small لنسب الأعمال إلى أصحابها.
يُوفر HTML5 عنصر figcaption جديدا. بداية كانت هناك رغبة لإعادة استخدام عنصر caption مثلما تم اقتراحه في HTML3، لكن كانت هناك مشاكل "إرثية" (Legacy problems) بحكم أن caption كانت تُستخدم سابقا كأحد ذرية عنصر table فقط.
أحد مبادئ التصميم التي بُني عليها HTML5 هو أنه يجب على كل خاصية جديدة أن توفر تراجعا رشيقا، وإن لم يكن بإمكان العنصر القيام بذلك فإنه يجب عليه أن يسمح بتوفير محتوى تراجعي Fallback content، حيث أنه يتم تفضيل استخدام عناصر موجودة بدل استحداث عناصر جديدة، لكنه بحكم أن HTML5 لغة برمجية عملية فإنه لما يكون استحداث عنصر جديد أمرا ضروريا فإنها تقوم بذلك.
دلالية تفاعلية
لا تؤثر العناصر الهيكلية لـ HTML5 على مظهر الصفحات في المتصفحات كثيرا، إلا أن التطبيقات التي تُبنى على المتصفحات (خاصة تطبيقات قراءة الشاشات) قد شرعت في استخدامها (للمزيد حول الأمر: " HTML5, ARIA Roles, and Screen Readers in March 2011" و " JAWS, IE and Headings in HTML5.")
بعض العناصر الأخرى لديها تأثير على شكل الصفحات، فعلى سبيل المثال العنصر details عبارة عن عنصر تفاعلي والذي يلعب دور نافذة صغيرة يحصل المستخدم لدى النقر عليها على بيانات أو خواص إضافية.
ستقوم أغلب المُتصفحات إظهار هذا العنصر كصندوق قابل للتوسع، بعبارة أخرى لما يقوم المُستخدم بالنقر على أيقونة يقوم المُتصفح بتوليدها (كمثلث أو كسهم تحميل) أو حتى على كلمة "تفاصيل" (والتي سيكون بإمكان المُطور استبدالها في العنصر summary الذي سيكون ابنا مُباشرا للعنصر details)، وسيتم فتح الصندوق بشكل منسدل مظهرا التفاصيل التي يحتويها. من المُمكن أن يكون المحتوى عبارة عن وصف كامل للصورة أو للرسم البياني، وصفا لجدول مركب، خصائص للتحكم في نموذج بحث، أو أية معلومات أخرى. تُعتبر هذه الخاصية إحدى الخصائص الضرورية للويب الحديث، وبفضل HTML5 أصبح بالإمكان القيام بذلك من دون الحاجة إلى أي JavaScript.
أغلبنا سبق لك أن شاهد مُختلف الخواص الدلالية الجديدة لنماذج HTML5 (تعرف على العناصر والخصائص الجديدة لنماذج HTML5)، والتي أغلبها عبارة عن خصائص للعنصر input والتي توفر تراجعا رشيقا إلى <input type=text> في المتصفحات الأقدم. من بين العناصر الجديدة نجد أيضا كلا من datalist، output، progress و meter.
هل نملك العناصر الدلالية الأنسب؟
كما رأينا فإننا نملك عناصر دلالية جديدة عديدة، لكن السؤال الذي يجب أن نطرحه هو: هل فعلا نملك العناصر الدلالية الأنسب لاستعمالاتنا؟ مثلما رأينا فإن دراسة Google التي بُني عليها الأمر تعود إلى عدة سنوات خلت (2005)، ومن المُحتمل أن تكون الدلالية التي نعمل عليها متأخرة بعدة سنوات عن احتياجاتنا الحقيقية، كما لاحظنا فإن هذه العناصر تدور كلها هو مفهوم المُستند ومحتوياته document-centric وليست مبنية حول التطبيقات application-centric. هل نحتاج إلى عناصر دلالية تدول حول التطبيقات مثل login أو share، أو حتى Modal.
ليس من السهل الإجابة على هذا السؤال، لكن كون HTML معيارا حيا living standard فإنه من المُمكن إضافة مثل هذه العناصر لاحقا لو تم اقتراح حالات استخدام قوية للـ Working Group.
من دون شك سيرحب أغلب المُطورين بطرق جديدة لتضمين الصور والتي تتماشى مع مختلف الأجهزة التي يتم عليها. يُمكن مثلا أن نقتبس من عنصر video والذي يقوم بعرض الفيديو من المصدر الذي يتوافق مع المتصفح، يُمكن مثلا تخيل عنصر picture يكون على النحو التالي:
<picture alt="angry pirate"> <source src=hires.png media="min-width:800px"> <source src=midres.png media="min-width:480px"> <source src=lores.png> <!-- fallback for browsers without support --> <img src=midres.png alt="angry pirate"> </picture>
هذا العنصر سيعرض hire.png على الشاشات الكبيرة، midres.png على الشاشات التي يتراوح عرضها ما بين 480 و800 بكسل، و lores.png لباقي الشاشات. وهو ما قد يجيب أيضا على التساؤل الذي يطرحه عادة المصممون على أنفسهم: "هل يجب علي أن أطلب من جميع المتصفحات تحميل صورة عالية الجودة ومن ثم أقوم بتصغيرها للشاشات الصغيرة مما يعني بأنني سأقوم بتحميل بيانات زائدة، أم أقوم بتحميل صورة منخفضة الجودة ومن ثم أقوم بتكبيرها على الشاشات الكبيرة وبالتالي فإنني سأضحي بجودة الصور".
وقياسا على ما سبق وأن رأيناه من عناصر دلالية شائعة فإنه يُمكن أيضا أن نوفر تراجعا رشيقا، والذي سيكون في هذه الحالة عنصرا من نوع img وبالتالي سيحصل الجميع على المحتوى الأصح.
لا يزال إرسال الصورة بالحجم الأنسب أحد أعقد المشاكل فيما يتعلق بالتصاميم العبارة للأجهزة cross-device design وللتصاميم المتجاوبة responsive design. قد نجد حلا لها مع HTML6، لكن إلى غاية ذلك الحين تبقى أفضل الحلول -والتي من ضمنها حلا Adaptive Images و Responsive Images- تحتاج إلى JavaScript وإلى بعض التعديلات على ملف htaccess من جانب الخادوم. لكن أسوأ الحلول الحالية تتطلب تقنيات عفا عنها الزمن، كـ" اشتمام المتصفحات" Browser-sniffing، والذي تم تغيير اسمه ليصبح "اكتشاف الأجهزة" device detection رغم أنها تستعمل نفس التقنيات القديمة المتعلقة بالتحقق من user-agent والتي هي عبارة عن تقنية هشة جدا، لا تصلح مع التقنيات المستقبلية، كما أنها غير قابلة للتحجيم Scalable، دون أن ننسى بأنها تُذكرنا بالأيام التي كنا نشاهد فيها "لأفضل عرض استخدم متصفح netscape بدقة 800x600" على صفحات المواقع.
متى، أين ومن؟
تحتاج الكثير من البيانات إلى المعلومات التالية: متى، أين ومن.
يُوفر HTML5 عنصرtime (والذي أسال الكثير من الحبر) والذي يسمح لك بإرفاق التواريخ التي يُمكن لنا أن نقرها من دون صعوبة human-readable بتواريخ على هيأة قابلة للتحليل بشكل آلي machine-readable. لا يهم النص الذي تضعه ما بين وسمين الفتح والإغلاق، لأن ذلك النص هو الذي سيظهر للقراء، وبالتالي فإنه يُمكن استخدام أي من الصيغتين التاليتين:
<time datetime="1982-07-18">The day the woman I love was born</time> <time datetime="1982-07-18">Priyanka Chopra’s birthday</time>
أيا كانت الصيغة التي تختارها فإنه يمكن للآلة قراءة التاريخ بشكل صحيح مادام تم توفير التاريخ على شكل YYYY-MM-DD. إن أردت إضافة الوقت فإنه يمكنك ذلك لكن يجب عليك أن تفصله عن التاريخ بـ T وأن تستخدم وقتا من 24 ساعة (وليس من 12 ساعة) وتختمه بـ Z إضافة إلى أي اختلاف في الحزمة الزمنية. وبالتالي 2011-11-13T20:00Z تُمثل الساعة 8 مساء من يوم 13 نوفمبر سنة 2011 بالتوقيت العالمي UTC، في حين 2011-11-13T23:26.083Z-05.00 تُمثل الساعد 11 ليلا و26 دقيقة و83 جزء من الألف من الثانية في الحزمة الساعية التي تتواجد 5 ساعات قبل التوقيت العالمي. يُمكن مثلا لمتصفح في سيريلانكا أن يقوم بتحويل هذه المعلومة بشكل آلي إلى توقيت حسب التوقيت البوذي، كما أن مُحركات البحث قادرة على استخدام timestamps لتحديد مدى طزاجة نتائج البحث.
رغم الانتشار الكبير لخدمات تحديد الأماكن الجغرافية geolocation إلا أننا لا نملك أي عنصر لتمثيلها والذي يقبل 3 خصائص: خطوط الطول، دوائر العرض، إضافة إلى الارتفاع (بشكل اختياري). وسيكون رائعا لو كان بإمكاننا كتابة شيء مثل التالي:
<location lat=51.502064 long=-0.131981>London SW1A 4WW</location>
وسيكون حينها بإمكان المتصفحات أن تقترح عليك خريطة فيما جملة من التوجيهات إلى المكان الذي تود أن تصل إليه اعتمادا على إحداثياتك الجغرافية الحالية.
احتوى HTML3 على عنصر person تم استخدامه لأسماء الأفراد وذلك للتمكن من استخراجها بشكل آلي من طرف تطبيقات الأرشفة، لكنه لم يتم استخدامها. في HTML4 كان بالإمكان استخدام العنصر cite لتغليف أسماء الأشخاص، لكنه تم التخلص منه في HTML5 بشكل مثير للجدل، وبالتالي فإنه مع HTML5 لا نملك أية وسيلة لتحديد أسماء الأفراد بشكل واضح لا لُبس فيه. في المقابل فإن أسماء الأفراد يُعتبر مشكلا في غاية التعقيد، فإن كان للأوقات والتواريخ صيغ قياسية للتعبير عنها (YYYY-MM-DD للأولى و HH :MM :SS,mmm للثانية) وإن كان يتم تمثيل الأماكن الجغرافية دائما بخطوط الطول ودوائر العرض، فإن الأسماء أصعب للتحليل وللتقسيم إلى وحدات صغيرة يسهل التعامل معها، فعلى سبيل المثال هناك أسماء العائلات الروسية، الأسماء الإندونيسية أحادية الكلمات، الأسماء التي تحتوي على عدة أسماء للعائلة، دون أن ننسى الألقاب التايلاندية. يُمكنكم الاطلاع على مدى تعقيد الأمر بقراءة هذا المقال: Personal Names Around the World.
يملك عنصر date الجديد -والذي استبدل عنصر time- خاصية تحدد قيمة الوقت الذي يُمكن قراءته بشكل آلي (machine-readable information)، لكنه لا يتطلب أو يتضمن صيغة خاصة للقيام بذلك، وبالتالي فإنه لا يُمكن لمحركات البحث مثلا أن تعلم إن كان 1936-10-19 تاريخا، جزءا من رقم، أو حتى رمزا بريديا.
Microdata
HTML5 تماما مثل سابقه HTML4 عبارة عن معيار قابل للتمديد extensible (لكنه ليس قابلا للتمديد على طريقة XML التي يذمها الـ Working Group). بإمكانك أن تستخدم الـ microformat التي سبق وأن تمت تجربتها واختبارها والتي تستعمل أصناف HTML (HTML classes) أو مواصفات RDFa الكاملة والتي لا يُمكنها أن تتجاوز اختبارات التحقق validation في كل من HTML4 أو HTML5. يتم اعتبار RDFa صعبة المراس، حيث أن Google أجرت بحثا بين بأنه يتم ارتكاب 30% أكثر من الأخطاء لدى استخدام RDFa مقارنة بغيرها من الصيغ). أما microdata فعبارة عن آلية لإضافة طبقة دلالية إضافية باستخدام مجموعة من الوسوم التي تم التفاهم عليها مُسبقا. يُمكنكم إيجاد المزيد حول الأمر على موقع HTML5doctor.
مثلما هو عليه الحال مع microformat و RDFa، فإن الوسوم الدلالية التي نضيفها لن يكون لديها أي معنى ما لم يكن لدينا "وثيقة" تدلنا على المعنى الذي يحمله كل وسم. بعبارة أخرى هذه البيانات تحتاج إلى أن تربط إلى قاموس مفردات تُخبر التطبيقات الزاحفة crawler بأي طريقة يجب عليه أن يفسر البيانات التي يجدها. ولمن أراد استخدام microdata هناك موقع schema.org والذي يجمع مخططات/وسوم HTML يُمكن للمطورين استخدامها بطريقة تتعرف عليها كبريات مُحركات البحث.
هل للويب الدلالي أي فائدة؟
بما أنه توليد الكثير من الوسوم أصبح يتم بشكل آلي عبر JavaScript فإن هناك من يعتقد بأن الدلالية لم يعد لها فائدة، عادة ما نُشاهد منتجات يتم التسويق لها على أساس أنها مُنتجات HTML5 لكنها بكل بساطة عبارة عن تطبيقات تقوم بجعل مجموعة من عناصر div "تطير" من مكان إلى آخر من الصفحة باستخدام JavaScript بنفس الطريقة المُتبعة مع DHTML منذ عشرية.
بل أصبح هناك العديد من المُطورين الذين يطلقون تطبيقات لا تحتوي على أية وسوم، وهناك بعض أطر العمل التي تنتج هياكل HTML تحتوي على وسم body فارغ ومن ثم تقوم بحقنه بوسوم HTML باستخدام JavaScript. إن كنت ممكن يقومون بالقيام بذلك فأنت أقرب ما تكون من Flash منك إلى الويب.
ومثلما أن هناك من يعتقد بأن قضاء 47 دقيقة (والتي قد يبدو بأنها مُدة طويلة) لبناء تصميم CSS هي مدة طويلة جدا ويتجهون مباشرة إلى استخدام الجداول في صفحاتهم، فإن هناك أيضا من يعتقد بأن قضاء بعض الوقت في التفكير في أي عنصر يجب استخدامه هو أيضا مضيعة وقت.
هناك حجة أفضل والتي تقول بأنه لا يوجد أية تطبيقات تهتم أو تستهلك المحتويات الدلالية، فلماذا الاهتمام بها؟ رغم أن هذه الحجة ليس صحيحة لأن العمل جار على ربط تقنيات قابلية الوصول accessibility مع الدلالية الحديثة. لكن حتى لو كانت هذه الحجة صحيحة فإنها تتجاهل بأن المشكل الحالي هو مشكل مشابه لمشكل من أتى أولى، الدجاجة أم البيضة؟ لأنها تفترض بأنه لن تظهر أية محركات بحث جديدة يكون بمقدورها استخدام العناصر الجديدة، أو أن المتصفحات لن تطلق أية إصدارات جديدة تقوم باستغلال الدلالية فيها، أو أن المطورين لن يكتبوا أية إضافات للمتصفحات للقيام بذلك. باختصار هذه الحجة تفترض بأن دورة تطور الويب قد اكتملت.
للويب الدلالي فائدة، لأن الدلالية تحمل معنى وبمجرد أن يتم اعتماد ذلك فإنه يُمكن للآلات أن تقوم باستغلال تلك البيانات من دون الحاجة إلى كتابة أو تطوير خوارزميات لتخمن معناها. سيكون بإمكان إضافة للمتصفح أن تسمح للمستخدم بالانتقال مباشرة إلى nav بنقرة زر واحدة لأنها ستقوم بالبحث عن nav مباشرة بدل البحث في كامل عناصر div وتخمن ما إذا كان المعرف id أو الصنف class الذي تحمله يوحي بأنها عبارة عن nav، هذا إن افترضنا أن المطور سيسمي هذا العنصر بأسماء لها معنى كـ nav، navigation، sidebar أو menu. كما أنه على موقع مطعم مثلا فإن div يحمل المعرف menu قد يحتوي على قائمة المأكولات المتوفرة بدل أمر آخر، وهو ما يذكرنا من جديد في مقدار الغموض الذي يلتبس لغاتنا الحية. وسيصبح مثلا بإمكان تطبيق زاحف crawler أن يجمع المقالات حسب ترتيبها الزمي مثلا. باختصار هناك الكثير من الحالات التي يُمكن التفكير فيها بناء على ذلك.
تم بناء الويب اعتمادا على تقنيات بسيطة تم دمجها مع بعض لتعطينا نتائج مُذهلة وهي النتائج التي تجاوزت كل نوايا وتوقعات مطوريها الأوائل، وسيواصل الويب إبهارنا على هذا النحو. الأمر الذي جعل الويب مذهلا بهذه الطريقة والأمر الذي جعله مرنا وفي غاية القوة هو توفر المحتوى على شكل صيغ مفتوحة وبإمكاننا تحليله ودمجه بطرق مذهلة.
يمكن لهذا أن يحدث لو تم وسم المحتوى من أجل إعطاء معنى له، ولو كان للغة وسوم يُمكن استخدامها كجزء من مفرداتنا. ما يقوم به HTML5 هو توسيع لدائرة المفردات التي نستعملها، بطبيعة الحال سنحتاج إلى مفردات إضافية والتي ستأتي مع HTML6.
إذا كنت تعتقد بأن الويب عبارة عن نظام وجب عليه أن يعمل بنفس الطريقة على مختلف المتصفحات، وعلى مختلف أنظمة التشغيل وعلى مختلفة الأجهزة وباختلاف اللغات، وإن كنت تظن بأن شيفرته يجب أن تكون متوفرة للقراءة، وبأننا يجب أن يكون بمقدورنا القيام بمختلف العمليات عليه (القدرة على التغيير، والدمج، والقابلية للوصول، والقابلية للأرشفة ولإعادة الاستخدام) فإنه يجب علينا أن نضمن بأننا نستخدم الأدوات الدلالية التي في حوزتنا بشكل صحيح، وهو ما يضمن بأننا سنستفيد جميعا من الأمر.
ترجمة –وبتصرف- للمقال HTML5 Semantics لصاحبه Bruce Lawson.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.