Chrome 133 बीटा

Rachel Andrew

पब्लिश करने की तारीख: 15 जनवरी, 2024

अगर कुछ और नहीं बताया गया है, तो यहां बताए गए बदलाव, Android, ChromeOS, Linux, macOS, और Windows के लिए, Chrome के बीटा चैनल की नई रिलीज़ पर लागू होंगे. यहां दी गई सुविधाओं के बारे में ज़्यादा जानने के लिए, दिए गए लिंक पर जाएं या ChromeStatus.com पर दी गई सूची देखें. Chrome 133, 15 जनवरी, 2024 तक बीटा वर्शन है. डेस्कटॉप के लिए Google.com पर या Android पर Google Play Store से, सबसे नया वर्शन डाउनलोड किया जा सकता है.

सीएसएस और यूज़र इंटरफ़ेस (यूआई)

इस रिलीज़ में, सीएसएस और यूज़र इंटरफ़ेस (यूआई) से जुड़ी सात नई सुविधाएं जोड़ी गई हैं.

सीएसएस का बेहतर attr() फ़ंक्शन

सीएसएस लेवल 5 में बताए गए attr() में बदलाव लागू करता है. इससे <string> के अलावा, अन्य टाइप का इस्तेमाल किया जा सकता है. साथ ही, सभी सीएसएस प्रॉपर्टी में इसका इस्तेमाल किया जा सकता है. इसमें, content स्यूडो-एलिमेंट के लिए मौजूदा सहायता के अलावा, अन्य सहायता भी शामिल है.

ज़्यादा जानने के लिए, सीएसएस attr() को अपग्रेड किया गया लेख पढ़ें.

सीएसएस :open सूडो-क्लास

:open स्यूडो-क्लास, <dialog> और <details> के खुले होने पर उनसे मैच करता है. साथ ही, <select> और <input> के उन मोड से मैच करता है जिनमें पिकर है और पिकर दिख रहा है.

सीएसएस स्क्रोल स्टेटस कंटेनर क्वेरी

कंटेनर की स्क्रोल स्थिति के आधार पर, उनके वंशजों को स्टाइल देने के लिए कंटेनर क्वेरी का इस्तेमाल करें.

क्वेरी कंटेनर, स्क्रोल कंटेनर होता है या ऐसा एलिमेंट होता है जिस पर स्क्रोल कंटेनर की स्क्रोल पोज़िशन का असर पड़ता है. इन स्थितियों के बारे में क्वेरी की जा सकती है:

  • stuck: स्क्रीन पर चिपकाया गया कंटेनर, स्क्रोल बॉक्स के किसी एक किनारे से चिपक गया है.
  • snapped: स्क्रोल स्नैप अलाइन किया गया कंटेनर, फ़िलहाल हॉरिज़ॉन्टल या वर्टिकल तौर पर स्नैप किया गया है.
  • scrollable: क्या स्क्रोल कंटेनर को, पूछे गए डायरेक्शन में स्क्रोल किया जा सकता है.

नए container-type: scroll-state की मदद से, कंटेनर के बारे में क्वेरी की जा सकती है.

#sticky {
  position: sticky;
  container-type: scroll-state;
}

@container scroll-state(stuck: top) {
  #sticky-child {
    font-size: 75%;
  }
}

ज़्यादा जानने के लिए, सीएसएस scroll-state() लेख पढ़ें.

सीएसएस text-box, text-box-trim, और text-box-edge

टेक्स्ट कॉन्टेंट को बेहतर तरीके से अलाइन करने के लिए, text-box-trim और text-box-edge प्रॉपर्टी के साथ-साथ text-box शॉर्टहैंड प्रॉपर्टी का इस्तेमाल करें. इससे, टेक्स्ट के वर्टिकल अलाइनमेंट को बेहतर तरीके से कंट्रोल किया जा सकता है.

text-box-trim प्रॉपर्टी से यह पता चलता है कि किनारों को ऊपर या नीचे से काटना है. साथ ही, text-box-edge प्रॉपर्टी से यह पता चलता है कि किनारों को कैसे काटना है.

इन प्रॉपर्टी की मदद से, फ़ॉन्ट मेट्रिक का इस्तेमाल करके वर्टिकल स्पेस को सटीक तरीके से कंट्रोल किया जा सकता है. ज़्यादा जानकारी के लिए, CSS text-box-trim देखें.

