ক্রোমের প্রায় প্রতিটি ভার্সনেই আমরা পণ্য, এর কর্মক্ষমতা এবং ওয়েব প্ল্যাটফর্মের ক্ষমতার ক্ষেত্রে উল্লেখযোগ্য সংখ্যক আপডেট এবং উন্নতি দেখতে পাই।
Chrome 49 (বিটা ২রা ফেব্রুয়ারী, ২০১৬। আনুমানিক স্থিতিশীল তারিখ: মার্চ ২০১৬) তে Chrome-এ বেশ কিছু পরিবর্তন রয়েছে।
getComputedStyle(e).cssX-এ "css" উপসর্গের ব্যবহার বন্ধ করা হয়েছে
TL;DR : getComputedStyle(e) তে "css" উপসর্গের ব্যবহার বন্ধ করা হয়েছে কারণ এটি আনুষ্ঠানিক spec এর অংশ ছিল না।
getComputedStyle একটি দারুন ছোট ফাংশন। এটি DOM এলিমেন্টের স্টাইলের সমস্ত CSS মান রিটার্ন করবে যেমনটি রেন্ডারিং ইঞ্জিন দ্বারা গণনা করা হয়েছে। উদাহরণস্বরূপ, আপনি getComputedStyle(_someElement_).height রান করতে পারেন এবং এটি 224.1px রিটার্ন করতে পারে কারণ এটি বর্তমানে প্রদর্শিত উপাদানের উচ্চতা।
এটা বেশ কার্যকর API বলে মনে হচ্ছে। তাহলে আমরা কী পরিবর্তন করছি?
Chrome এর রেন্ডারিং ইঞ্জিন Blink এ পরিবর্তিত হওয়ার আগে, এটি WebKit দ্বারা চালিত ছিল এবং এটি আপনাকে একটি বৈশিষ্ট্যের শুরুতে "css" প্রিফিক্স ব্যবহার করতে দিত। উদাহরণস্বরূপ getComputedStyle(e).cssHeight এর পরিবর্তে getComputedStyle(e).height । উভয়ই একই অন্তর্নিহিত মানগুলিতে ম্যাপ করা একই ডেটা ফেরত দেবে, তবে "css" প্রিফিক্সের এই ব্যবহারটি অ-মানক এবং অবচিত এবং সরানো হয়েছে।
দ্রষ্টব্য - cssFloat একটি স্ট্যান্ডার্ড সম্পত্তি এবং এই অবচয় দ্বারা প্রভাবিত হয় না।
যদি আপনি Chrome 49-এ এইভাবে কোনও সম্পত্তি অ্যাক্সেস করেন তবে এটি undefined ফিরে আসবে এবং আপনাকে আপনার কোডটি ঠিক করতে হবে।
initTouchEvent এর ব্যবহার বন্ধ করা হয়েছে
TL;DR : স্পেক সম্মতি উন্নত করার জন্য TouchEvent constructor পক্ষে initTouchEvent অবচিত করা হয়েছে এবং Chrome 54-এ এটি সম্পূর্ণরূপে সরানো হবে।
Chromestatus Tracker CRBug সমস্যা অপসারণের উদ্দেশ্য
দীর্ঘদিন ধরে আপনি initTouchEvent API ব্যবহার করে Chrome-এ সিন্থেটিক টাচ ইভেন্ট তৈরি করতে সক্ষম হচ্ছেন, এগুলি প্রায়শই আপনার সাইটের কিছু UI পরীক্ষা বা স্বয়ংক্রিয় করার জন্য টাচ ইভেন্টগুলি সিমুলেট করতে ব্যবহৃত হয়। Chrome 49-এ আমরা এই APIটি বাতিল করেছি এবং Chrome 53-এ এটি সম্পূর্ণরূপে অপসারণের উদ্দেশ্যে নিম্নলিখিত সতর্কতা প্রদর্শন করব।
এই পরিবর্তনটি ভালো হওয়ার অনেক কারণ রয়েছে। এটি টাচ ইভেন্টস স্পেসিফিকেশনেও নেই। initTouchEvent এর Chrome বাস্তবায়ন Safari এর initTouchEvent API এর সাথে মোটেও সামঞ্জস্যপূর্ণ ছিল না এবং অ্যান্ড্রয়েডের Firefox এর থেকে আলাদা ছিল। এবং পরিশেষে, TouchEvent কনস্ট্রাক্টর ব্যবহার করা অনেক সহজ।
সিদ্ধান্ত নেওয়া হয়েছে যে আমরা এমন একটি API বজায় রাখার পরিবর্তে স্পেক অনুসরণ করার লক্ষ্য রাখব যা স্পেক করা হবে না বা একমাত্র অন্য বাস্তবায়নের সাথে সামঞ্জস্যপূর্ণ নয়। ফলস্বরূপ, আমরা প্রথমে initTouchEvent ফাংশনটি অবচয় করছি এবং তারপরে সরিয়ে দিচ্ছি এবং ডেভেলপারদের TouchEvent কনস্ট্রাক্টর ব্যবহার করতে বাধ্য করছি।
ওয়েবে এই API ব্যবহার করা হচ্ছে কিন্তু আমরা জানি এটি তুলনামূলকভাবে কম সংখ্যক সাইট ব্যবহার করে, তাই আমরা যত তাড়াতাড়ি সম্ভব এটি অপসারণ করছি না। আমরা বিশ্বাস করি যে সাইটগুলি Chrome এর স্বাক্ষর সংস্করণ পরিচালনা না করার কারণে কিছু ব্যবহার ব্যাহত হয়েছে।
যেহেতু initTouchEvent API-এর 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 এই ডিপ্রিকেশনের সাথে মিলবে এবং আঘাত করবে। যদিও এটি এখনও সরানো যাচ্ছে না কারণ অ্যান্ড্রয়েডে কিছু সময়ের জন্য অন্যান্য ওয়েবকিট এবং পুরানো ব্লিঙ্ক ভিত্তিক ব্রাউজার থাকবে যেখানে আপনাকে এখনও পুরানো API সমর্থন করতে হবে।
ওয়েবে TouchEvents সঠিকভাবে পরিচালনা করার জন্য আপনার কোডটি Firefox, IE Edge এবং Chrome সমর্থনে পরিবর্তন করা উচিত, window অবজেক্টে TouchEvent এর অস্তিত্ব পরীক্ষা করে দেখুন এবং যদি এর একটি ধনাত্মক "দৈর্ঘ্য" থাকে (যা নির্দেশ করে যে এটি একটি কনস্ট্রাক্টর যা একটি আর্গুমেন্ট নেয়) তাহলে আপনার এটি ব্যবহার করা উচিত।
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 spec অনুসারে এই পদ্ধতিগুলিতে প্রতিশ্রুতি প্রবর্তনের পথ পরিষ্কার করার অংশ।
এখানে 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 হেডারে উল্লেখিত প্রথম মানটি পাবেন। যদি তা উপস্থিত না থাকে তবে আপনি <meta> উপাদানের charset বৈশিষ্ট্যে উল্লেখিত মানটি পাবেন (উদাহরণস্বরূপ, <meta charset="utf-8"> )। অবশেষে যদি এর কোনওটিই উপলব্ধ না থাকে তবে document.characterSet হবে ব্যবহারকারীর সিস্টেম সেটিং।
Gecko এই প্রপার্টিটি সমর্থন করে না এবং এটি পরিষ্কারভাবে নির্দিষ্ট করা হয়নি তাই এই প্রপার্টিটি Chrome 49 (জানুয়ারী 2016-এ বিটা) ব্লিঙ্ক থেকে বাদ দেওয়া হবে। Chrome 50-এ প্রপার্টিটি অপসারণ না হওয়া পর্যন্ত নিম্নলিখিত সতর্কতা আপনার কনসোলে প্রদর্শিত হবে:
এটি নির্দিষ্ট না করার যুক্তি সম্পর্কে আরও আলোচনা github https://github.com/whatwg/dom/issues/58 এ পড়তে পারেন।
getStorageUpdates() সরানো হয়েছে
TL;DR : Navigator.getStorageUpdates() মুছে ফেলা হয়েছে কারণ এটি আর Navigator স্পেসিফিকেশনে নেই।
Chromestatus Tracker CRBug সমস্যা অপসারণের উদ্দেশ্য
যদি এর ফলে কারো উপর প্রভাব পড়ে, তাহলে আমি আমার মাথা খাটাইবো। getStorageUpdates() ওয়েবে খুব কমই (যদি থাকে) ব্যবহার করা হয়েছে।
HTML5 স্পেসিফিকেশনের (খুব পুরনো সংস্করণ) উদ্ধৃত করার জন্য:
বেশ ভালো লাগছে তাই না? স্পেকে "where" শব্দটিও ব্যবহার করা হয়েছে (যা ঘটনাক্রমে স্পেকে where এর একমাত্র উদাহরণ)। স্পেকের স্তরে একটি StorageMutex ছিল যা localStorage এবং কুকিজের মতো ব্লকিং স্টোরেজের অ্যাক্সেস নিয়ন্ত্রণ করত এবং এই API সেই mutex মুক্ত করতে সাহায্য করবে যাতে অন্যান্য স্ক্রিপ্টগুলি এই StorageMutex দ্বারা ব্লক না হয়। কিন্তু এটি কখনও বাস্তবায়িত হয়নি, এটি IE বা Gecko তে সমর্থিত নয়, এবং WebKit এর (এবং তাই Blink এর) বাস্তবায়ন একটি নো-অপ ছিল।
এটি বেশ কিছুদিন ধরে স্পেসিফিকেশন থেকে সরানো হয়েছে এবং ব্লিঙ্ক থেকে সম্পূর্ণরূপে সরানো হয়েছে (দীর্ঘদিন ধরে এটি কোনও নো-অপশন ছিল এবং ডাকা হলেও কিছুই করেনি)।
যদি আপনার কাছে navigator.getStorageUpdates() নামক কোড থাকে, তাহলে ফাংশনটি কল করার আগে আপনাকে ফাংশনটির উপস্থিতি পরীক্ষা করতে হবে।
Object.observe() অবচিত হয়েছে
TL;DR : Object.observe() আর স্ট্যান্ডার্ডাইজেশন ট্র্যাকে না থাকায় এটি বন্ধ করে দেওয়া হয়েছে এবং ভবিষ্যতের রিলিজে এটি সরানো হবে।
Chromestatus Tracker CRBug সমস্যা অপসারণের উদ্দেশ্য
২০১৫ সালের নভেম্বরে ঘোষণা করা হয়েছিল যে Object.Observe TC39 থেকে প্রত্যাহার করা হচ্ছে । এটি Chrome 49 থেকে অবচিত করা হয়েছে এবং আপনি যদি এটি ব্যবহার করার চেষ্টা করেন তবে কনসোলে নিম্নলিখিত সতর্কতাটি দেখতে পাবেন:
অনেক ডেভেলপার এই API পছন্দ করেছেন এবং যদি আপনি এটি নিয়ে পরীক্ষা-নিরীক্ষা করে থাকেন এবং এখন একটি ট্রানজিশন পাথ খুঁজছেন, তাহলে MaxArt2501/object-observe এর মতো পলিফিল অথবা polymer/observe-js এর মতো একটি র্যাপার লাইব্রেরি ব্যবহার করার কথা বিবেচনা করুন।