LayoutNG एक नया लेआउट इंजन है. इसे Chrome 76 में रिलीज़ किया जाएगा. इसे बनाने में कई साल लगे हैं. इसमें कई बेहतरीन सुधार किए गए हैं. साथ ही, परफ़ॉर्मेंस को बेहतर बनाने और लेआउट की बेहतर सुविधाएं देने के लिए, और भी सुधार किए जाएंगे.
नया क्या है?
- परफ़ॉर्मेंस को अलग-अलग करने की सुविधा को बेहतर बनाता है.
- लैटिन के अलावा अन्य स्क्रिप्ट के लिए बेहतर सहायता.
- फ़्लोट और मार्जिन से जुड़ी कई समस्याओं को ठीक करता है.
- वेब के साथ काम करने से जुड़ी कई समस्याओं को ठीक करता है.
कृपया ध्यान दें कि LayoutNG को अलग-अलग चरणों में लॉन्च किया जाएगा. Chrome 76 में, इनलाइन और ब्लॉक लेआउट के लिए LayoutNG का इस्तेमाल किया जाता है. आने वाले रिलीज़ में, टेबल, फ़्लेक्सबॉक्स, ग्रिड, और ब्लॉक फ़्रैगमेंटेशन जैसे अन्य लेआउट प्राइमिटिव को बदल दिया जाएगा.
डेवलपर के लिए दिखने वाले बदलाव
हालांकि, उपयोगकर्ताओं को दिखने वाले असर का कम से कम होना चाहिए, लेकिन LayoutNG कुछ व्यवहारों में बहुत ही छोटे बदलाव करता है. साथ ही, सैकड़ों टेस्ट ठीक करता है और अन्य ब्राउज़र के साथ काम करने की सुविधा को बेहतर बनाता है. हमारी पूरी कोशिश के बावजूद, ऐसा हो सकता है कि इससे कुछ साइटों और ऐप्लिकेशन के रेंडर होने या काम करने का तरीका थोड़ा अलग हो जाए.
परफ़ॉर्मेंस की विशेषताएं भी काफ़ी अलग हैं. हालांकि, पूरी परफ़ॉर्मेंस पहले जैसी ही है या उससे थोड़ी बेहतर है, लेकिन कुछ इस्तेमाल के उदाहरणों में परफ़ॉर्मेंस में सुधार दिख सकता है. वहीं, कुछ उदाहरणों में कम से कम कुछ समय के लिए परफ़ॉर्मेंस में गिरावट आ सकती है.
फ़्लोट
LayoutNG में फ़्लोटिंग एलिमेंट (float: left;
और float: right;
) के लिए फिर से सहायता लागू की गई है. इससे, अन्य कॉन्टेंट के हिसाब से फ़्लोट के प्लेसमेंट से जुड़ी कई समस्याएं ठीक हो गई हैं.
सुपरइम्पोज़्ड सामग्री
लेगसी फ़्लोट लागू करने पर, फ़्लोटिंग एलिमेंट के आस-पास कॉन्टेंट डालते समय मार्जिन का सही तरीके से हिसाब नहीं लगाया जाता था. इस वजह से, कॉन्टेंट, फ़्लोट के साथ पूरी तरह या कुछ हद तक ओवरलैप हो जाता था. आम तौर पर, यह गड़बड़ी तब दिखती है, जब किसी पैराग्राफ़ के बगल में इमेज को इस तरह से रखा जाता है कि इमेज के आस-पास मौजूद टेक्स्ट की लाइन की ऊंचाई के हिसाब से इमेज का साइज़ तय न हो पाए. (Chromium बग #861540 देखें.)

टेक्स्ट, दाईं ओर मौजूद फ़्लोटिंग इमेज के ऊपर ओवरलैप होता है

टेक्स्ट, दाईं ओर मौजूद फ़्लोटिंग इमेज के बगल में होता है
एक ही समस्या एक लाइन में भी हो सकती है. यहां दिए गए उदाहरण में, #895962 फ़्लोटिंग एलिमेंट के बाद, नेगेटिव मार्जिन वाला ब्लॉक एलिमेंट दिखाया गया है. टेक्स्ट, फ़्लोट के साथ ओवरलैप नहीं होना चाहिए.

टेक्स्ट, फ़्लोटिंग ऑरेंज एलिमेंट के ऊपर दिखता है

टेक्स्ट, फ़्लोटिंग ऑरेंज एलिमेंट के बगल में दिखता है
फ़ॉर्मैटिंग के हिसाब से कॉन्टेक्स्ट पोज़िशनिंग
जब ब्लॉक फ़ॉर्मैटिंग कॉन्टेक्स्ट बनाने वाले किसी एलिमेंट का साइज़, फ़्लोट के बगल में तय किया जाता है, तो लेगसी लेआउट इंजन, ब्लॉक का साइज़ तय करने की कोशिश करता है. हालांकि, यह कोशिश तय संख्या में ही की जाती है. इस तरीके से, अनुमान लगाना मुश्किल और व्यवहार अस्थिर हो गया. साथ ही, यह अन्य तरीकों से मेल नहीं खाता. LayoutNG में ब्लॉक का साइज़ तय करते समय, सभी फ़्लोट को ध्यान में रखा जाता है. (Chromium बग #548033 देखें.)
अब एब्सोलूट और फ़िक्स्ड पोज़िशनिंग, W3C के स्पेसिफ़िकेशन के मुताबिक ज़्यादा काम करती है और अन्य ब्राउज़र के व्यवहार से बेहतर तरीके से मेल खाती है. इन दोनों के बीच का अंतर, इन दो मामलों में सबसे ज़्यादा दिखता है:
- मल्टी-लाइन इनलाइन ब्लॉक
अगर पूरी तरह से पोज़िशन किया गया कोई ब्लॉक, एक से ज़्यादा लाइनों में फैला हुआ है, तो हो सकता है कि लेगसी इंजन, ब्लॉक के बॉउंड का हिसाब लगाने के लिए, लाइनों के सिर्फ़ सबसेट का गलत इस्तेमाल करे. - वर्टिकल राइटिंग मोड
लेगसी इंजन को वर्टिकल राइटिंग मोड में, डिफ़ॉल्ट पोज़िशन में, फ़्लो से बाहर के एलिमेंट को डालने में कई समस्याएं आती थीं. बेहतर लिखने के मोड के बारे में ज़्यादा जानकारी के लिए, अगला सेक्शन देखें.
दाईं से बाईं (RTL) ओर लिखी जाने वाली भाषाएं और वर्टिकल राइटिंग मोड
LayoutNG को शुरू से ही वर्टिकल राइटिंग मोड और दाईं से बाईं ओर लिखने वाली भाषाओं के साथ काम करने के लिए डिज़ाइन किया गया था. इसमें, दोनों दिशाओं में लिखे जाने वाले कॉन्टेंट को भी शामिल किया गया है.
दोनों दिशाओं में चलने वाला टेक्स्ट
LayoutNG, यूनिकोड स्टैंडर्ड के मुताबिक बाईडायरेक्शनल एल्गोरिदम के सबसे अप-टू-डेट वर्शन के साथ काम करता है. इस अपडेट में रेंडर करने से जुड़ी कई गड़बड़ियां ठीक की गई हैं. साथ ही, इसमें कुछ ऐसी सुविधाएं भी शामिल हैं जो पहले मौजूद नहीं थीं. जैसे, ब्रैकेट के साथ काम करने की सुविधा. Chromium गड़बड़ी #302469 देखें.
ऑर्थोगोनल फ़्लो
LayoutNG, वर्टिकल फ़्लो लेआउट को ज़्यादा सटीक बनाता है. उदाहरण के लिए, बिल्कुल सही जगह पर मौजूद ऑब्जेक्ट का प्लेसमेंट और ऑर्थोगोनल फ़्लो बॉक्स का साइज़ (खास तौर पर, जब प्रतिशत का इस्तेमाल किया जाता है). W3C के टेस्ट सुइट में मौजूद 1,258 टेस्ट में से, पुराने लेआउट इंजन में पास न होने वाले 103 टेस्ट, LayoutNG में पास हो गए.
इन्सट्रिंसिक साइज़िंग
जब किसी ब्लॉक में ऑर्थोगोनल राइटिंग मोड में चाइल्ड एलिमेंट होते हैं, तो अब इनट्रिन्सिक साइज़ का हिसाब सही तरीके से लगाया जाता है.
टेक्स्ट लेआउट और लाइन ब्रेक
लेगसी Chromium लेआउट इंजन, टेक्स्ट एलिमेंट और लाइन को एक-एक करके लेआउट करता था. यह तरीका ज़्यादातर मामलों में अच्छा काम करता था. हालांकि, स्क्रिप्ट के साथ काम करने और अच्छी परफ़ॉर्मेंस पाने के लिए, इसमें बहुत ज़्यादा जटिलताएं थीं. इससे, साइज़ के हिसाब से कॉन्टेंट के कंटेनर और उनके कॉन्टेंट के साइज़ में मामूली अंतर या लाइन ब्रेक की गड़बड़ियां भी हो सकती थीं.
LayoutNG में, टेक्स्ट को पैराग्राफ़ लेवल पर लेआउट किया जाता है और फिर उसे लाइनों में बांटा जाता है. इससे बेहतर परफ़ॉर्मेंस, बेहतर क्वालिटी का टेक्स्ट रेंडरिंग, और लाइन ब्रेक करने की सुविधा मिलती है. इन दोनों के बीच के सबसे अहम अंतरों के बारे में यहां बताया गया है.
एलिमेंट की सीमाओं के बीच जॉइन करना
कुछ स्क्रिप्ट में, आस-पास मौजूद कुछ वर्णों को एक साथ जोड़ा जा सकता है. ऐरेबिक भाषा का यह उदाहरण देखें:
LayoutNG में, अब वर्णों को अलग-अलग एलिमेंट में होने पर भी जॉइन किया जा सकता है. अलग-अलग स्टाइल लागू करने पर भी जॉइन सेव रहेंगे. (Chromium बग #6122 देखें.)
ग्राफ़िम, किसी भाषा के लेखन सिस्टम की सबसे छोटी इकाई होती है. उदाहरण के लिए, अंग्रेज़ी और लैटिन वर्णमाला का इस्तेमाल करने वाली अन्य भाषाओं में, हर अक्षर एक ग्राफ़ेम होता है.
यहां दी गई इमेज में, लेगसी लेआउट इंजन और LayoutNG में, नीचे दिए गए एचटीएमएल को रेंडर करने का तरीका दिखाया गया है:
<div>نسق</div>
<div>نس<span>ق</span></div>

ध्यान दें कि दूसरे अक्षर का फ़ॉर्म कैसे बदलता है

अब दोनों वर्शन एक जैसे हैं
चाइनीज़, जैपनीज़, और कोरियन (CJK) लिगचर
हालांकि, Chromium पहले से ही लिगेचर के साथ काम करता है और उन्हें डिफ़ॉल्ट रूप से चालू करता है, लेकिन इसमें कुछ सीमाएं हैं: रेंडरिंग ऑप्टिमाइज़ेशन की वजह से, लेगसी लेआउट इंजन में एक से ज़्यादा CJK कोडपॉइंट वाले लिगेचर काम नहीं करते. LayoutNG इन पाबंदियों को हटा देता है. साथ ही, यह किसी भी स्क्रिप्ट के लिए लिगचर का इस्तेमाल करता है.
नीचे दिए गए उदाहरण में, Adobe SourceHanSansJP फ़ॉन्ट का इस्तेमाल करके, तीन डिसक्रेशनरी लिगचर को रेंडर किया गया है:

MHz सही तरीके से लिगचर बनाता है
लेकिन マンション और 10点 नहीं बनाते

तीनों ग्रुप उम्मीद के मुताबिक लिगचर बनाते हैं
कॉन्टेंट के हिसाब से साइज़ वाले एलिमेंट
कॉन्टेंट के हिसाब से साइज़ होने वाले एलिमेंट (जैसे, इनलाइन ब्लॉक) के लिए, मौजूदा लेआउट इंजन पहले ब्लॉक का साइज़ कैलकुलेट करता है और फिर कॉन्टेंट पर लेआउट लागू करता है. कुछ मामलों में, जैसे कि जब फ़ॉन्ट कार्निंग ज़्यादा होती है, तो कॉन्टेंट और ब्लॉक के साइज़ में अंतर हो सकता है. LayoutNG में, इस गड़बड़ी को ठीक कर दिया गया है, क्योंकि ब्लॉक का साइज़, असल कॉन्टेंट के हिसाब से तय किया जाता है.
नीचे दिए गए उदाहरण में, कॉन्टेंट के हिसाब से साइज़ किया गया पीला ब्लॉक दिखाया गया है. इसमें Lato फ़ॉन्ट का इस्तेमाल किया जाता है, जो T और - के बीच के स्पेस को अडजस्ट करने के लिए, कर्नरिंग का इस्तेमाल करता है. पीले बॉक्स के बाउंड, टेक्स्ट के बाउंड से मेल खाने चाहिए.

आखिरी T के बाद मौजूद खाली जगह पर ध्यान दें

ध्यान दें कि बॉक्स के बाएं और दाएं किनारे, टेक्स्ट के बाउंड से कैसे मैच करते हैं
लाइन रैपिंग
ऊपर बताई गई समस्या की तरह ही, अगर साइज़ के हिसाब से कॉन्टेंट के लिए बने ब्लॉक का कॉन्टेंट, ब्लॉक से बड़ा (चौड़ा) है, तो कभी-कभी कॉन्टेंट ग़ैर-ज़रूरी तरीके से रैप हो सकता है. ऐसा बहुत कम होता है, लेकिन कभी-कभी अलग-अलग दिशाओं में चलने वाले कॉन्टेंट के लिए ऐसा होता है.

ध्यान दें कि टेक्स्ट के दाईं ओर, लाइन ब्रेक और अतिरिक्त स्पेस की ज़रूरत नहीं है

ध्यान दें कि बॉक्स के बाएं और दाएं किनारे, टेक्स्ट के बाउंड से कैसे मैच करते हैं
ज़्यादा जानकारी
LayoutNG की मदद से ठीक की गई, संगतता से जुड़ी समस्याओं और गड़बड़ियों के बारे में ज़्यादा जानकारी के लिए, कृपया ऊपर दी गई समस्याएं देखें. इसके अलावा, LayoutNG में ठीक की गई के तौर पर मार्क की गई गड़बड़ियों के लिए, Chromium के गड़बड़ी डेटाबेस को खोजें.
अगर आपको लगता है कि LayoutNG की वजह से किसी वेबसाइट में गड़बड़ी हुई है, तो कृपया गड़बड़ी की शिकायत करें. हम इसकी जांच करेंगे.