popover एट्रिब्यूट की hint वैल्यू

Popover API, popover एट्रिब्यूट की दो वैल्यू के लिए व्यवहार तय करता है: auto और manual. इस सुविधा से तीसरी वैल्यू के बारे में पता चलता है, popover=hint. "टूलटिप" टाइप के व्यवहार से जुड़े होने की वजह से, हिंट का व्यवहार थोड़ा अलग होता है. मुख्य रूप से, अंतर यह है कि पॉपओवर के नेस्ट किए गए स्टैक खोलने पर, hint, auto के अधीन होता है. इसलिए, auto पॉप-ओवर के मौजूदा स्टैक के खुले रहने के दौरान, उससे मिलता-जुलता hint पॉप-ओवर खोला जा सकता है.

कैननिकल उदाहरण के तौर पर, <select> पिकर खुला है (popover=auto) और कर्सर घुमाने पर दिखने वाला टूलटिप (popover=hint) दिखाया गया है. इस कार्रवाई से <select> पिकर बंद नहीं होता.

पॉपओवर को ट्रिगर करने वाले टूल और ऐंकर की पोज़िशनिंग में सुधार

popover.showPopover({source}) की मदद से, पॉपओवर के बीच कॉल करने वाले के संबंध सेट करने का एक ज़रूरी तरीका जोड़ा गया है. इससे, 'इंवोक करने वाले' रिलेशनशिप की मदद से, 'अनजान एंकर एलिमेंट' रेफ़रंस बनाए जा सकते हैं.

कॉल करने वाले फ़ंक्शन में नेस्ट किए गए पॉपओवर को फिर से कॉल नहीं किया जाना चाहिए

यहां दिए गए उदाहरण में, बटन पर क्लिक करने से पॉपओवर सही तरीके से चालू हो जाता है. हालांकि, इसके बाद पॉपओवर पर क्लिक करने से, पॉपओवर बंद नहीं होना चाहिए.

<button popovertarget=foo>Activate
  <div popover id=foo>Clicking me shouldn't close me</div>
</button>

पहले ऐसा इसलिए होता था, क्योंकि पॉपओवर क्लिक बबल, <button> पर दिखता है और कॉलर को चालू करता है. इससे पॉपओवर बंद हो जाता है. इसे अब, आम तौर पर होने वाली प्रोसेस के मुताबिक बदल दिया गया है.

वेब एपीआई

Animation.overallProgress

इससे डेवलपर को यह जानकारी आसानी से मिलती है कि कोई ऐनिमेशन, अपने सभी इटरेटेशन में कितनी दूर तक पहुंचा है. भले ही, उसकी टाइमलाइन की प्रकृति कुछ भी हो. overallProgress प्रॉपर्टी के बिना, आपको मैन्युअल तरीके से यह हिसाब लगाना होगा कि कोई ऐनिमेशन कितनी दूर तक आगे बढ़ चुका है. इसके लिए, आपको ऐनिमेशन के दोहराए जाने की संख्या को ध्यान में रखना होगा. साथ ही, यह भी देखना होगा कि ऐनिमेशन का currentTime, कुल समय का प्रतिशत है या समय की सटीक संख्या (जैसा कि स्क्रोल-ड्रिवन ऐनिमेशन के मामले में होता है).

Atomics ऑब्जेक्ट का pause() तरीका

Atomics नेमस्पेस ऑब्जेक्ट में pause() तरीका जोड़ता है, ताकि सीपीयू को यह जानकारी दी जा सके कि मौजूदा कोड, स्पिनलॉक को लागू कर रहा है.

स्क्रिप्ट के लिए सीएसपी हैश रिपोर्टिंग

सुरक्षा के मकसद से, जटिल वेब ऐप्लिकेशन को अक्सर डाउनलोड किए गए सब-रिसॉर्स का ट्रैक रखना पड़ता है.

खास तौर पर, आने वाले समय में लागू होने वाले इंडस्ट्री स्टैंडर्ड और सबसे सही तरीकों (उदाहरण के लिए, पीसीआई-डीएसएस वर्शन 4) के मुताबिक, वेब ऐप्लिकेशन को उन सभी स्क्रिप्ट की इन्वेंट्री रखनी होगी जिन्हें वे डाउनलोड और एक्सीक्यूट करते हैं.

