دراسة حالة - HTML5 في deviantART muro

Mike Dewey
Mike Dewey

مقدمة

في 7 آب (أغسطس) 2010، احتفلت deviantART بعيد ميلادها العاشر. احتفلنا بعيد ميلادنا من خلال إطلاق أداة رسم HTML5 تسمى deviantART muro. يمكن استخدام الأداة كتطبيق ويب مستقل وكذلك أداة رسم بسيطة لإضافة صور إلى تعليقات المنتدى.

وقد رحّب منتدى deviantART بأداة الرسم الجديدة هذه بحماس كبير، وأصبحت الأداة نفسها تشهد الآن عدد زيارات أكبر من بعض مواقع الويب ذات الحجم اللائق. منذ إطلاقه، يتم إرسال رسم جديد باستخدام deviantART muro حوالي مرة كل 5 ثوانٍ. هذه ليست سوى أعداد الرسومات التي اكتملت، وقد بدأ الكثير منها ولم يتم حفظه.

تقدم المقالة التالية بعض المعلومات الأساسية حول كيفية استخدامنا لـ HTML5، ولماذا اخترنا استخدام التكنولوجيات التي قمنا بها، والأشياء التي اكتشفتها أثناء كتابة أحد أول تطبيقات HTML5 الكاملة لموقع ويب كبير.

خلفيتي

في أواخر عام 2005، كنت أحد المطورين المسؤولين عن أداة الرسم التي استخدمتها Draw Here. وكانت الأداة عبارة عن أداة لـ "رسومات الويب على الجدران" تم إطلاقها بواسطة تطبيق مختصر. كانت تُستخدم لرسم الصور على أي صفحات ويب. تم إنشاء برنامج "رسم هنا" في البداية باستخدام رسومات موجّهة يمكن تغيير حجمها (SVG) (الإصدار التجريبي من Firefox 1.5 كان أحد المتصفحات الأولى التي تدعم رسومات الرسومات الموجّهة التي يمكن تغيير حجمها (SVG)).

في Internet Explorer، كنا ننشئ الرسم SVG في الخلفية، ولكننا نعرض الرسم باستخدام VML. لم تكن WebKit تدعم الرسومات الموجّهة التي يمكن تغيير حجمها (SVG) في ذلك الوقت، لذا نقلت الرمز الخاص بنا لعرض الرسومات الموجّهة التي يمكن تغيير حجمها (SVG) باستخدام لوحة الرسم (التي كانت تقنية جديدة كانت تظهر في WebKit في ذلك الوقت). في مرحلة ما، قمت بإنشاء منفذ بحيث يمكن عرض رمز SVG على المتصفحات القديمة باستخدام مجموعة من عناصر div التي تم لصقها معًا. (بالطبع، كانت هذه مزحة لتظهر أنه يمكن تنفيذها وكان استخدامها بطيئًا إلى حد كبير).

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

التكنولوجيات المستخدَمة بواسطة deviantART muro

نظرًا لخلفيتي في استخدام تقنيات HTML5 مختلفة في بداياته، طُلب مني أن أكون المطور الرئيسي في deviantART muro. ويمكن لأي شخص يقرأ هذه المقالة فهم السبب الذي دفعنا إلى استخدام HTML5 بدلاً من تقنية تستند إلى مكوّن إضافي، مثل Silverlight أو Flash. أردنا شيئًا قويًا وأيضًا شيئًا يستخدم المعايير المفتوحة.

الاختيار بين "لوحة الرسم" ورسومات موجّهة يمكن تغيير حجمها (SVG)

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

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

عندما تستخدم لوحة الرسم، فإنك تطلق الأشياء على اللوحة، ثم تنساها. لوحة فارغة ولوحة مرسومة لمدة ساعة تعملان بالطريقة نفسها تمامًا في التعليمات البرمجية، وتحتوي على نفس بصمة الذاكرة تقريبًا. في حين أن برنامج الرسم النقطي يعمل عادةً بشكل جيد مع النار وينسى التكنولوجيا، إلا أنه يجعل أشياء معينة صعبة. على سبيل المثال، يكون إنشاء دالة التراجع السريع أصعب بكثير في لوحة الرسم منه في SVG. في رسومات موجّهة يمكن تغيير حجمها (SVG)، يمكنك الاحتفاظ بالاسم المعرِّف لآخر عدة أسطر وضعتها، والتراجع عن هذه الخطوة يحتاج إلى نزع هذه العناصر. باستخدام لوحة الرسم، لا تعرف ما كان تحتها، ولذلك فإن إزالة الخط تتطلب إعادة رسم المنطقة التي كانت فيها.

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

استخدام "لوحة الرسم"

قطعت "لوحة الرسم" شوطًا طويلاً في السنوات الخمس الماضية. باستخدام الرسم هنا، لم ننشر منفذ لوحة الرسم، لأن الأداء لم يكن جيدًا. الآن، أعتقد أنه من الآمن أن نقول إنه ربما يعمل بشكل أفضل مما تتخيل. يمكن عادةً أن يحدث محو جزء كبير من اللوحة وإعادة رسم الأشكال المعقدة بسرعات أسرع من تصور الإنسان. الشيء الوحيد الذي وجدت أنه بطيء جدًا في بعض الأحيان هو استخدام getImageData() لعينة وحدات البكسل. تعتمد سرعة العملية بشكل واضح على حجم لوحة الرسم، ولكن على لوحة كبيرة، يمكن أن يستغرق تنفيذ getImageData() في الوقت الخطأ وقتًا كافيًا حتى يشعر المستخدم أن التطبيق بطيء في الاستجابة.

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

