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

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

في الإصدار Chrome 49 (الإصدار التجريبي في 2 شباط (فبراير) 2016. التاريخ الثابت المقدَّر: آذار (مارس) 2016) هناك عدد من التغييرات في Chrome

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

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

• نية الإزالة
• أداة تتبُّع حالة Chrome
• مشكلة في 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 نهائيًا

النص المختصر (TL;DR): تم إيقاف واجهة برمجة التطبيقات initTouchEvent نهائيًا لصالح TouchEvent constructor لتحسين الامتثال للمواصفات، وستتم إزالتها نهائيًا في الإصدار 54 من Chrome.

هدف الإزالة Chromestatus Tracker مشكلة CRBug

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

هناك عدة أسباب تجعل هذا التغيير جيدًا. فضلاً عن ذلك، لا يشمل ذلك مواصفات أحداث اللمس، لأنّ طريقة تنفيذ المتصفّح 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" في "وكيل المستخدم" وأن Chrome على Android سيتطابق مع عملية الإيقاف هذه. لا يمكن إزالتها بعد، لأنه ستكون هناك متصفحات أخرى تستند إلى WebKit ومتصفحات قديمة تستخدم Blink على Android لفترة من الوقت، والتي ستظل بحاجة إلى دعم واجهة برمجة التطبيقات القديمة لفترة من الوقت.

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

    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.

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

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

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

في ما يلي مثال من العرض التوضيحي RTCPeerConnection (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() يتضمّنان دائمًا مَعلمة معالج خطأ، لذا يُعدّ تحديد هذه المَعلمة تغييرًا آمنًا.

بوجه عام، بالنسبة إلى تطبيقات WebRTC المتعلّقة بالإنتاج، ننصحك باستخدام adapter.js، وهو عنصر يتّبع حافظة مشروع WebRTC، لمنع التطبيقات من إجراء تغييرات في المواصفات واختلافات البادئات.

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

النص المختصر (TL;DR): تم إيقاف Document.defaultCharset نهائيًا لتحسين الامتثال للمواصفات.

هدف الإزالة Chromestatus Tracker مشكلة CRBug

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

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

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

يمكن قراءة المزيد من النقاشات حول أسباب عدم تحديد ذلك على github. https://github.com/whatwg/dom/issues/58

تمت إزالة الطريقة getStorageUpdates() .

النص المختصر (TL;DR): تمت إزالة السمة Navigator.getStorageUpdates() لأنّها لم تعُد ضِمن مواصفات المستكشف.

هدف الإزالة Chromestatus Tracker مشكلة CRBug

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

الاقتباس من (الإصدار القديم جدًا) من مواصفات HTML5:

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

لقد تمت إزالته من المواصفات منذ فترة طويلة وتمت إزالته تمامًا من Blink (لفترة طويلة، كان الأمر بدون مستخدم ولم يتم تنفيذ أي إجراء حتى ولو تم طلبه).

إذا كان لديك رمز يُسمى navigator.getStorageUpdates()، وهو أمر مستبعد، عليك التأكّد من توفُّر الدالة قبل طلبها.

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

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

هدف الإزالة Chromestatus Tracker مشكلة CRBug

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

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