यह सुविधा, सीएसपी और Reporting API पर आधारित है. इससे, दस्तावेज़ में लोड होने वाले सभी स्क्रिप्ट संसाधनों के यूआरएल और हैश (सीओआरएस/एक ही सोर्स के लिए) की रिपोर्ट मिलती है.

डीओएम की स्थिति को बनाए रखने वाला मूव

यह एक DOM प्राइमिटिव (Node.prototype.moveBefore) जोड़ता है. इससे, एलिमेंट की स्थिति को रीसेट किए बिना, एलिमेंट को DOM ट्री में एक से दूसरी जगह ले जाया जा सकता है.

हटाने और डालने के बजाय, किसी सेल को एक सेल से दूसरी सेल में ले जाने पर, उस सेल का स्टेटस सेव रहता है. जैसे:

  • <iframe> एलिमेंट लोड रहते हैं.
  • ऐक्टिव एलिमेंट पर फ़ोकस बना रहता है.
  • पॉपओवर, फ़ुलस्क्रीन, और मॉडल डायलॉग खुले रहते हैं.
  • सीएसएस ट्रांज़िशन और ऐनिमेशन चलते रहते हैं.

<area> पर attributionsrc एट्रिब्यूट दिखाना

<area> पर attributionsrc एट्रिब्यूट के एक्सपोज़र को, एट्रिब्यूट के मौजूदा प्रोसेसिंग व्यवहार के साथ अलाइन करता है. भले ही, एट्रिब्यूट को एक्सपोज़ न किया गया हो.

इसके अलावा, <area> पर एट्रिब्यूट का इस्तेमाल करना सही है, क्योंकि यह एलिमेंट फ़र्स्ट-क्लास नेविगेशन प्लैटफ़ॉर्म है. Chrome पहले से ही <a> और window.open के दूसरे प्लैटफ़ॉर्म पर इसका इस्तेमाल करता है

एलिमेंट के लोड होने में लगने वाले समय और एलसीपी में, क्रॉस-ओरिजिन renderTime को ज़्यादा बार दिखाएं. भले ही, Timing-Allow-Origin कुछ भी हो

एलिमेंट के दिखने में लगने वाले समय और एलसीपी एंट्री में renderTime एट्रिब्यूट होता है. यह एट्रिब्यूट, उस पहले फ़्रेम के साथ अलाइन होता है जिसमें इमेज या टेक्स्ट पेंट किया गया था.

फ़िलहाल, इस एट्रिब्यूट को क्रॉस-ऑरिजिन इमेज के लिए सुरक्षित किया गया है. इसके लिए, इमेज रिसॉर्स पर Timing-Allow-Origin हेडर की ज़रूरत होती है. हालांकि, इस पाबंदी को आसानी से हटाया जा सकता है. उदाहरण के लिए, एक ही फ़्रेम में एक ही ऑरिजिन और क्रॉस-ऑरिजिन वाली इमेज दिखाकर.

इस वजह से, हम इस पाबंदी को हटाने जा रहे हैं. इसके बजाय, जब दस्तावेज़ को क्रॉस-ऑरिजिन से अलग नहीं किया जाता है, तो रेंडर होने में लगने वाले समय को चार मिलीसेकंड बढ़ा दिया जाएगा. ऐसा लगता है कि यह क्रॉस-ऑरिजिन इमेज के बारे में, डिकोड करने के समय की काम की जानकारी को लीक होने से रोकने के लिए काफ़ी है.

responseStart को वापस लाएं और firstResponseHeadersStart को शामिल करें

103 Early Hints की सुविधा चालू होने पर, जवाबों में दो टाइमस्टैंप होते हैं:

  • शुरुआती हिंट कब मिलते हैं (103)
  • जब फ़ाइनल हेडर मिलते हैं (उदाहरण के लिए, 200)

