إيقاف واجهات برمجة التطبيقات وإزالتها في Chrome 49

Paul Kinlan

في كل إصدار تقريبًا من Chrome، نلاحظ عددًا كبيرًا من التحديثات والتحسينات على المنتج وأدائه وإمكانات منصة الويب.

في الإصدار 49 من Chrome (الإصدار التجريبي في 2 فبراير 2016 (تاريخ الإصدار الثابت المقدَّر: آذار/مارس 2016) تم إجراء عدد من التغييرات على Chrome

تم إيقاف استخدام البادئة "css" في getComputedStyle(e).cssX نهائيًا

مختصر: تم إيقاف استخدام البادئة "css" في getComputedStyle(e) لأنّها لم تكن جزءًا من المواصفات الرسمية.

• إشعار بنيّة الإزالة
• أداة التتبّع في Chromestatus
• مشكلة CRBug

‫getComputedStyle هي دالة صغيرة رائعة. سيعرض جميع قيم CSS الخاصة بأنماط عنصر DOM كما تم احتسابها بواسطة محرك العرض. على سبيل المثال، يمكنك تشغيل getComputedStyle(_someElement_).height وقد تعرض لك النتيجة 224.1 بكسل لأنّ هذا هو ارتفاع العنصر كما يظهر حاليًا.

يبدو أنّها واجهة برمجة تطبيقات مفيدة جدًا. إذًا، ما الذي سنغيّره؟

قبل أن يتم تغيير محرك العرض في Chrome إلى Blink، كان يعمل باستخدام WebKit، وكان يتيح لك إضافة البادئة "css" إلى بداية إحدى الخصائص. على سبيل المثال، getComputedStyle(e).cssHeight بدلاً من getComputedStyle(e).height. ستعرض كلتاهما البيانات نفسها لأنّهما مرتبطتان بالقيم الأساسية نفسها، ولكن استخدام البادئة "css" غير متوافق مع المعايير وقد تم إيقافه نهائيًا وإزالته.

ملاحظة: cssFloat هي سمة عادية ولا تتأثر بعملية الإيقاف النهائي هذه.

إذا وصلت إلى سمة بهذه الطريقة في Chrome 49، سيتم عرض undefined وعليك إصلاح الرمز.

تم إيقاف استخدام initTouchEvent نهائيًا

ملخّص: تم إيقاف initTouchEvent نهائيًا واستبداله بـ TouchEvent constructor لتحسين التوافق مع المواصفات، وستتم إزالته نهائيًا في الإصدار 54 من Chrome.

Intent to Remove Chromestatus Tracker CRBug Issue

لفترة طويلة، كان بإمكانك إنشاء أحداث لمس اصطناعية في Chrome باستخدام واجهة برمجة التطبيقات initTouchEvent، ويتم استخدامها بشكل متكرر لمحاكاة أحداث اللمس إما للاختبار أو لأتمتة بعض عناصر واجهة المستخدم في موقعك الإلكتروني. في الإصدار 49 من Chrome، أوقفنا نهائيًا واجهة برمجة التطبيقات هذه، وسنعرض التحذير التالي بهدف إزالتها تمامًا في الإصدار 53 من Chrome.

هناك عدد من الأسباب التي تجعل هذا التغيير مفيدًا. وهي غير مضمّنة أيضًا في مواصفات "أحداث اللمس". لم يكن تنفيذ Chrome لـ initTouchEvent متوافقًا على الإطلاق مع واجهة برمجة التطبيقات initTouchEvent في Safari، وكان مختلفًا عن تنفيذ Firefox على Android. وأخيرًا، أصبح من الأسهل بكثير استخدام الدالة الإنشائية TouchEvent.

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

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

بسبب الاختلاف الكبير بين عمليات تنفيذ واجهة برمجة التطبيقات initTouchEvent على نظامَي التشغيل iOS وAndroid/Chrome، كان عليك غالبًا استخدام رمز برمجي على النحو التالي (مع تجاهل Firefox في كثير من الأحيان).

    var event = document.createEvent('TouchEvent');
    
    if(ua === 'Android') {
      event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
        300, 300, 200, 200, false, false, false, false);
    } else {
      event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
        200, false, false, false, false, touches, targetTouches, changedTouches, 0, 0);
    }
    
    document.body.dispatchEvent(touchEvent);

