ब्राउज़र सीएसएस चयनकर्ताओं से दाएं से बाएं क्यों मेल खाते हैं?

Question

CSS चयनकर्ता ब्राउज़र इंजन से दाएं से बाएं से मेल खाते हैं। इसलिए वे पहले बच्चों को ढूंढते हैं और फिर उनके माता-पिता को देखते हैं कि वे नियम के बाकी हिस्सों से मेल खाते हैं या नहीं।

1. ऐसा क्यों है?
2. क्या यह सिर्फ इसलिए है क्योंकि युक्ति कहती है?
3. यदि यह बाएं से दाएं का मूल्यांकन किया गया तो क्या यह अंतिम लेआउट को प्रभावित करता है?

मेरे लिए ऐसा करने का सबसे सरल तरीका यह होगा कि चयनकर्ता कम से कम तत्वों का उपयोग करें। तो पहले आईडी (क्योंकि उन्हें केवल 1 तत्व वापस करना चाहिए)। तब शायद कक्षाएं या एक तत्व जिसमें सबसे कम संख्या में नोड्स होते हैं - जैसे कि पृष्ठ पर केवल एक ही अवधि हो सकती है इसलिए किसी भी नियम के साथ सीधे उस नोड पर जाएं जो एक अवधि का संदर्भ देता है।

यहाँ कुछ लिंक मेरे दावों का समर्थन कर रहे हैं

1. http://code.google.com/speed/page-speed/docs/rendering.html
2. https://developer.mozilla.org/en/Writing_Efficient_CSS

---

ऐसा लगता है कि माता-पिता के सभी बच्चों (जो कई हो सकते हैं) के बजाय एक बच्चे के सभी माता-पिता जो एक होना चाहिए, को देखने से बचने के लिए इस तरह से किया जाता है। यहां तक ​​कि अगर डोम गहरा है तो यह आरटीएल मिलान में कई के बजाय केवल एक नोड प्रति स्तर पर दिखेगा। क्या CSS चयनकर्ताओं LTR या RTL का मूल्यांकन करना आसान / तेज है?

Comments

3. नहीं - कोई फर्क नहीं पड़ता कि आप इसे कैसे पढ़ते हैं, चयनकर्ता हमेशा तत्वों के एक ही सेट से मेल खाता है।

— 05इमे विदेस

इसके लायक क्या है, एक ब्राउज़र यह नहीं मान सकता कि आपकी आईडी अद्वितीय हैं। आप अपने DOM पर एक ही id = "foo" चिपका सकते हैं, और एक #fooचयनकर्ता को उन सभी नोड्स का मिलान करना होगा। jQuery के पास यह कहने का विकल्प है कि $ ("# foo") हमेशा केवल एक तत्व वापस करेगा, क्योंकि वे अपने स्वयं के एपीआई को अपने नियमों से परिभाषित कर रहे हैं। लेकिन ब्राउज़र को सीएसएस को लागू करने की आवश्यकता है, और सीएसएस दी गई आईडी के साथ दस्तावेज़ में सब कुछ मेल करने के लिए कहता है।

— बोरिस ज़बर्स्की

@ क्वेंटिन एक "गैर-अनुरूप" (एचटीएमएल में) दस्तावेज़ आईडी गैर-अद्वितीय हो सकते हैं, और उन दस्तावेजों में सीएसएस को उस आईडी के साथ सभी तत्वों के मिलान की आवश्यकता होती है। CSS अपने आप में विशिष्ट होने की कोई आदर्श आवश्यकताओं को नहीं रखता है; आपके द्वारा उद्धृत पाठ सूचनात्मक है।

— बोरिस ज़बर्स्की