Chrome 115 में इन दो टाइमस्टैंप को मेज़र करने की सुविधा जोड़ी गई थी. साथ ही, हमने responseStart (जिसका इस्तेमाल पहले बाइट में लगने वाला समय (टीटीएफ़बी) करता है) का मतलब बदलकर "आखिरी हेडर" कर दिया था.firstInterimResponseStart इस वजह से, उन ब्राउज़र और टूल के साथ वेब के साथ काम करने से जुड़ी समस्या हुई जिनमें इस आम तौर पर इस्तेमाल की जाने वाली मेट्रिक के लिए ऐसा बदलाव नहीं किया गया था.

Chrome 133 में, इस responseStart बदलाव को वापस लाया गया है, ताकि इस काम करने के तरीके से जुड़ी समस्या को हल किया जा सके. इसके बजाय, firstResponseHeadersStart को शामिल किया गया है, ताकि साइटें TTFB की मूल परिभाषा को बनाए रखते हुए, आखिरी हेडर तक पहुंचने में लगने वाले समय को मेज़र कर सकें.

FileSystemObserver इंटरफ़ेस

FileSystemObserver इंटरफ़ेस, वेबसाइटों को फ़ाइल सिस्टम में हुए बदलावों के बारे में सूचना देता है. साइटें, उपयोगकर्ता के डिवाइस या बकेट फ़ाइल सिस्टम (जिसे ऑरिजिन प्राइवेट फ़ाइल सिस्टम भी कहा जाता है) में उन फ़ाइलों और डायरेक्ट्री में हुए बदलावों को देखती हैं जिनके लिए उपयोगकर्ता ने पहले अनुमति दी है. साथ ही, उन्हें बदलाव के टाइप जैसी बुनियादी जानकारी की सूचना दी जाती है.

एनर्जी सेवर मोड चालू होने पर फ़्रीज़ होना

एनर्जी सेवर मोड चालू होने पर, Chrome उस "ब्राउज़िंग कॉन्टेक्स्ट ग्रुप" को फ़्रीज़ कर देगा जो पांच मिनट से ज़्यादा समय से छिपा हुआ है और काम नहीं कर रहा है. ऐसा तब होगा, जब उसमें एक ही ऑरिजिन वाले फ़्रेम का कोई सबग्रुप, सीपीयू के इस्तेमाल की सीमा से ज़्यादा इस्तेमाल करेगा. हालांकि, ऐसा तब नहीं होगा, जब:

  • ऑडियो या वीडियो कांफ़्रेंसिंग की सुविधा देता है. यह सुविधा, माइक्रोफ़ोन, कैमरा या स्क्रीन/विंडो/टैब कैप्चर या 'ओपन' RTCDataChannel या 'लाइव' MediaStreamTrack वाले RTCPeerConnection की पहचान करके पता लगाई जाती है.
  • किसी बाहरी डिवाइस को कंट्रोल करता है. यह डिवाइस, WebUSB, Web Bluetooth, WebHID या Web Serial का इस्तेमाल करके पता लगाया जाता है.
  • वेब लॉक या IndexedDB कनेक्शन को होल्ड करता है, जो किसी दूसरे कनेक्शन पर वर्शन अपडेट या लेन-देन को ब्लॉक करता है.

फ़्रीज़ करने का मतलब है, प्रोसेस को रोकना. इसे Page Lifecycle API में औपचारिक तौर पर परिभाषित किया गया है.

एनर्जी सेवर मोड चालू होने पर, बैकग्राउंड में चल रहे करीब 10% टैब को फ़्रीज़ करने के लिए, सीपीयू के इस्तेमाल की सीमा को कैलिब्रेट किया जाएगा.

एक से ज़्यादा इंपोर्ट मैप

फ़िलहाल, इंपोर्ट मैप को किसी भी ES मॉड्यूल से पहले लोड करना ज़रूरी है. साथ ही, हर दस्तावेज़ में सिर्फ़ एक इंपोर्ट मैप हो सकता है. इस वजह से, उन्हें रीयल-लाइफ़ के उदाहरणों में इस्तेमाल करना मुश्किल और धीमा हो जाता है: उनसे पहले लोड होने वाला कोई भी मॉड्यूल, पूरे ऐप्लिकेशन को बंद कर देता है. साथ ही, कई मॉड्यूल वाले ऐप्लिकेशन में, वे एक बड़ा ब्लॉकिंग रिसॉर्स बन जाते हैं, क्योंकि सभी संभावित मॉड्यूल के लिए पूरा मैप पहले लोड होना चाहिए.