أولاً، هذا الإجراء غير مناسب لأنّه يبحث عن "Android" في User-Agent، وبالتالي سيتم إيقاف Chrome على Android نهائيًا. لا يمكن إزالة هذه الميزة في الوقت الحالي، لأنّه ستظل هناك متصفحات أخرى تستند إلى WebKit وإصدارات قديمة من Blink على Android لفترة من الوقت، وستظل بحاجة إلى توفير الدعم لواجهة برمجة التطبيقات القديمة.

للتعامل مع TouchEvents بشكل صحيح على الويب، عليك تغيير الرمز البرمجي ليتوافق مع Firefox وIE Edge وChrome من خلال التحقّق من توفّر TouchEvent في العنصر window، وإذا كان يتضمّن "طول" موجب (ما يشير إلى أنّه أداة إنشاء تتلقّى وسيطة)، عليك استخدام ذلك.

    if('TouchEvent' in window && TouchEvent.length > 0) {
      var touch = new Touch({
        identifier: 42,
        target: document.body,
        clientX: 200,
        clientY: 200,
        screenX: 300,
        screenY: 300,
        pageX: 200,
        pageY: 200,
        radiusX: 5,
        radiusY: 5
      });
    
      event = new TouchEvent("touchstart", {
        cancelable: true,
        bubbles: true,
        touches: [touch],
        targetTouches: [touch],
        changedTouches: [touch]
      });
    }
    else {
      event = document.createEvent('TouchEvent');
    
      if(ua === 'Android') {
        event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
          300, 300, 200, 200, false, false, false, false);
      } else {
        event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
          200, false, false, false, false, touches, targetTouches, 
          changedTouches, 0, 0);
      }
    }
    
    document.body.dispatchEvent(touchEvent);

معالجات الأخطاء والنجاح مطلوبة في طرق RTCPeerConnection

ملخّص: تتطلّب طريقتَا WebRTC RTCPeerConnection، وهما createOffer() وcreateAnswer()، الآن معالج أخطاء بالإضافة إلى معالج نجاح. في السابق، كان من الممكن استدعاء هذه الطرق باستخدام معالج نجاح فقط. تم إيقاف هذا الاستخدام نهائيًا.

في الإصدار 49 من Chrome، أضفنا أيضًا تحذيرًا يظهر عند استدعاء setLocalDescription() أو setRemoteDescription() بدون توفير معالج أخطاء. نتوقّع أن يصبح وسيط معالج الأخطاء إلزاميًا لهذه الطرق في الإصدار 50 من Chrome.

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

في ما يلي مثال من عرض RTCPeerConnection التوضيحي في WebRTC (main.js، السطر 126):

    function onCreateOfferSuccess(desc) {
      pc1.setLocalDescription(desc, function() {
         onSetLocalSuccess(pc1);
      }, onSetSessionDescriptionError);
      pc2.setRemoteDescription(desc, function() {
        onSetRemoteSuccess(pc2);
      }, onSetSessionDescriptionError);
      pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
    }

يُرجى العِلم أنّ كلاً من setLocalDescription() وsetRemoteDescription() كانا يتضمّنان دائمًا مَعلمة معالج الأخطاء، لذا فإنّ تحديد هذه المَعلمة ببساطة هو تغيير آمن.

بشكل عام، ننصحك باستخدام adapter.js، وهو برنامج وسيط تتم صيانته من خلال مشروع WebRTC، وذلك لعزل التطبيقات عن التغييرات في المواصفات والاختلافات في البادئات.

تم إيقاف Document.defaultCharset نهائيًا

الملخّص: تم إيقاف Document.defaultCharset نهائيًا لتحسين الامتثال للمواصفات.

Intent to Remove Chromestatus Tracker CRBug Issue