@Boris Zbarsky jQuery क्या jQuery के भीतर कोड पथ पर निर्भर करता है। कुछ मामलों में, jQuery NodeSelector API (देशी querySelectorAll) का उपयोग करता है । अन्य मामलों में, Sizzle का उपयोग किया जाता है। Sizzle कई ID से मेल नहीं खाता, लेकिन QSA करता है (AYK)। लिया गया पथ चयनकर्ता, संदर्भ और ब्राउज़र और उसके संस्करण पर निर्भर करता है। jQuery के क्वेरी एपीआई का उपयोग करता है जिसे मैंने "मूल निवासी, दोहरी दृष्टिकोण" कहा है। मैंने उस पर एक लेख लिखा था, लेकिन यह नीचे है। हालांकि आप यहाँ पा सकते हैं: fortybelow.ca/hosted/dhtmlkitchen/JavaScript-Query-Engines.html

— गैरेट

मुझे किसी पर भी यकीन नहीं है, लेकिन आप दोनों यह पता लगा सकते हैं कि इस बातचीत के लंबे समय के साथ क्या हो रहा है। हमारे पास इन विस्तारित चर्चाओं के लिए चैट है। जो कुछ भी आप वास्तव में रखना चाहते हैं उसे प्रश्न या उत्तर में डाल दिया जाना चाहिए, खासकर अगर यह जानकारी को स्पष्ट कर रहा हो। स्टैक ओवरफ्लो चर्चाओं को अच्छी तरह से हैंडल नहीं करता है।

— जॉर्ज स्टॉकर

Answer 1

ध्यान रखें कि जब कोई ब्राउज़र चयनकर्ता मिलान कर रहा होता है, तो इसमें एक तत्व होता है (एक वह जिसके लिए शैली निर्धारित करने की कोशिश की जाती है) और आपके सभी नियम और उनके चयनकर्ता और यह खोजने की आवश्यकता होती है कि कौन से नियम तत्व से मेल खाते हैं। यह सामान्य jQuery की बात से अलग है, कहते हैं, जहां आपके पास केवल एक चयनकर्ता है और आपको उस चयनकर्ता से मेल खाने वाले सभी तत्वों को खोजने की आवश्यकता है।

यदि आपके पास केवल एक चयनकर्ता है और उस चयनकर्ता के खिलाफ तुलना करने के लिए केवल एक तत्व है, तो बाएं से दाएं कुछ मामलों में अधिक समझ में आता है। लेकिन यह निश्चित रूप से ब्राउज़र की स्थिति नहीं है। ब्राउज़र जीमेल या जो कुछ भी प्रस्तुत करने <span>की कोशिश कर रहा है और जिसकी शैली के लिए कोशिश कर रहा है और 10,000+ नियम जीमेल अपनी स्टाइलशीट में डाल रहा है (मैं उस नंबर को नहीं बना रहा हूं)।

विशेष रूप से, उस स्थिति में जब ब्राउज़र चयनकर्ताओं में से अधिकांश को देख रहा है, तो यह विचार कर रहा है कि प्रश्न में तत्व से मेल नहीं खाता है। तो समस्या यह तय करने में से एक बन जाती है कि एक चयनकर्ता जितनी तेजी से मेल नहीं खाता है; यदि उन मामलों में थोड़ा अतिरिक्त काम करने की आवश्यकता होती है जो आपके द्वारा मेल नहीं खाने वाले मामलों में आपके द्वारा बचाए गए सभी कार्यों के कारण जीत जाते हैं।

यदि आप अपने तत्व के खिलाफ चयनकर्ता के सबसे दाहिने हिस्से का मिलान करके शुरू करते हैं, तो संभावना है कि यह मेल नहीं खाएगा और आपका काम हो गया। यदि यह मेल खाता है, तो आपको अधिक काम करना होगा, लेकिन केवल आपके पेड़ की गहराई के अनुपात में, जो कि ज्यादातर मामलों में उतना बड़ा नहीं है।

दूसरी ओर, यदि आप चयनकर्ता के बाएं भाग से मेल खाते हुए शुरू करते हैं ... तो आप इसके खिलाफ क्या मेल खाते हैं? आपको डोम चलना शुरू करना होगा, नोड्स की तलाश में जो इसे मेल कर सकते हैं। बस यह पता लगाना कि कुछ भी मेल नहीं खा रहा है कि बाएं हिस्से में कुछ समय लग सकता है।