इस सुविधा की मदद से, हर दस्तावेज़ के लिए एक से ज़्यादा इंपोर्ट मैप बनाए जा सकते हैं. इसके लिए, उन्हें एक जैसा और तय तरीके से मर्ज किया जाता है.

स्टोरेज ऐक्सेस हेडर

पुष्टि किए गए एम्बेड के लिए, बिना सेगमेंट वाली कुकी के लिए ऑप्ट इन करने का दूसरा तरीका उपलब्ध कराता है. इन हेडर से पता चलता है कि किसी नेटवर्क अनुरोध में, बिना सेगमेंट वाली कुकी शामिल हैं या नहीं. साथ ही, इनसे सर्वर को 'स्टोरेज ऐक्सेस' की उन अनुमतियों को चालू करने की अनुमति मिलती है जो उन्हें पहले ही दी जा चुकी हैं. 'स्टोरेज ऐक्सेस' की अनुमति को चालू करने का कोई दूसरा तरीका देने पर, नॉन-iframe रिसॉर्स का इस्तेमाल किया जा सकता है. साथ ही, पुष्टि किए गए एम्बेड के लिए इंतज़ार का समय कम किया जा सकता है.

Promise<DOMString> की मदद से ClipboardItem बनाने की सुविधा

ClipboardItem, जो असाइन किए गए क्लिपबोर्ड write() तरीके का इनपुट है, अब अपने कन्स्ट्रक्टर में ब्लॉब के साथ-साथ स्ट्रिंग वैल्यू भी स्वीकार करता है. ClipboardItemData, Blob, स्ट्रिंग या ऐसा Promise हो सकता है जो Blob या स्ट्रिंग में बदल जाता है.

WebAssembly Memory64

memory64 के प्रस्ताव में, 2^32 बिट से ज़्यादा साइज़ वाली लीनियर WebAssembly मेमोरी के लिए सहायता जोड़ी गई है. इसमें कोई नया निर्देश नहीं दिया गया है. इसके बजाय, मेमोरी और टेबल के लिए 64-बिट इंडेक्स की अनुमति देने के लिए, मौजूदा निर्देशों को बढ़ाया गया है.

​​वेब पुष्टि करने वाला एपीआई: PublicKeyCredential getClientCapabilities() तरीका

PublicKeyCredential getClientCapabilities() तरीके से यह पता लगाया जा सकता है कि उपयोगकर्ता के क्लाइंट पर, WebAuthn की कौनसी सुविधाएं काम करती हैं. यह तरीका, काम करने वाली सुविधाओं की सूची दिखाता है. इससे डेवलपर, क्लाइंट की खास सुविधाओं के आधार पर पुष्टि करने के अनुभव और वर्कफ़्लो को पसंद के मुताबिक बना सकते हैं.

WebGPU: एक-कॉम्पोनेंट वाले वर्टिक्स फ़ॉर्मैट (और unorm8x4-bgra)

वेबजीपीयू के शुरुआती वर्शन में मौजूद नहीं होने वाले अतिरिक्त वर्टिक्स फ़ॉर्मैट जोड़ता है. ऐसा, macOS के पुराने वर्शन या काम न करने की वजह से होता है. ये वर्शन अब किसी भी ब्राउज़र पर काम नहीं करते. एक कॉम्पोनेंट वाले वर्टिक्स फ़ॉर्मैट की मदद से, ऐप्लिकेशन सिर्फ़ ज़रूरी डेटा का अनुरोध कर सकते हैं. इससे पहले, उन्हें 8 और 16-बिट डेटा टाइप के लिए, कम से कम दो गुना ज़्यादा अनुरोध करने पड़ते थे. unorm8x4-bgra फ़ॉर्मैट की मदद से, एक ही शेडर को बनाए रखते हुए, BGRA में कोड किए गए वर्टिक्स कलर को लोड करना थोड़ा आसान हो जाता है.

Web Cryptography API का X25519 एल्गोरिदम