‫Document.defaultCharset هي سمة للقراءة فقط تعرض ترميز الأحرف التلقائي لنظام المستخدم استنادًا إلى إعداداته الإقليمية. وقد تبيّن أنّ الحفاظ على هذه القيمة غير مفيد بسبب الطريقة التي تستخدم بها المتصفحات معلومات ترميز الأحرف في استجابة HTTP أو في العلامة الوصفية المضمّنة في الصفحة.

باستخدام document.characterSet، ستحصل على القيمة الأولى المحدّدة في عنوان HTTP. إذا لم يكن ذلك متاحًا، سيتم عرض القيمة المحدّدة في السمة charset للعنصر <meta> (على سبيل المثال، <meta charset="utf-8">). أخيرًا، إذا لم يتوفّر أي من هذه الخيارات، سيتم عرض document.characterSet وفقًا لإعدادات النظام الخاصة بالمستخدم.

لم يكن Gecko متوافقًا مع هذه السمة، ولم يتم تحديد مواصفاتها بشكل واضح، لذا سيتم إيقاف هذه السمة نهائيًا في Blink في الإصدار 49 من Chrome (الإصدار التجريبي في كانون الثاني (يناير) 2016). سيظهر التحذير التالي في وحدة التحكّم إلى أن تتم إزالة السمة في الإصدار 50 من Chrome:

يمكنك الاطّلاع على المزيد من المناقشات حول أسباب عدم تحديد هذه المواصفات على GitHub https://github.com/whatwg/dom/issues/58

تمت إزالة getStorageUpdates()

النص طويل جدًّا ولم تتم قراءته (TL;DR): تمت إزالة Navigator.getStorageUpdates() لأنّه لم يعُد مضمّنًا في مواصفات Navigator.

Intent to Remove Chromestatus Tracker CRBug Issue

إذا تأثّر أي شخص بذلك، سألتهم قبعتي. لم يتم استخدام getStorageUpdates() على الويب إلا نادرًا(إن تم استخدامه على الإطلاق).

وفقًا للنسخة (القديمة جدًا) من مواصفات HTML5:

يبدو رائعًا، أليس كذلك؟ تستخدم المواصفات حتى كلمة "من أين" (وهي بالمصادفة الموضع الوحيد الذي تظهر فيه كلمة "من أين" في المواصفات). على مستوى المواصفات، كان هناك StorageMutex يتحكّم في الوصول إلى مساحة التخزين المحظورة، مثل localStorage وملفات تعريف الارتباط، وكانت واجهة برمجة التطبيقات هذه تساعد في تحرير هذا القفل المتبادل حتى لا يتم حظر النصوص البرمجية الأخرى بواسطة هذا StorageMutex. ولكن لم يتم تنفيذها مطلقًا، ولا تتوافق مع IE أو Gecko، كما أنّ تنفيذها في WebKit (وبالتالي Blink) لم يكن له أي تأثير.

تمت إزالته من المواصفات منذ فترة طويلة، وتمت إزالته بالكامل من Blink (كانت هذه السمة غير فعّالة لفترة طويلة ولم تفعل شيئًا حتى عند استدعائها).

في حال كان لديك رمز يستدعي navigator.getStorageUpdates()، عليك التحقّق من توفّر الدالة قبل استدعائها.

تم إيقاف Object.observe()‎ نهائيًا

ملخّص: تم إيقاف Object.observe() نهائيًا لأنّه لم يعُد ضمن مسار التوحيد، وستتم إزالته في إصدار مستقبلي.

Intent to Remove Chromestatus Tracker CRBug Issue

في نوفمبر 2015، تم الإعلان عن سحب Object.Observe من TC39. تم إيقاف هذه الميزة نهائيًا في الإصدار 49 من Chrome، وسيظهر لك التحذير التالي في وحدة التحكّم إذا حاولت استخدامها:

وقد نالت هذه الواجهة إعجاب العديد من المطوّرين، وإذا كنت قد جرّبتها وتبحث الآن عن مسار انتقال، ننصحك باستخدام polyfill مثل MaxArt2501/object-observe أو مكتبة التفاف مثل polymer/observe-js.