इसलिए ब्राउज़र दाईं ओर से मेल खाते हैं; यह एक स्पष्ट शुरुआती बिंदु देता है और आपको अधिकांश उम्मीदवार चयनकर्ताओं से बहुत जल्दी छुटकारा दिलाता है। आप कुछ डेटा http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17465 (हालांकि नोटेशन भ्रामक है) पर देख सकते हैं , लेकिन यह विशेष रूप से जीमेल के लिए जीमेल है। दो साल पहले, (नियम, तत्व) जोड़े के 70% के लिए आप तय कर सकते हैं कि नियम के लिए सही चयनकर्ता के टैग / वर्ग / आईडी भागों की जांच करने के बाद नियम मेल नहीं खाता है। मोजिला के पगेलोड प्रदर्शन परीक्षण सूट की संगत संख्या 72% थी। तो यह वास्तव में उन सभी नियमों के 2/3 से छुटकारा पाने की कोशिश करने के लायक है जितनी जल्दी हो सके और फिर केवल शेष 1/3 से मेल खाने की चिंता करें।

ध्यान दें कि ऐसे अन्य अनुकूलन ब्राउज़र हैं जो पहले से ही नियमों से मेल खाने की कोशिश से बचने के लिए करते हैं जो निश्चित रूप से मेल नहीं खाएंगे। उदाहरण के लिए, यदि सबसे सही चयनकर्ता के पास एक आईडी है और वह आईडी तत्व की आईडी से मेल नहीं खाता है, तो उस तत्व के खिलाफ उस चयनकर्ता के साथ गेको में मिलान करने का कोई प्रयास नहीं होगा: "आईडी के साथ चयनकर्ताओं" का सेट जो प्रयास किया जाता है तत्व की आईडी पर हैशटेबल लुकअप से आता है। तो यह 70% नियम हैं जिनके मिलान करने का एक अच्छा मौका है जो अभी भी सही चयनकर्ता के टैग / वर्ग / आईडी पर विचार करने के बाद भी मेल नहीं खाते हैं।

Comments

थोड़े से बोनस के रूप में, इसे अंग्रेजी में भी LTR की तुलना में RTL पढ़ना अधिक समझ में आता है। एक उदाहरण: stackoverflow.com/questions/3851635/css-combinator-precedence/...

— BoltClock

ध्यान दें कि RTL मिलान केवल कॉम्बिनेटर पर लागू होता है । यह सरल चयनकर्ता स्तर तक नीचे नहीं जाता है। यही है, एक ब्राउज़र सबसे सही कंपाउंडर का चयन करता है , या साधारण चयनकर्ताओं के अनुक्रम और इसे परमाणु से मेल खाने का प्रयास करता है। फिर, यदि कोई मेल है, तो यह अगले कंपाउंड चयनकर्ता के लिए बाईं ओर कॉम्बीनेटर का अनुसरण करता है और उस स्थिति में तत्व की जांच करता है, और इसी तरह। ऐसा कोई सबूत नहीं है कि एक ब्राउज़र एक यौगिक चयनकर्ता RTL के प्रत्येक भाग को पढ़ता है; वास्तव में, अंतिम पैराग्राफ ठीक ही दिखाता है (आईडी चेक हमेशा पहले आते हैं)।

— BoltClock

दरअसल, जब तक आप चयनकर्ताओं से मेल खा रहे होते हैं, कम से कम गेको में, पहले नाम और नाम स्थान आता है। आईडी (साथ ही टैग्नैम और क्लासनेम) को एक पूर्व-फ़िल्टरिंग चरण में माना जाता है जो चयनकर्ताओं के साथ मिलान करने की कोशिश किए बिना अधिकांश नियमों को समाप्त करता है।

— बोरिस ज़बर्स्की