"X25519" एल्गोरिदम, [RFC7748] में बताए गए X25519 फ़ंक्शन का इस्तेमाल करके, की-एग्रीमेंट करने के लिए टूल उपलब्ध कराता है. "X25519" एल्गोरिदम आइडेंटिफ़ायर का इस्तेमाल, SubtleCrypto इंटरफ़ेस में किया जा सकता है. इससे, लागू किए गए ऑपरेशन ऐक्सेस किए जा सकते हैं: generateKey, importKey, exportKey, deriveKey, और deriveBits.

नए ऑरिजिन ट्रायल

Chrome 133 में, इन नए ऑरिजिन ट्रायल में ऑप्ट इन किया जा सकता है.

एनर्जी सेवर मोड चालू होने पर, टैब फ़्रीज़ होने की सुविधा से ऑप्ट आउट करना

इस ऑप्ट आउट ट्रायल की मदद से, साइटें एनर्जी सेवर मोड के उस व्यवहार से ऑप्ट आउट कर सकती हैं जो Chrome 133 में उपलब्ध है.

बंद की गई सुविधाएं और हटाए गए आइटम

Chrome के इस वर्शन में, नीचे दी गई सुविधाएं बंद की गई हैं और हटा दी गई हैं. जिन सुविधाओं को बंद किया जा रहा है, उन सुविधाओं की सूची देखने के लिए ChromeStatus.com पर जाएं. साथ ही, उन सुविधाओं की सूची भी देखें जो पहले बंद की जा चुकी हैं.

Chrome के इस वर्शन में एक सुविधा बंद कर दी गई है.

WebGPU की maxInterStageShaderComponents सीमा को बंद करना

कई वजहों से, maxInterStageShaderComponents limit के इस्तेमाल पर रोक लगा दी गई है. Chrome के वर्शन 135 में, इसे हटाने की तारीख.

  • maxInterStageShaderVariables के साथ डुप्लीकेट: यह सीमा पहले से ही एक जैसे मकसद के लिए काम करती है. यह शेडर के अलग-अलग चरणों के बीच भेजे गए डेटा की संख्या को कंट्रोल करती है.
  • मामूली अंतर: दोनों सीमाओं का हिसाब लगाने के तरीके में थोड़ा अंतर है. हालांकि, यह अंतर मामूली है और maxInterStageShaderVariables की सीमा के अंदर इसे असरदार तरीके से मैनेज किया जा सकता है.
  • आसान बनाना: maxInterStageShaderComponents को हटाने से, शेडर इंटरफ़ेस को बेहतर बनाया जा सकता है और डेवलपर के लिए इसे इस्तेमाल करना आसान हो जाता है. थोड़े-बहुत अंतर वाली दो अलग-अलग सीमाओं को मैनेज करने के बजाय, वे ज़्यादा सही नाम और बेहतर maxInterStageShaderVariables पर फ़ोकस कर सकते हैं.

Chrome के इस वर्शन में दो सुविधाएं हटा दी गई हैं.

पहले, जब किसी संसाधन को <link rel=prefetch> का इस्तेमाल करके पहले से फ़ेच किया जाता था, तो Chrome, पांच मिनट के अंदर पहली बार इस्तेमाल करने के लिए, उसके कैश सेमेटिक्स (जैसे, max-age और no-cache) को अनदेखा कर देता था, ताकि उसे फिर से फ़ेच न करना पड़े. अब Chrome, इस खास मामले को हटा देता है और सामान्य एचटीटीपी कैश सेमेंटेक्स का इस्तेमाल करता है.

इसका मतलब है कि <link rel=prefetch> का फ़ायदा पाने के लिए, वेब डेवलपर को कैश मेमोरी में सेव करने के लिए सही हेडर (Cache-Control या Expires) शामिल करने होंगे.

इसका असर, स्टैंडर्ड के मुताबिक न होने वाले <link rel=prerender> पर भी पड़ता है.

Chrome के स्वागत पेज को हटाना, जो शुरुआती सेटिंग वाले पहले रन टैब से ट्रिगर होता है

initial_preferences फ़ाइल की first_run_tabs प्रॉपर्टी में chrome://welcome को शामिल करने से अब कोई असर नहीं पड़ेगा. इसे हटा दिया गया है, क्योंकि यह पेज, डेस्कटॉप प्लैटफ़ॉर्म पर ट्रिगर होने वाले 'पहली बार इस्तेमाल करने का अनुभव' के साथ काम नहीं करता.