منتقي الألوان
أداة اختيار الألوان

كانت غريزتي الأولى هي البدء في التفكير في طريقة لإنشاء أداة واجهة المستخدم الصغيرة باستخدام HTML وCSS التقليديَين. قد يشير بارعون في اختراق CSS إلى كيفية تنفيذ كل ذلك على CSS، لكن الشكل المثلث للجزأين اللذين يتغيران اللون يجعل الأمر غير واضح.

عندما خطرت لي استخدام لوحة رسم، أنشأتُ الأداة باستخدام عنصر DOM واحد وسطرين من JavaScript. يستخدم deviantART muro عقد لوحة رسم في كل مكان. كل طبقة عبارة عن لوحة رسم، وتغيير ترتيب الطبقات هو مجرد مسألة تبديل مؤشر z. إن لوحة التكبير/التصغير التي تُظهر عرضًا مخفضًا لمنطقة الرسم هي مجرد لوحة أخرى تستدعي أحيانًا drawImage() باستخدام لوحات الطبقة كصور مصدر. حتى مؤشر منطقة الرسم (دائرة ثنائية اللون تقوم بضبط الحجم بناءً على حجم الفرشاة والتكبير/التصغير) هو لوحة رسم تطفو أسفل الماوس.

السبب في أنّنا كُننا أكثر تحررًا في استخدام لوحات الرسم مقارنةً بتقنيات HTML5 الأخرى، هو أنّ مكتبة ExplorerCanvas في Google تتيح إمكانية محاكاة اللوحات في Internet Explorer. هذا يقودني إلى القسم التالي.

Internet Explorer (IE)

السبب الرئيسي وراء عدم استخدام المزيد من المواقع الإلكترونية الكبرى لـ HTML5 حتى الآن هو عدم رغبتهم في خسارة مستخدمي Internet Explorer. أنا متأكد من أن السؤال الأول في أذهان معظم المطورين عندما يسمعون أن deviantART أنشأ تطبيق رسم HTML5 هو، "ما الذي تم إجراؤه بشأن IE؟"

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

قررنا أننا سننشئ أي ميزة رائعة خطرت في الذهن باستخدام مواصفات HTML5، وحاول جعلها تعمل في Internet Explorer، وإذا لم تتمكن من ذلك، فسنفتح نافذة توضح أن الميزة لم تكن متاحة لأن المتصفح لم يستخدم معيار ويب حتى الآن.

حاولنا في البداية جعل الأمور تعمل باستخدام ExplorerCanvas (exCanvas) من Google. وهي جيدة بشكل مدهش في تقليد اللوحة لمعظم الأشياء. إلا أن لها جانبًا سلبيًا واحدًا. كل ضغط على لوحة الرسم هو كائن DOM في ترجمة VML الأساسية. بالنسبة لمعظم الأشياء التي قد تحاولها مع لوحة الرسم، فهذا أمر جيد، ولكن بعض فُرش deviantART muro تبتكر أشكالاً من طبقات الكثير من الحدود معًا. عندما يواجه Internet Explorer VML الذي يحتوي على آلاف العُقد - حتى على الأجهزة السريعة - فإنه يتعطل ويموت. لهذا السبب، كان علينا إجراء الكثير من طلبات الرسم عند استخدام لغة VML الفعلية واستخدام حيل تتيح لنا إنشاء تسلسل للعُقد معًا واستخدام أمر Move لتحديد المواضع التي يجب أن تكون هناك فجوات فيها. الكثير من عناصر التحكم الصغيرة والعناصر غير المضمّنة في الواجهة تستخدم علامة لوحة رسم، حيث إن تلك الاستخدامات الصغيرة الصغيرة تعمل بشكل جيد مع exCanvas.

بالإضافة إلى جعل بعض الأشياء تعمل مع exCanvas، اقترحنا على المستخدمين أنهم يمكنهم الاستمرار في استخدام إصدارهم من Internet Explorer في حالة تثبيت المكوّن الإضافي Google Chrome Frame. إن إطار Google Chrome هو مكوّن إضافي يضم محرك عرض Google Chrome في Internet Explorer. ومن منظور المستخدم، لا يزال المستخدِم يستخدم المتصفّح الذي اعتاد عليه، ولكن تحت الأغلفة، يتم عرض صفحتنا باستخدام إمكانات HTML5 في Chrome وJavaScript أسرع.

كنت أعرف أنه من المفترض أن يكون من السهل نقل الأشياء للعمل باستخدام Chrome Frame، لكنني لم أكن أدرك مدى البساطة. كل ما وضعته في علامة وصفية إضافية... وهذا كل شيء، تبدأ الأشياء في العمل في IE.

ملخّص

إنه لمن دواعي سروري أن أعمل مع التقنيات الجديدة في مواصفات HTML5، وأود أن أقول إن كل ما استخدمته جاهز بالتأكيد للوقت الترفيهي. حتى إذا كنت بحاجة إلى أشياء للعمل بشكل لا تشوبه شائبة على IE، فهناك مقدار مذهل من الأشياء التي يمكنك القيام بها للجمع بين لوحة الرسم ولوحات exCanvas. كما أن كتابة طبقة ترجمة بين SVG وVML يمكن تنفيذها بشكل مدهش أيضًا. ما إن تبدأ في استخدام التكنولوجيا، فإن الأمر أشبه بدخول عالم جديد كليًا.

المراجع