यही कारण है कि हो सकता है मदद क्या अनुकूलन यूए कर रहा है पर निर्भर करता है, लेकिन यह छिपकली में पूर्व छानने कदम मैं ऊपर का वर्णन मदद नहीं करेगा। एक दूसरा फ़िल्टरिंग कदम है, जो आईडी और कक्षाओं पर काम करता है जो कि वंशज कॉम्बीनेटर के लिए उपयोग किया जाता है, हालांकि यह मदद कर सकता है।

— बोरिस ज़बर्स्की

@ बेंटो सियारो: विशिष्टताओं की समस्याओं का भी उल्लेख नहीं।

— BoltClock

Answer 2

दाएं से बाएं पार्सिंग, जिसे नीचे-अप पार्सिंग भी कहा जाता है, वास्तव में ब्राउज़र के लिए कुशल है।

निम्नलिखित को धयान मे रखते हुए:

#menu ul li a { color: #00f; }

ब्राउज़र पहले a, फिर li, फिर ul, और फिर के लिए जाँच करता है #menu।

ऐसा इसलिए है क्योंकि ब्राउज़र जिस पृष्ठ को स्कैन कर रहा है, उसे बस वर्तमान तत्व / नोड और पिछले सभी नोड्स / तत्वों को देखना होगा जिन्हें उसने स्कैन किया है।

ध्यान देने वाली बात यह है कि ब्राउजर पल की प्रोसेसिंग करना शुरू कर देता है, इसे एक पूर्ण टैग / नोड मिल जाता है और इसके लिए पूरे पेज का इंतजार नहीं करना पड़ता है, सिवाय इसके कि जब यह एक स्क्रिप्ट पाता है, तो उस स्थिति में यह अस्थायी रूप से रुक जाता है और स्क्रिप्ट के निष्पादन को पूरा करता है। आगे बढ़ता है।

यदि यह दूसरे तरीके से राउंड करता है तो यह अक्षम होगा क्योंकि ब्राउज़र ने पाया कि यह तत्व पहले चेक पर स्कैन कर रहा था, लेकिन फिर सभी अतिरिक्त चयनकर्ताओं के लिए दस्तावेज़ के माध्यम से देखना जारी रखने के लिए मजबूर किया गया था। इसके लिए ब्राउज़र में संपूर्ण html होना चाहिए और css पेंटिंग शुरू करने से पहले पूरे पृष्ठ को स्कैन करने की आवश्यकता हो सकती है।

यह इस बात से उलट है कि कैसे अधिकांश लिबास डोम पर हावी हो जाते हैं। वहाँ डोम का निर्माण किया गया है और इसे पूरे पृष्ठ को स्कैन करने की आवश्यकता नहीं है बस पहले तत्व को ढूंढें और फिर इसके अंदर दूसरों से मिलान करें।

Answer 3

यह अधिक विशिष्ट से कम विशिष्ट तक कैस्केडिंग की अनुमति देता है। यह एप्लिकेशन में शॉर्ट सर्किट की भी अनुमति देता है। यदि अधिक विशिष्ट नियम उन सभी पहलुओं पर लागू होता है जो माता-पिता के नियम पर लागू होते हैं, तो सभी माता-पिता के नियमों की अनदेखी की जाती है। यदि माता-पिता में अन्य बिट्स हैं, तो उन्हें लागू किया जाता है।

यदि आप दूसरे रास्ते पर चले गए, तो आप माता-पिता के अनुसार प्रारूपित करेंगे और फिर हर बार बच्चे को कुछ अलग करने के लिए अधिलेखित करेंगे। लंबे समय में, पहले से ही ध्यान में रखे गए नियमों में वस्तुओं की अनदेखी की तुलना में यह बहुत अधिक काम है।

Comments

यह एक अलग मुद्दा है। आप विशिष्टता द्वारा नियमों को क्रमबद्ध करके और फिर उनके खिलाफ विशिष्टता क्रम में मिलान करके कैस्केडिंग करते हैं। लेकिन यहाँ सवाल यह है कि किसी दिए गए नियम के लिए आप एक विशेष तरीके से इसके चयनकर्ताओं से मेल खाते हैं।

— बोरिस ज़बर्स्की