इसे पोस्ट करने के लिए धन्यवाद! संभावनाओं के लिए बहुत उत्साहित

इन परिभाषित शैलियों को पूरे उपयोगकर्ता की साइट पर वैश्विक रूप से लागू किया जा सकता है (उदाहरण के लिए फ़ॉन्ट स्केल, या रंग, या सभी बटन कैसे दिखते हैं) घोषित करना।

फिलहाल, गुटेनबर्ग केवल प्रति-ब्लॉक स्तर पर शैली अनुकूलन का समर्थन करता है। इसलिए एक पोस्ट में एक बटन को अपडेट करना, अन्य पेजों पर बटन को पूर्वव्यापी रूप से अपडेट नहीं करेगा।

स्पष्ट करने के लिए, क्या उपयोगकर्ता संपादक UI के माध्यम से सभी बटनों पर रंग, या सभी अनुच्छेदों पर फ़ॉन्ट-आकार को अपडेट कर पाएंगे? और यदि हां, तो क्या वे अब भी प्रति-ब्लॉक आधार पर समायोजन करने में सक्षम होंगे?

गुटेनबर्ग ब्लॉकों को कैसे सहेजा/रेंडर किया जाता है, उसी तरह, हम आउटपुट किए गए HTML को ग्लोबल स्टाइल्स से सहेज सकते हैं और स्टोर कर सकते हैं। इस HTML में उत्पन्न चर शामिल हैं, जिन्हें PHP के माध्यम से सिर में इंजेक्ट किया जा सकता है, जिसका अर्थ है कि लोड पर आवश्यक चर/शैली समेकन नहीं है। यह पहले ही किया जा चुका है।

क्या सामने के छोर पर CSS चरों का उपयोग करने का कोई अच्छा विकल्प होगा? यहां चिंता यह है कि WP का उपयोग करने वाली कोई भी वेबसाइट IE पर काम करना बंद कर देगी। भले ही WP एक परियोजना के रूप में IE (जो भविष्य में किसी बिंदु पर होने की संभावना है) का समर्थन बंद करने का निर्णय लेता है, यदि उपयोगकर्ता अब इसके साथ IE- संगत वेबसाइट नहीं बना सकते हैं जो किसी भी सरकार या अन्य आधिकारिक संस्थान के लिए एक बड़ी समस्या हो सकती है जो इसका उपयोग करता है डब्ल्यूपी.

इतना अच्छा और इस सुविधा के लिए इंतजार नहीं कर सकता!

क्या सामने के छोर पर CSS चरों का उपयोग करने का कोई अच्छा विकल्प होगा? यहां चिंता यह है कि WP का उपयोग करने वाली कोई भी वेबसाइट IE पर काम करना बंद कर देगी। भले ही WP एक परियोजना के रूप में IE (जो भविष्य में किसी बिंदु पर होने की संभावना है) का समर्थन बंद करने का निर्णय लेता है, यदि उपयोगकर्ता अब इसके साथ IE- संगत वेबसाइट नहीं बना सकते हैं जो किसी भी सरकार या अन्य आधिकारिक संस्थान के लिए एक बड़ी समस्या हो सकती है जो इसका उपयोग करता है डब्ल्यूपी.

यह एक महत्वपूर्ण बिंदु और दुर्भाग्यपूर्ण वास्तविकता है। यह अच्छा होगा यदि हम कुछ कठिन डेटा प्राप्त कर सकें, हालांकि इसका कितना प्रभाव होगा।

इसके साथ ही, मुझे आश्चर्य है कि https://www.npmjs.com/package/postcss-css-variables कुछ ऐसा होगा जो अंतिम सीएसएस के साथ सहायता के लिए निर्माण प्रक्रिया में उपयोग किया जा सकता है। हो सकता है कि WP के लिए एक प्लगइन हो सकता है जो सीएसएस आउटपुट की फ्लाई प्रोसेसिंग पर ट्रांसपाइल (उस पैकेज का उपयोग करके) आईई अनुकूल आउटपुट में करेगा जो कि उन साइटों द्वारा उपयोग किया जा सकता है जिन्हें इसकी आवश्यकता है?

@tellthemachines + @nerrad आपकी प्रतिक्रिया के लिए धन्यवाद! मैं सहमत हूं, सीएसएस चर के साथ चिंता और (पुराने) ब्राउज़र समर्थन की कमी बहुत वास्तविक है।

हो सकता है कि WP के लिए एक प्लगइन हो सकता है जो सीएसएस आउटपुट की फ्लाई प्रोसेसिंग पर ट्रांसपाइल (उस पैकेज का उपयोग करके) आईई अनुकूल आउटपुट में करेगा जो कि उन साइटों द्वारा उपयोग किया जा सकता है जिन्हें इसकी आवश्यकता है?

यह दिलचस्प होगा! जेएस-आधारित पॉलीफ़िल फिल क्लाइंट साइड की आवश्यकता को कम करने के लिए कुछ सर्वर-साइड।

मैं वास्तव में उम्मीद कर रहा हूं कि हम इस परियोजना के लिए स्टाइलिंग तंत्र के लिए सीएसएस वेरिएबल्स का उपयोग कर सकते हैं। या तो एक तकनीक का उपयोग करना जैसे @nerrad ने सुझाव दिया, और टट्टू/

इसके साथ ही, मुझे नहीं लगता कि सीएसएस उस टुकड़े को बदलता है जो वैश्विक शैलियों को बनाता/तोड़ता है ।

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

उस उपयोगकर्ता अनुभव पर ध्यान केंद्रित करना, मुझे लगता है, अंततः गुटेनबर्ग अनुभव का एक बड़ा हिस्सा है :)। मुझे याद आ रहा है कि एक टिप्पणी @nerrad ने लिखा (नीचे लिंक), जहां उन्होंने वाक्पटुता से वर्डप्रेस के भीतर उपयोगकर्ता अनुभव के महत्व पर जोर दिया।

https://github.com/WordPress/gutenberg/pull/16384#issuecomment -573430079

सभी को नमस्कार!

मेरे पास एक अपडेट है। मैं @karmatosed के साथ काम कर रहा

मैंने एक प्रोटोटाइप बनाया है जो प्रवाह + पदानुक्रम को प्रदर्शित करता है कि वैश्विक शैलियाँ ब्लॉक और थीम के साथ कैसे काम करेंगी

मैंने एक स्क्रीनकास्ट रिकॉर्ड किया जो प्रोटोटाइप + अवधारणाओं पर जाता है:

:वीडियो_कैमरा: वीडियो
https://www.loom.com/share/73f721797f524dfeb2c3a222e9e24561

: उठाया_हाथ: डेमो
https://yvz8y.csb.app/#/v2/post

बहुत लंबा, नहीं देखा

कोई चिंता नहीं! मैं संक्षेप में बताने की कोशिश करूँगा <3

इस पिरामिड द्वारा शैली पदानुक्रम का प्रतिनिधित्व किया जा सकता है:

कोर : बेस स्टाइल जो गुटेनबर्ग/ग्लोबल स्टाइलिंग सिस्टम के साथ आते हैं
थीम :
वैश्विक : उपयोगकर्ता द्वारा लागू की गई कस्टम शैलियाँ, पूरी साइट के लिए अभिप्रेत हैं
दस्तावेज़ : उपयोगकर्ता द्वारा लागू की गई कस्टम शैलियाँ, कुछ पृष्ठों/टेम्पलेट भागों (FSE) के लिए अभिप्रेत हैं
ब्लॉक : व्यक्तिगत ब्लॉक के लिए उपयोगकर्ता द्वारा लागू कस्टम शैलियाँ

उपरोक्त पिरामिड में, हम देख सकते हैं कि कोर शैलियाँ (ब्लैक टेक्स्ट) अपने तरीके से ऊपर बनी हुई हैं, क्योंकि किसी अन्य परत पर किसी भी शैली को परिभाषित नहीं किया गया था। जिसके परिणामस्वरूप ऐसा कुछ दिखता है:

अगर हम थीम को ब्लू में बदलते हैं , तो ब्लू थीम की कस्टम शैलियाँ (इस मामले में, नीला टेक्स्ट), कोर की शैलियों को ओवरराइड कर देंगी। यह ऊपर की ओर बना रहेगा क्योंकि कोई अन्य कस्टम शैली लागू नहीं होती है

इस तरह दिखने वाली साइट के परिणामस्वरूप:

यदि हम एक वैश्विक शैली लागू करते हैं, तो यह विषय की ओवरराइड कर देगी:

यदि हम कोई दस्तावेज़ शैली लागू करते हैं, तो यह वैश्विक (यदि लागू हो) को ओवरराइड कर देगी:

अंत में, यदि हम किसी विशिष्ट ब्लॉक को कस्टमाइज़ करते हैं, तो यह अन्य परतों को ओवरराइड कर देगा:

जिसके परिणामस्वरूप:

हमारे पास कस्टम सेटिंग्स को "रीसेट" करने या हटाने की क्षमता भी होगी। इस उदाहरण में, मान लें कि उपयोगकर्ता अपनी वैश्विक शैली सेटिंग हटा देता है। हालाँकि, दस्तावेज़ शैली बनी हुई है, जो इस प्रकार प्रस्तुत करती है:

थीम स्विचिंग

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

मान लें कि उपयोगकर्ता ने अपनी मौजूदा थीम ("नीला") को एक गुच्छा अनुकूलित किया है।
मान लें कि उपयोगकर्ता एक नई थीम ("लाल") स्थापित करता है। एक थीम जिसे उन्होंने अभी डाउनलोड किया है।

उनके स्विच करने के बाद, वैश्विक + दस्तावेज़ शैलियाँ रीसेट हो जाएँगी।

इसका कारण यह है कि उन्होंने अभी तक "लाल" विषय पर कुछ भी अनुकूलित नहीं किया है।

"नीला" पर वापस जाने से, उनकी पिछली वैश्विक/दस्तावेज़ शैलियों को पुनर्स्थापित किया जाएगा।

TLDR (बहुत लंबा, पढ़ा नहीं गया)

• एक शैली पदानुक्रम है - कोर, थीम, वैश्विक, दस्तावेज़, ब्लॉक
• वैश्विक, दस्तावेज़, ब्लॉक शैलियों को उपयोगकर्ता द्वारा अनुकूलित किया जाता है
• ग्लोबल + दस्तावेज़ शैलियाँ एक थीम से जुड़ी होती हैं
• यह कम से कम साइड इफेक्ट के साथ थीम स्विचिंग की अनुमति देता है

आपके समय के लिए बहुत बहुत शुक्रिया! विचार + प्रतिक्रिया का स्वागत है

बहुत बढ़िया ब्रेकडाउन, धन्यवाद @ItsJonQ!
हालांकि थीम और ग्लोबल काफी समान नहीं है?
मेरा मतलब है कि विषयों का भविष्य कैसा दिख सकता है, इस बारे में सोचते हुए, अधिकांश थीम शायद कस्टमाइज़र का उपयोग करने से वैश्विक-शैली प्रणाली में स्विच हो जाएंगी। सेटिंग्स जो अब कस्टमाइज़र में मौजूद हैं उन्हें इस सिस्टम में माइग्रेट कर दिया जाएगा... उन्हें एक ही चीज़ के रूप में माना जा सकता है। हम उन्हें "थीम" कह सकते हैं यदि थीम कस्टमाइज़र का उपयोग करती है और "वैश्विक" यदि थीम ग्लोबल-स्टाइल सिस्टम का उपयोग कर रही है, लेकिन यह एक या दूसरे है, तो किसी भी थीम की कस्टमाइज़र और ग्लोबल दोनों में समान सेटिंग्स नहीं होंगी- स्टाइल्स एडिटर क्योंकि ऐसा करने का कोई कारण नहीं है, दोनों के होने का कोई फायदा नहीं है।

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

क्या सामने के छोर पर CSS चरों का उपयोग करने का कोई अच्छा विकल्प होगा? यहां चिंता यह है कि WP का उपयोग करने वाली कोई भी वेबसाइट IE पर काम करना बंद कर देगी।

यह फ़ॉलबैक बनाकर हल करने योग्य है जैसे:

p {
    font-size: 16px; // Fallback for IE.
    font-size: var( --font-size-paragraph );
}

इसे https://www.npmjs.com/package/postcss-custom-properties का उपयोग करके स्वचालित किया जा सकता है एक अन्य दृष्टिकोण एक SASS मिश्रण होगा, हालांकि CSS मैला हो जाता है (आपको <strong i="11">@include</strong> font-size-mixin( 16px ); लिखना होगा जो कि थोड़ा सा है अप्राकृतिक। पुराने वेब नागरिकों पर काबू पाने के विकल्प हैं, इसलिए CSS कस्टम गुण उपयोग करने के लिए ठीक हैं।

मैंने अभी-अभी सभी #9534 और इस मुद्दे को पढ़ा है और मैं एक ऐसे परिप्रेक्ष्य को सामने लाना चाहता हूँ जिसका अभी तक उल्लेख नहीं किया गया है जहाँ तक मैंने पढ़ा है।

उपयोगकर्ता स्टाइलिंग बनाम बिल्डर्स स्टाइलिंग

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

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

उस स्थिति में ऊपर वर्णित "शैली पदानुक्रम" वह नहीं है जो किसी को चाहिए या चाहिए क्योंकि स्टाइल को केवल विषय द्वारा परिभाषित किया जाना चाहिए। वैश्विक, दस्तावेज़ और ब्लॉक स्तर पर कुछ भी बदलना संभव नहीं होना चाहिए। और यहां तक ​​​​कि कोर स्टाइलिंग को भी बहुत अधिक माना जा सकता है। इसके बजाय थीम स्तर यह तय करने वाला पहला, आखिरी और केवल एक होना चाहिए कि सब कुछ कैसे स्टाइल किया जाए ।

क्या हमें केवल उपयोगकर्ताओं के नियंत्रण में रहने को स्वीकार नहीं करना चाहिए?

आम तौर पर हाँ, लेकिन शायद यहाँ नहीं। आइए देखें क्यों।

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

(इससे भी अधिक मैं व्यक्तिगत रूप से सोचता हूं कि स्टाइल से संबंधित कुछ विकल्पों को हटाने से वास्तव में उपयोगकर्ताओं को स्टाइल के बारे में सोचने की आवश्यकता से मुक्त करके सामग्री संपादक बनने में मदद मिलती है। यह वास्तव में उन्हें अधिक नियंत्रण में महसूस कराता है, भले ही वे तकनीकी रूप से न हों। _ "निर्णय, विकल्प नहीं"_)

कोर शैलियों को हमेशा राय दी जाती है।

मैं समझता हूं कि कुछ आधार रेखा होनी चाहिए, लेकिन यहां तक ​​​​कि अगर इसे हटाया भी नहीं जाता है तो अक्सर इसे बदलने की जरूरत होती है। सरल उदाहरण: वर्तमान में कॉलम और गैलरी ब्लॉक लेआउट के लिए सीएसएस फ्लेक्सबॉक्स का उपयोग करते हैं, जिससे कोई भी कोर ब्लॉक सीएसएस पूरी तरह से अप्रचलित हो जाता है यदि सीएसएस ग्रिड पर आधारित आपकी पूरी साइट लेआउट होने पर भी बाधा नहीं आती है।

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

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

अंतिम विचार

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

उस सेटिंग में उपयोगकर्ताओं को विशेष रूप से साइट की स्टाइलिंग पर कोई या कम से कम बहुत कम नियंत्रण नहीं होना चाहिए।

@kraftner यह वास्तव में हाजिर है और मैं केवल यह वर्तमान में प्लगइन्स की कोई

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

आगे बढ़ने से पहले निपटने के लिए यह कुछ महत्वपूर्ण है।

आपके विस्तृत विचारों के लिए धन्यवाद, @kraftner , ये अच्छे बिंदु हैं।

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

मुझे नहीं लगता कि यहां ऐसा जरूरी है। सिस्टम एक ब्लॉक की शैली क्षमताओं को इस तरह से संरचित करने का एक तरीका प्रस्तावित करता है जिसे बेहतर नियंत्रित किया जा सकता है, लेकिन यह इस बारे में बहुत कुछ नहीं कहता है कि यह नियंत्रण कौन करेगा। यह पूरी तरह से संभव है कि इसमें से अधिकांश केवल थीम बिल्डर टूल के रूप में, व्यवस्थापकों और डिजाइनरों के लिए, उपयोगकर्ताओं को समाप्त करने के लिए जरूरी नहीं है।

इसे "थीम संपादक" के विकास के रूप में अधिक सोचें, न कि उपयोगकर्ताओं को सभी शैली विवरणों पर नियंत्रण देने के लिए। उत्तरार्द्ध भी अधिकांश उपयोगकर्ताओं के लिए बहुत अच्छा नहीं होगा, क्योंकि यह काफी भारी होगा, लेकिन थीम को ब्लॉक पर बेहतर और आसान नियंत्रण की आवश्यकता होती है (विशेषकर ब्लॉक जिन्हें वे नहीं जानते हैं, यहां तक ​​​​कि मौजूद भी हैं!)

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

यह पूरी तरह से उचित है, और यह कहे बिना जाना चाहिए कि एक साइट का इस बात पर नियंत्रण होगा कि क्या ये उपकरण उजागर हैं, कौन सी भूमिकाएँ, और कौन सी क्षमता - उसी तरह आपके नियमित उपयोगकर्ताओं के पास PHP थीम संपादक तक पहुँच नहीं है।

और यहां तक ​​​​कि कोर स्टाइलिंग को भी बहुत अधिक माना जा सकता है। इसके बजाय थीम स्तर यह तय करने वाला पहला, आखिरी और केवल एक होना चाहिए कि सब कुछ कैसे स्टाइल किया जाए।

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

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

निश्चित रूप से। फिर से, मैं इस नींव को ब्लॉक पर विषय पर अधिक जानबूझकर नियंत्रण देने के रूप में देखता हूं। एक साइड इफेक्ट यह है कि हम एक ऐसी प्रणाली के साथ समाप्त हो जाते हैं जो उपयोगकर्ताओं के सामने भी आ सकती है यदि वे सीएसएस लिखने और हाथ से PHP टेम्पलेट्स को संशोधित करने के बजाय जीयूआई का उपयोग करके उस स्तर का नियंत्रण रखना चाहते हैं, लेकिन यह एक नहीं होने वाला है -साइज-फिट-ऑल-यूज-केस, क्योंकि वर्डप्रेस की दुनिया अविश्वसनीय रूप से विविध है और हमें ऐसे टूल की आवश्यकता है जो विविध उपयोग के मामलों को समायोजित करें।

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

मुझे लगता है कि आप जो रूपरेखा तैयार कर रहे हैं वह पूरी तरह से वैध उपयोग का मामला है जिसे समायोजित करना और सुधारना आसान होना चाहिए।

यह बहुत अच्छा लगता है @mtias। मैं बस इस पर फिर से जोर देना चाहता था, विशेष रूप से इस बिंदु पर कि मुझे लगता है कि यह प्रत्येक और इनमें से किसी भी उपयोगकर्ता-नियंत्रणीय सुविधाओं के लिए केवल प्लगइन या कम से कम कोर में जाने के लिए एक अवरुद्ध आवश्यकता होनी चाहिए जब यह नियंत्रण के विकल्प के साथ आता है (कॉन्फ़िगर करें, प्रतिबंधित करें, अक्षम करें)।

मूल रूप से मेरे यहां आने का कारण यह है कि आपने जून में WCEU में कार्यालय समय में बहुत कुछ यही कहा था जब आप, मैं और @m इस विशेष विषय के बारे में बात कर रहे थे। लेकिन मुझे पहले से ही यह आभास हो गया था कि इसे बाद के लिए "अच्छी-से-अच्छी" चीज़ के रूप में देखा गया था, न कि एक कठिन आवश्यकता या प्राथमिकता के रूप में।

नियंत्रण के नुकसान के उदाहरणों के बारे में मैं बात कर रहा हूं - उनमें से ज्यादातर के पास पहले से ही मुद्दे हैं, लेकिन दुर्भाग्य से उनमें से बहुतों के लिए कोई आंदोलन नहीं है। अक्सर मुझे यह भी समझ में नहीं आता कि कैसे संबंधित बग भी हो सकते हैं, इसे बंद करना स्पष्ट रूप से विकास के दौरान नई सुविधाओं के लिए भी कोशिश नहीं की जाती है।
तो अंत में यह एक बहुत ही निराशाजनक "व्हेक-ए-मोल" स्थिति की तरह लगता है जहां प्रत्येक सुविधा के लिए कोई नियंत्रण प्राप्त कर सकता है, दो और जो नियंत्रित नहीं हैं संपादक में प्रवेश कर रहे हैं। मैं जिस बारे में बात कर रहा हूं, उस पर जोर देने के लिए, यहां उन मुद्दों की एक सूची है जो मैं वर्तमान में हूं या पहले संघर्ष कर रहा था, उन्हें नियंत्रित करने के कोई या केवल हैक करने के तरीके नहीं थे। (यह इस विषय पर मेरी आगामी WC वार्ता के लिए

• ड्रॉप कैप: #6184 / #14654 -> #6023 (यह WP 5.0 से बहुत पहले समस्याग्रस्त होने के बारे में जाना जाता था/रिपोर्ट किया गया था, यह सुविधा कभी भी क्यों चली गई?)
• तालिकाओं के लिए पृष्ठभूमि रंग #16478 / #19659 (वह "व्यापार-बंद" ठीक क्यों था और अवरुद्ध समस्या नहीं थी?)
• फ़ॉन्ट आकार #13824 / 46290 (यह कैसे फिसल सकता है? सामान को अक्षम करना किसी भी विकल्प को जोड़ने के बाद कोशिश करने वाली पहली चीजों में से एक है, नहीं?)
• ग्रेडियंट्स: #18213 (यह सुविधा एक सामान्य समाधान के अक्षम होने की प्रतीक्षा क्यों नहीं करती है, इसके बजाय एक प्रयोगात्मक ध्वज, कोई दस्तावेज नहीं जोड़ना, कुछ अक्षम करने के लिए सिर्फ एक और नया तंत्र पेश करना?)
• कॉलमों की संख्या #10791 -> #18892 (मैं एक सामान्य समाधान की आवश्यकता को समझता हूं, लेकिन तब तक नई सुविधाओं को होल्ड पर क्यों नहीं रखा गया है?)
• टेम्प्लेट लॉकिंग #8112 / #7845 (पुराने कस्टम फ़ील्ड प्लगइन्स दृष्टिकोण को बदलने के लिए CPT संरचना को लॉक करने में सक्षम होने के लिए ये तत्काल आवश्यकताएं हैं)

मुझे पता है कि इस सूची के अंत में मैं स्टाइल के मुद्दों से कुछ हद तक पीछे हट रहा हूं, लेकिन मेरा मानना ​​​​है कि यह सब एक साथ व्यापक विषय को दर्शाता है: गुटेनबर्ग पर नियंत्रण करना अभी भी कहीं न कहीं कठिन और असंभव के बीच है।

मुझे गलत मत समझो: मैं समझता हूं कि गुटेनबर्ग अभी भी भारी विकास के अधीन है और इन सभी मुद्दों को अलग-अलग देखकर निश्चित रूप से कहा जा सकता है कि बग होते हैं, कुछ भी कभी भी सही नहीं होता है और हम केवल एक के बाद एक काम कर सकते हैं। लेकिन उपरोक्त सभी का योग मुझे ऐसा महसूस कराता है कि इसे परियोजना नेतृत्व द्वारा प्राथमिकता के रूप में नहीं देखा जाता है और पहले सामग्री संपादन के साथ इस महत्वपूर्ण मुद्दों को हल करने के बजाय, हम पहले से ही अगले, और भी अधिक जटिल क्षेत्र में आगे बढ़ रहे हैं। पूर्ण साइट संपादन का।

टीएल; डीआर: पूरे गुटेनबर्ग में उपयोगकर्ताओं की क्षमताओं पर नियंत्रण एक महत्वपूर्ण और तत्काल आवश्यकता है, और मुझे वास्तव में लगता है कि इस पर कुछ और ध्यान केंद्रित करने का समय आ गया है। कृपया, कोई और सुविधाएँ लागू करने से पहले कृपया हमें वापस नियंत्रण दें। :प्रार्थना:

मैं मातम में बहुत अधिक खुदाई नहीं करना चाहता, लेकिन एक बात मेरे लिए इस मुद्दे के विवरण के उदाहरणों में से एक में कूद गई:

वैश्विक शैलियों का उपयोग शुरू करने के लिए ब्लॉक के लिए, सिस्टम द्वारा आउटपुट किए गए सीएसएस चर का उपयोग करने के लिए उनके सीएसएस को फिर से सक्रिय करने की आवश्यकता होगी।

और फिर यह उदाहरण का हिस्सा है:

border: 1px solid var(--wp-gs-color-primary-dark20);

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

इसके बजाय, इसे शायद इस प्रकार परिभाषित किया गया है:

border: 1px solid var(--wp-button-block-border-color);

और फिर एक रिश्ते को परिभाषित किया जाता है (विषय के अनुसार?):

--wp-button-block-border-color: --wp-gs-color-primary-dark20

सुनिश्चित नहीं है कि मैंने इसे स्पष्ट रूप से समझाया है। यह पहले से ही काफी जटिल लग रहा है, लेकिन यह कुछ ऐसा है जिसकी मुझे आशा है कि इसे हल करने की आवश्यकता हो सकती है।

संपादित करें: आगे हालांकि यह सुनिश्चित नहीं है कि मैंने जो प्रस्तावित किया है वह तीसरे पक्ष के ब्लॉक के साथ कैसे काम करेगा। शायद मुद्दा यह है कि शब्दार्थ को अधिक स्पष्ट रूप से परिभाषित करने की आवश्यकता है, इसलिए हम कुछ 'अंधेरे' या 'प्रकाश' नाम देने से बचते हैं।

जैसा कि मैं दृश्य हूं, मुझे आश्चर्य हुआ कि क्या इससे किसी को यह देखने में मदद मिल सकती है कि हर बार कुछ पुनरावृत्त होने पर क्या प्रभाव पड़ता है। उदाहरण के लिए, परतें कैसे फ़िल्टर होती हैं। यह पिरामिड कैस्केड @ItsJonQ पर बनाया गया है और सहयोग से किया गया है।

यह क्या करता है विशिष्ट कार्यों को देखें:

• विश्व स्तर पर शैली बदलना: उदाहरण के लिए, आधारभूत फ़ॉन्ट आकार बढ़ाना। इस मामले में यह सब कुछ वैश्विक के रूप में चला जाता है। डॉट्स दिखाते हैं कि यह सबसे ऊपर है (पदानुक्रम का सम्मान करते हुए) और इसलिए क्या प्रभावित होता है।
• स्थानीय/दस्तावेज़ शैली बदल रहा है: उदाहरण के लिए बेसलाइन फ़ॉन्ट आकार केवल पृष्ठ पर बढ़ता है।
• ब्लॉक शैली में परिवर्तन: उदाहरण के लिए केवल एक कोट ब्लॉक पर बेसलाइन फ़ॉन्ट आकार बदलना।

यदि आप देखते हैं कि 2 कॉलम हैं, जिनमें कोई इंटरैक्शन नहीं है, तो आपके द्वारा कोई भी इंटरैक्शन करने से पहले ये पूरे समय तक बने रहते हैं।

नोट करने के लिए एक और बिंदु में कुछ चीजें शामिल हैं:

• शैली विविधताएं
• कस्टम स्टाइल
• डेवलपर (प्लगइन) ब्लॉक शैलियाँ

इस छवि में, विषय मूल डिफ़ॉल्ट के बगल में परत है, जो कुछ भी वैश्विक स्तर पर ऊपर बदलता है वह शीर्ष पर ब्लॉक तक जाता है।

वैश्विक शैलियाँ - पहला पुनरावृत्ति

आज सुबह (टोरंटो समय), मैं इस नए ग्लोबल स्टाइल फोकस पर सिंक करने के लिए @nosolosw और @jorgefilipecosta के साथ एक कॉल पर

हम में से प्रत्येक ने एक समय में इस समस्या पर स्वतंत्र रूप से काम किया है। यह देखते हुए कि वैश्विक शैलियों के कई पहलू एकदम नए हैं (गुटेनबर्ग के संदर्भ में), और सभी विभिन्न चलती भागों में शामिल जटिलताएं, हमें लगा कि अपने अनुभवों, विचारों, प्रयोगों को साझा करने के लिए सिंक करना अच्छा होगा। और योजना शुरू करने के लिए।

3 भाग

विभिन्न कार्यान्वयन विवरणों और विभिन्न किनारे के मामलों पर चर्चा करने के बाद, हमने मूल प्रस्तावित अवधारणा को 3 मुख्य भागों में सरल बनाया:

• समाधानकर्ता (हमने बैठक के दौरान इसे "मर्ज" कहा)
• ब्लाकों
• नियंत्रण

"ट्रांसफॉर्मर्स", "हुक" और "रेंडरर" टुकड़ों को छोड़कर, ये 3 भाग अभी भी मूल डिजाइन की भावना को मूर्त रूप देते हैं, जिन्हें "रिज़ॉल्वर" और "ब्लॉक्स" में सरल और समेकित किया गया था।

रिज़ॉल्वर

रिज़ॉल्वर डेटाबेस से theme.json फ़ाइल और पहले से सहेजे गए वैश्विक स्टाइल डेटा की जाँच के लिए ज़िम्मेदार है। इसके बाद यह डेटासेट को एक साथ मर्ज कर देगा और गुटेनबर्ग के उपभोग के लिए कुछ तैयार करेगा।

ब्लाकों

ब्लॉक गुटेनबर्ग ब्लॉक हैं जिन्हें हम सभी जानते हैं और प्यार करते हैं! CSS वैरिएबल का उपयोग शुरू करने के लिए ब्लॉक के .css अपडेट करने की आवश्यकता होगी जो ग्लोबल स्टाइलिंग सिस्टम के लिए महत्वपूर्ण होंगे।

नियंत्रण

नियंत्रण उपयोगकर्ता-इंटरफ़ेस हैं जो उपयोगकर्ता को वैश्विक शैली मूल्यों को समायोजित करने में सक्षम बनाते हैं। इन्हें पूर्ण साइट संपादन अनुभवों में प्रस्तुत किया जाएगा।

नोट: व्यक्तिगत ब्लॉक इंस्टेंस के लिए नियंत्रण भी मौजूद हैं। वे विभिन्न नियंत्रण क्षेत्र हैं जो एक ब्लॉक के InspectorControls । अद्यतन केवल शैली मानों को लागू करने के तरीके को समायोजित करेगा, अर्थात हार्ड कोडित मानों के बजाय इनलाइन शैली CSS चर जोड़ना। (उस पर और बाद में)

प्रवाह ("बैकएंड")

निम्नलिखित ग्लोबल स्टाइल सिस्टम के बैकएंड प्रवाह का विवरण देगा।

रिज़ॉल्वर

जब रिज़ॉल्वर शुरू होता है, तो यह पहले स्थानीय रूप से theme.json फ़ाइल के लिए देखता है।

1. theme.json

इस प्रस्ताव के लिए, theme.json फ़ाइल एक थीम के लिए एक आसान तरीका है:

ए। वैश्विक शैलियों में ऑप्ट-इन करें
बी। थीम विशिष्ट शैली मान घोषित करें

theme.json का एक उदाहरण इस तरह दिख सकता है:

{
    "name": "Awesome Theme",
    "global": {
        "color": {
            "background": "black",
            "text": "red"
        }
    },
    "blocks": {
        "core/paragraph": {
            "color": {
                "text": "hotpink"
            }
        }
    }
}

इस उदाहरण में, थीम वैश्विक डिफ़ॉल्ट color.background और color.text को ओवरराइड कर रही है। यह विशेष रूप से कोर पैराग्राफ ब्लॉक के color.text भी समायोजित कर रहा है।

2. डेटाबेस की जाँच करना

यदि theme.json है, तो रिज़ॉल्वर पहले से सहेजी गई वैश्विक शैलियों के लिए डेटाबेस की जाँच करेगा।

थीम विशिष्ट वैश्विक शैलियाँ

वैश्विक शैलियों को इस तरह से सहेजा जाना चाहिए जो किसी विषय के लिए विशिष्ट हो। यह शैली सौंदर्य संघर्षों के बिना विषयों को सुरक्षित रूप से स्विच करने की क्षमता को सक्षम बनाता है।

यह इस डेमो में प्रदर्शित किया जा सकता है

(कुछ वैश्विक/दस्तावेज़ शैलियों को लागू करने और विषयों को बदलने का प्रयास करें)।

3. विलय

theme.json डेटा और डेटाबेस डेटा को मर्ज कर दिया जाता है और गुटेनबर्ग द्वारा उपभोग के लिए तैयार किया जाता है।

खंड

1. प्रदान किया गया

गुटेनबर्ग संपादक द्वारा ब्लॉक लोड और प्रस्तुत किए जाते हैं। ब्लॉक वैश्विक स्टाइल सम्मेलनों के अनुरूप सीएसएस चर की एक श्रृंखला का उपयोग करते हैं।

सीएसएस चर

ग्लोबल स्टाइल्स का उपयोग करते हुए कोर पैराग्राफ ब्लॉक का एक उदाहरण निम्नलिखित है:

p {
    color: currentColor;
}

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, var(--wp-gs-color-text));
}

.wp-gs गुंजाइश

हमारे प्रारंभिक कार्यान्वयन के लिए, विचार एक विशिष्ट CSS चयनकर्ता ( .wp-gs ) को या तो html या body DOM नोड पर प्रभावी ढंग से "वैश्विक शैली समर्थित वातावरण" स्थापित करने के लिए लागू करना है। .

यह विश्व स्तर पर स्टाइल वाले ब्लॉक के लिए CSS विशिष्टता को बढ़ाता है।

उपरोक्त उदाहरण में, वैश्विक शैलियों के बिना <p> प्रतिपादन (जैसे वे आज कैसे करते हैं) एक मूल चयनकर्ता से इसका रंग प्राप्त करेगा।

हालांकि, "वैश्विक शैली समर्थित वातावरण" के भीतर, .wp-gs p नियम लागू होगा।

var(...)

हम जिस सम्मेलन के साथ जा रहे हैं वह वैश्विक शैली सीएसएस चर को --wp-gs (वर्डप्रेस ग्लोबल स्टाइल) के साथ उपसर्ग करना है। ऊपर के उदाहरण में:

.wp-gs p {
    color: var(--wp-gs-paragraph-color-text, --wp-gs-color-text);
}

var() लिए सेटअप है:

1. कस्टम ब्लॉक विशिष्ट शैली प्रतिपादन को संभालें
2. सामान्य मूल्यों पर वापस आना

फॉलबैक के साथ ब्लॉक विशिष्ट शैलियों का उपयोग करने की परंपरा सिस्टम को बेहतर अनाज नियंत्रण और स्थिरता दोनों देती है।

2. ब्लॉक x नियंत्रण

यदि किसी ब्लॉक इंस्टेंस में कस्टम सौंदर्य परिवर्तन होते हैं, उदाहरण के लिए टेक्स्ट कलर अपडेट, तो अपडेट की गई विशेषता (ओं) को इनलाइन शैलियों के रूप में प्रस्तुत किया जाएगा। वर्तमान कार्यान्वयन और प्रस्तावित कार्यान्वयन के बीच का अंतर, हार्ड कोडित मूल्यों पर CSS चर का उपयोग है।

वर्तमान:

<p style="color: red;">...</p>

प्रस्तावित:

<p style="--wp-gs-paragraph-color-text: red;">...</p>

कई मायनों में, प्रभाव समान हैं। हालांकि, CSS वेरिएबल्स का उपयोग करने से अधिकांश CSS कैस्केडिंग प्रभाव लागू हो सकते हैं।

नियंत्रण

पूर्ण साइट संपादन से साइट संपादन प्रवाह के भीतर नियंत्रण मौजूद होंगे।

1. अद्यतन

जब कोई अद्यतन किया जाता है, तो अद्यतन विशेषता रिज़ॉल्वर को भेजी जाती है।

रिज़ॉल्वर यह काम करता है (शायद @wordpress/data स्टोर के साथ समन्वय करता है), और अद्यतन उपभोज्य डेटा को वापस गुटेनबर्ग में धकेलता है।

अंत में, उस अद्यतन डेटा (साथ ही अद्यतन सीएसएस चर) को हाइड्रेट किया जाता है और FSE उपयोगकर्ता इंटरफ़ेस, और किसी भी दृश्यमान ब्लॉक को प्रदान किया जाता है।

प्रवाह ("फ्रंटेंड")

जिस समाधान के साथ हम आए हैं (वर्तमान में) उसके लिए किसी दिए गए पृष्ठ के लिए शैली मूल्यों के नवीनतम संयोजन प्राप्त करने और बनाने के लिए रिज़ॉल्वर को theme.json और डेटाबेस को जांचने/पढ़ने की आवश्यकता है।

यह पेज लोड पर सर्वर साइड होता है।

इसके बाद रिज़ॉल्वर लोड होने वाले पृष्ठ के <head> में इंजेक्ट करने के लिए एक <style> टैग बनाएगा। उदाहरण:

<head>
    ...
    <style>
        :root {
            --wp-gs-color-text: black;
            --wp-gs-color-background: white;
            --wp-gs-color-primary: blue;
            ...
            --wp-gs-paragraph-color-text: hotpink;
        }
    </style>
</head>

अंत में, ब्लॉक से वैश्विक शैलियों को सक्रिय करने के लिए .wp-gs CSS चयनकर्ता को इंजेक्ट करने की आवश्यकता है।

- <html>
+ <html class="wp-gs">

और बस!

पहली पहल

@nosolosw , @jorgefilipecosta , और मैं ऊपर उल्लिखित 3 भागों को बनाने के लिए एक साथ काम करूंगा:

• रिज़ॉल्वर - @jorgefilipecosta
• ब्लॉक - @nosolosw
• यूआई नियंत्रण - @itsjonq

पहली पहल जिसके लिए हम निर्माण करने जा रहे हैं, उपयोगकर्ताओं को निम्न की अनुमति देती है:

1. डिफ़ॉल्ट टेक्स्ट रंग के लिए वैश्विक शैलियाँ सेट करें
2. वैश्विक शैलियों का उपयोग करने के लिए मुख्य अनुच्छेद + शीर्षक ब्लॉक सक्षम करें
3. थीम को डिफ़ॉल्ट टेक्स्ट रंग, शीर्षक और पैराग्राफ़ ब्लॉक टेक्स्ट रंगों को अनुकूलित करने की अनुमति दें

गोचास

इस समय सबसे बड़ा गोचा यह है कि हम अनिश्चित हैं कि IE का ठीक से समर्थन कैसे किया जाए। हमारा वर्तमान सिस्टम बहुत हद तक CSS वेरिएबल और ब्राउज़र की मूल विशेषता पर निर्भर करता है जो IE11 में समर्थित नहीं है ।

पॉलीफ़िल उपलब्ध हैं, लेकिन रेंडरिंग समेकन करने के लिए पर्याप्त नहीं हैं जिनकी हमें आवश्यकता है (कम से कम, बॉक्स से बाहर नहीं)।

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

प्रतिक्रिया + धन्यवाद!

सबसे पहले, अगर आपने इसे पढ़ने के लिए बनाया है (चाहे आपने इसे स्किम किया है या नहीं), बहुत-बहुत धन्यवाद ! मुझे पता है कि यह पढ़ने के लिए बहुत भयानक था। :दिल:

मेरा इरादा किसी भी डिजाइन, प्रयोग और कार्यान्वयन के संबंध में यथासंभव पारदर्शी होना है।

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

हमेशा की तरह, विचारों और प्रतिक्रिया का स्वागत है !!

एक बार फिर धन्यवाद :)

इस समय सबसे बड़ा गोचा यह है कि हम अनिश्चित हैं कि IE का ठीक से समर्थन कैसे किया जाए। हमारा वर्तमान सिस्टम बहुत हद तक CSS वेरिएबल्स और ब्राउज़र की मूल विशेषता पर निर्भर करता है जो IE11 में समर्थित नहीं है।

IE11 के आसपास के आँकड़ों को सतह पर लाने के लिए अगर यह लोगों को झंकार करने में मदद करता है:

• जनवरी 2020 तक IE11 का उपयोग 1.43% ( CanIUse के माध्यम से)
• IE11 स्क्रीन रीडर का उपयोग अगस्त-सितंबर 2019 तक 10.9% ( WebAim के माध्यम से। 2017 में यह 23.3%) था।

IE11 समर्थन को "पूर्ण दृश्य" स्तर के बजाय "कार्यात्मक" पर छोड़ना एक सामान्य उद्योग मानक है।

यह यहां भी पर्याप्त हो सकता है, विशेष रूप से स्क्रीन रीडर उपयोग के मामले को देखते हुए कि बाकी थीम और ब्लॉक स्टाइल एक फॉलबैक के रूप में काम करते हैं?

मुझे नहीं पता कि ie11CustomProperties पॉलीफ़िल कितना ठोस है, लेकिन डेवलपर ज़रूरत पड़ने पर इसे हमेशा मैन्युअल रूप से शामिल कर सकते हैं। आप इसे किसी प्रकार के ऑप्ट-इन टॉगल के माध्यम से कोर से भी प्रदान कर सकते हैं?

जनवरी 2020 तक IE11 का उपयोग 1.43% (CanIUse के माध्यम से)

जनवरी 2019 से जनवरी 2020 तक सभी डेस्कटॉप विज़िट में IE11 का उपयोग था:

• दुनिया भर में 4.09% ( स्टेटकाउंटर )
• नीदरलैंड में 6.17% ( स्टेटकाउंटर )

IE11 समर्थन को "पूर्ण दृश्य" स्तर के बजाय "कार्यात्मक" पर छोड़ना एक सामान्य उद्योग मानक है।

माना

मैं नहीं जानता कि कितना ठोस है जैसे कि 11CustomProperties पॉलीफिल, लेकिन डेवलपर्स हमेशा जरूरत पड़ने पर इसे मैन्युअल रूप से शामिल कर सकते हैं। आप इसे किसी प्रकार के ऑप्ट-इन टॉगल के माध्यम से कोर से भी प्रदान कर सकते हैं?

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

IE11 समर्थन को "पूर्ण दृश्य" स्तर के बजाय "कार्यात्मक" पर छोड़ना एक सामान्य उद्योग मानक है।

इसी तरह हम में से अधिकांश css-vars और IE conundrum से निपटते हैं ... कुछ समझदार वैश्विक CSS नियमों को परिभाषित करना जो तब css-vars द्वारा ओवरराइड हो जाते हैं। यदि आगंतुक IE पर है, तो वे अभी भी पूरी तरह से वेबसाइट का उपयोग करने में सक्षम हैं - बस एक अलग रंग योजना, रिक्ति आदि के साथ।
वर्डप्रेस IE11 के साथ संगत है, लेकिन "IE11 के साथ संगत" का मतलब यह नहीं है कि IE11 चीजों को उसी तरह दिखाना चाहिए जिस तरह से एक पोस्ट-डायनासोर ब्राउज़र उन्हें प्रस्तुत करता है ... जब तक यह कार्यात्मक है हम स्पष्ट हैं।

मैं ie11CustomProperties का ऑटोर हूं। https://github.com/nuxodin/ie11CustomProperties/
इस बीच पॉलीफिल काफी तेज है और काफी सपोर्ट करता है।
यदि आप इसे आजमाना चाहते हैं तो समस्याओं के मामले में मैं खुशी से आपका समर्थन करूंगा।

@nuxodin निष्पक्ष होने के लिए, मैंने महीनों में इसका परीक्षण नहीं किया है, पिछली बार मैंने उस विशिष्ट रेपो की जाँच की थी जो v1.3 पर था, मुझे लगता है कि यह तब से एक लंबा सफर तय कर चुका है: +1:

रिज़ॉल्वर तब a . बनाएगा

@nuxodin वाह! यह आशाजनक लग रहा है! बहुत - बहुत धन्यवाद। IE11 का परीक्षण शुरू करने के लिए तैयार होने के बाद हम निश्चित रूप से ie11CustomProperties का पता लगाएंगे।

मैंने अभी यह सोचना शुरू किया है कि यह वहां कैसे काम कर सकता है, लेकिन मैं इस मुद्दे को जल्द से जल्द फ़्लैग करना चाहता था।
@koke धन्यवाद 🙏 !! मैं वास्तव में आपकी और अन्य लोगों की जितनी जल्दी हो सके मुद्दों/गड़बड़ी के बारे में सोचने की सराहना करता हूं।

यदि आगंतुक IE पर है, तो वे अभी भी पूरी तरह से वेबसाइट का उपयोग करने में सक्षम हैं - बस एक अलग रंग योजना, रिक्ति आदि के साथ।
वर्डप्रेस IE11 के साथ संगत है, लेकिन "IE11 के साथ संगत" का मतलब यह नहीं है कि IE11 चीजों को उसी तरह दिखाना चाहिए जिस तरह से एक पोस्ट-डायनासोर ब्राउज़र उन्हें प्रस्तुत करता है ... जब तक यह कार्यात्मक है हम स्पष्ट हैं।

@aristath , मैं इस भावना से काफी सहमत हूं। मुझे लगता है कि यदि IE11 आपका प्राथमिक ब्राउज़र है, तो आप पहले से ही आधुनिक वेब की पेशकश की बहुत सारी चीज़ों को याद कर रहे हैं। जब तक वह फ़ॉलबैक संस्करण काम करता है और पहुंच योग्य है, यह ठीक होना चाहिए लेकिन यह केवल तभी सच हो सकता है जब आप _साइट विज़िटर_ किसी और की वर्डप्रेस साइट ब्राउज़ कर रहे हों।

IE11 ब्राउज़र के साथ WordPress का उपयोग करने वाले _site admin_ के दृष्टिकोण से, यह जानना कठिन है कि संपादन/अनुकूलन अनुभव कैसा होगा। IE11 ब्राउज़र का उपयोग करते समय हमें WordPress साइट व्यवस्थापकों के लिए वैश्विक शैलियों को अक्षम करने के लिए कुछ जोड़ने की आवश्यकता हो सकती है। अन्यथा, वे अपने द्वारा किए गए किसी भी अनुकूलन को नहीं देख पाएंगे जो उनके लिए एक टूटे हुए अनुभव की तरह लग सकता है।

IE11 समर्थन को "पूर्ण दृश्य" स्तर के बजाय "कार्यात्मक" पर छोड़ना एक सामान्य उद्योग मानक है।

यह यहां भी पर्याप्त हो सकता है, विशेष रूप से स्क्रीन रीडर उपयोग के मामले को देखते हुए कि बाकी थीम और ब्लॉक स्टाइल एक फॉलबैक के रूप में काम करते हैं?

मुझे संपादक पक्ष के लिए इस विकल्प के साथ जाने में अधिक खुशी हो रही है। मेरी प्राथमिक चिंता सामने के छोर पर CSS vars को आउटपुट करने के साथ है, क्योंकि इसका मतलब है कि WP _no के साथ वेबसाइट बनाने वाले किसी भी व्यक्ति के पास IE का पूरी तरह से समर्थन करने के लिए विकल्प_ है यदि वे चाहें। और मेरी पिछली टिप्पणी के साथ (क्षमा करें अगर यह पर्याप्त स्पष्ट नहीं था) मेरा मतलब यह था कि यह सरकार और अन्य आधिकारिक संस्थाओं के लिए एक समस्या हो सकती है जो कि पूर्ण समर्थन प्रदान करने के लिए _have_ हो सकती है।

मैं प्रदर्शन प्रभावों के कारण पॉलीफिल मार्ग पर जाने के लिए भी अनिच्छुक हूं। यह कुछ जांच करने लायक हो सकता है कि हम सामने के छोर पर सीएसएस वर्र्स का उपयोग किए बिना इसे कैसे प्राप्त कर सकते हैं (भले ही हम उन्हें संपादक में उपयोग करते हों)।

मेरी प्राथमिक चिंता सामने के छोर पर CSS vars को आउटपुट करने के साथ है, क्योंकि इसका मतलब है कि WP के साथ वेबसाइट बनाने वाले किसी भी व्यक्ति के पास IE को पूरी तरह से समर्थन करने का विकल्प नहीं है, यदि वे चाहें।

एक PHP पार्सर जोड़ना संभव है जो सक्षम होने पर सर्वर-साइड चलाएगा और css-vars को उनके वास्तविक मानों से बदल देगा। यह IE पर सब कुछ ठीक वैसा ही दिखाएगा जैसा कि यह एक आधुनिक ब्राउज़र पर दिखाएगा।
जिस एजेंसी के लिए मैं काम करता हूं उसके लिए हमने इसे पहले किया है और यह पूरी तरह से ठीक काम करता है।
ऐसे कार्य के लिए आवश्यक सभी फ़िल्टर पहले से ही मौजूद हैं, इसलिए यह एक असंभव कार्य नहीं है।

एक PHP पार्सर जोड़ना संभव है जो सक्षम होने पर सर्वर-साइड चलाएगा और css-vars को उनके वास्तविक मानों से बदल देगा। यह IE पर सब कुछ ठीक वैसा ही दिखाएगा जैसा कि यह एक आधुनिक ब्राउज़र पर दिखाएगा।

यह निश्चित रूप से जाने का रास्ता है। हालांकि एक सीमा के साथ मुझे लगता है, जब तक सीएसएस वर्र्स को रूट या इसी तरह के शीर्ष-स्तरीय चयनकर्ता में रखा जाता है। https://jhildenbiddle.github.io/css-vars-ponyfill/ के समान

एक PHP पार्सर जोड़ना संभव है जो सक्षम होने पर सर्वर-साइड चलाएगा और css-vars को उनके वास्तविक मानों से बदल देगा। यह IE पर सब कुछ ठीक वैसा ही दिखाएगा जैसा कि यह एक आधुनिक ब्राउज़र पर दिखाएगा। मैंने इसे पहले उस एजेंसी के लिए किया है जिसके लिए मैं काम करता हूं और यह पूरी तरह से ठीक काम करता है।

यह PHP विचार वास्तव में दिलचस्प लगता है, खासकर यदि यह समान सीमाओं के साथ संघर्ष नहीं करता है जो फ़ॉलबैक करता है। मुझे कार्रवाई में काम कर रहे पीआर या कोड स्निपेट को देखना अच्छा लगेगा-बहुत आशाजनक लगता है :-)

निश्चित रूप से, मैं इसके लिए PHP कार्यान्वयन पर काम कर सकता हूं ...
हमें मूल रूप से 2 चीजों की आवश्यकता होगी:

1. CSS वर्र्स के मान प्राप्त करें।
2. IE11 के लिए फ़ॉलबैक शैलियाँ जोड़ें।

पहले के लिए मैंने एक फिल्टर जोड़ने के बारे में https://github.com/WordPress/gutenberg/pull/19883#pullrequestreview -349737431 पर एक टिप्पणी छोड़ी। हम उस फ़िल्टर का उपयोग css-vars और उनके मान प्राप्त करने के लिए कर सकते हैं।

दूसरा इस बात पर निर्भर करता है कि उन सीएसएस-वार्स का उपयोग करने वाला वास्तविक सीएसएस कहां मुद्रित होता है। क्या यह ब्लॉक में इनलाइन होगा? यदि ऐसा है, तो हम बैकवर्ड-संगतता सीएसएस को इंजेक्ट करने का ख्याल रखने के लिए render_block फ़िल्टर का उपयोग कर सकते हैं।
यदि नहीं, तो क्या कोई जनसंपर्क या विचार है कि इन्हें कैसे/कहाँ मुद्रित किया जाएगा? या थीम केवल wp_enqueue_style का उपयोग करके स्टाइलशीट को एनक्यू करेंगे?
यदि wp_enqueue_style का उपयोग किया जाता है, तो यह अभी भी करने योग्य है, लेकिन संलग्न फ़ाइलों की सामग्री को पार्स करने की आवश्यकता होगी, css-vars की तलाश करें, और यदि इन vars का उपयोग फ़ाइल में किया जाता है, तो उन शैलियों को कैल्क करें जिन्हें जोड़ने की आवश्यकता है और उन्हें प्रिंट करें . टीबीएच मैं इस आखिरी विकल्प से बचना चाहता हूं क्योंकि अगर थीम बड़ी फाइलें जोड़ती है तो यह कुछ ओवरहेड जोड़ सकती है।

ग्लोबल स्टाइल्स रोडमैप

अब तक आपके विचारों/प्रतिक्रिया के लिए आप सभी का धन्यवाद!

सिस्टम के कुछ पहलुओं (जैसे सीएसएस रेंडरिंग) के बारे में कुछ चर्चा हुई है, जो मान्य है। समग्र प्रणाली के लिए बहुत अधिक प्रतिरोध या चिंता प्रतीत नहीं होती है और कैसे टुकड़े एक साथ फिट होते हैं, जो एक अच्छा संकेत है। ऐसा लगता है कि हम सही रास्ते पर हैं!

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

इस वजह से, मुझे लगता है कि एक स्पष्ट (उच्च स्तरीय) दृष्टि प्रदान करना वास्तव में महत्वपूर्ण है - इसमें शामिल किसी भी व्यक्ति के लिए इसे समझना और अनुसरण करना आसान हो जाता है।

मैंने सिस्टम के काम करने के तरीके के साथ-साथ काम के चरणों को अनुक्रमित करने के लिए एक मोटा रोडमैप के लिए एक उच्च-स्तरीय अवलोकन को एक साथ रखा है।

📹 वीडियो स्क्रीनकास्ट / पूर्वाभ्यास
https://www.loom.com/share/9e63b821916a4f70821a52ced069b92b

वीडियो में, मैं सिस्टम के रेंडरिंग प्रवाह के माध्यम से चलता हूं और चरणों में जाता हूं।

रेंडर फ्लो

आरेख (ऊपर) वैश्विक शैलियों के रेंडर प्रवाह को दिखाता है। यह प्रणाली की शैली पदानुक्रम की कल्पना करता है। मैंने इसे "सिंथेटिक कैस्केड" नाम दिया है।

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

"दायरा"

शब्द "स्कोप्ड" एफएसई अनुभव से "दस्तावेज़" या "टेम्पलेट" भाग को संदर्भित करता है। अनिवार्य रूप से, एक "कंटेनर" ब्लॉक जिसमें ब्लॉक होते हैं।

तृतीय पक्ष ब्लॉक

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

तृतीय पक्ष ग्लोबल्स

तृतीय पक्ष ग्लोबल्स गैर-मुख्य शैलियों को संदर्भित करता है जो किसी ब्लॉक से संबद्ध नहीं हैं। उदाहरण के लिए, समग्र साइट एनिमेशन गति के लिए कस्टम वैश्विक शैलियों को जोड़ना। या शायद समग्र साइट टाइपोग्राफी फ़ॉन्ट पेयरिंग (हेडर/बॉडी)।

के चरण

मैंने काम को 6 अलग-अलग चरणों (ऊपर) में विभाजित किया है। नोट: जीवंतता उस क्षेत्र पर ध्यान केंद्रित करने पर जोर देती है जिसकी हमें आवश्यकता होगी। उदाहरण के लिए, पहले चरण में, रेड, कोर/ब्लॉक क्षेत्र बहुत जीवंत है।

लाल

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

शुरू करने के लिए, हम core/paragraph और core/heading ब्लॉक को लक्षित करने जा रहे हैं।

इसे एमवीपी पर विचार करें!

संतरा

दूसरा चरण! यह चरण सिस्टम में थीम समर्थन शुरू करने पर केंद्रित है। थीम विकल्प और theme.json फ़ाइल कोर डिफ़ॉल्ट के साथ कैसे परस्पर क्रिया करेगी। अंत में, थीम परिभाषित मूल्यों को कैसे प्रस्तुत किया जाता है और ग्लोबल स्टाइल्स संपादक UI के भीतर संशोधित किया जा सकता है।

पीला

तीसरा चरण! यह चरण वैश्विक शैलियाँ संपादक पर केंद्रित है। ब्लॉक शैली के मूल्यों को कैसे प्रस्तुत किया जाता है और उन्हें कैसे संशोधित किया जा सकता है। उपयोगकर्ता-अनुकूलित वैश्विक शैलियाँ थीम और मूल मूल्यों को कैसे प्रभावित करती हैं।

यह पहला चरण है जिसमें बहुत सारे विज़ुअल/इंटरैक्शन डिज़ाइन शामिल होंगे।

हरा

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

नीला

पाँचवाँ चरण! यह चरण शैली प्रतिपादन पहलू पर बहुत अधिक केंद्रित है। यहां, हम फिर से देखेंगे जहां CSS वेरिएबल सही समाधान हैं। यदि नहीं, तो बाकी सिस्टम के साथ काम करते हुए उस अनुभव को दोहराने के लिए हम क्या कर सकते हैं। समाधान पर काम करते समय, हमें यह सुनिश्चित करना होगा कि स्कोपिंग के साथ-साथ थीम अपेक्षा के अनुरूप काम करे। अंत में, यह चरण तीसरे पक्ष के ब्लॉक समर्थन को देखना शुरू कर देगा, और यह देखना शुरू कर देगा कि यह बाकी सिस्टम के साथ कैसे खेलता है।

बैंगनी

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

हम कहाँ पर हैं?

फिलहाल, वर्णित चरणों (ऊपर) के साथ, हमने अपनी पहली पहल के साथ 🔴 लाल चरण शुरू किया है।

@jorgefilipecosta ने एक प्रारंभिक पीआर बनाया है जो इस चरण के सभी पहलुओं को छूता है।

@karmatosed ग्लोबल स्टाइल्स एडिटिंग इंटरफेस के लिए डिजाइन तलाश

@nosolosw सिस्टम के रिज़ॉल्वर x क्लाइंट-साइड रेंडरर पहलू पर काम कर रहा है।

मैं नियंत्रणों को देखने के लिए आगे बढ़ रहा हूं।

समय

मैं अभी तक परियोजना के लिए एक सटीक समयरेखा प्रदान नहीं कर सकता। मुझे लगता है कि निर्माण, परीक्षण और विलय शुरू करने के बाद हमें चीजों की बेहतर समझ होगी। तब तक, उम्मीद है कि चरणों के टूटने से मदद मिलेगी।

हमेशा की तरह, विचारों और प्रतिक्रिया का स्वागत है! यदि आपने इसे अंत तक बनाया है, तो आपके समय के लिए बहुत-बहुत धन्यवाद! :दिल:

निश्चित रूप से, मैं इसके लिए PHP कार्यान्वयन पर काम कर सकता हूं ...
हमें मूल रूप से 2 चीजों की आवश्यकता होगी:

1. CSS वर्र्स के मान प्राप्त करें।
2. IE11 के लिए फ़ॉलबैक शैलियाँ जोड़ें।

पहली बार मैंने फ़िल्टर जोड़ने के बारे में #19883 (समीक्षा) पर एक टिप्पणी

दूसरा इस बात पर निर्भर करता है कि उन सीएसएस-वार्स का उपयोग करने वाला वास्तविक सीएसएस कहां मुद्रित होता है। क्या यह ब्लॉक में इनलाइन होगा? यदि ऐसा है, तो हम बैकवर्ड-संगतता सीएसएस को इंजेक्ट करने का ख्याल रखने के लिए render_block फ़िल्टर का उपयोग कर सकते हैं।
यदि नहीं, तो क्या कोई जनसंपर्क या विचार है कि इन्हें कैसे/कहाँ मुद्रित किया जाएगा? या थीम केवल wp_enqueue_style का उपयोग करके स्टाइलशीट को एनक्यू करेंगे?
यदि wp_enqueue_style का उपयोग किया जाता है, तो यह अभी भी करने योग्य है, लेकिन संलग्न फ़ाइलों की सामग्री को पार्स करने की आवश्यकता होगी, css-vars की तलाश करें, और यदि इन vars का उपयोग फ़ाइल में किया जाता है, तो उन शैलियों को कैल्क करें जिन्हें जोड़ने की आवश्यकता है और उन्हें प्रिंट करें . टीबीएच मैं इस आखिरी विकल्प से बचना चाहता हूं क्योंकि अगर थीम बड़ी फाइलें जोड़ती है तो यह कुछ ओवरहेड जोड़ सकती है।

हाय @अरिस्टथ ,

अपने विचार साझा करने और इस समस्या का समाधान करने का प्रयास करने के लिए धन्यवाद।

मुझे लगता है कि हम दूसरे परिदृश्य की उपस्थिति में हैं, wp_enqueue_style का उपयोग किया जाता है। वेरिएबल्स का उपयोग करने वाली शैलियाँ सामान्य ब्लॉक शैलियाँ हैं, और वे ज्यादातर बार wp_enqueue_style का उपयोग करके एनक्यू की जाती हैं। इसके अलावा, हमारे पास एक और भी बड़ी समस्या है कोर ब्लॉक शैलियों में इन चरों को वर्डप्रेस स्टाइल कॉन्सटेनेशन सिस्टम का उपयोग करके लोड किया जाता है, इसलिए वे एक विशाल स्प्रेडशीट का हिस्सा हैं।

एक और बिंदु यह है कि vars का एक साधारण प्रतिस्थापन काम नहीं कर सकता है क्योंकि विचार यह है कि भविष्य में हम एक विशिष्ट ब्लॉक के अंदर चीजों के लिए वैश्विक शैलियों को अनुकूलित करने में सक्षम होंगे (उदाहरण के लिए, किसी विशेष समूह के अंदर प्राथमिक रंग नीला है)। वेरिएबल के मान स्थिर नहीं हो सकते हैं; वे संदर्भ पर निर्भर करेंगे।

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

रिज़ॉल्वर तब a . बनाएगा

@ItsJonQ

यह दाईं ओर से शुरू होता है (गुटेनबर्ग और ब्लॉक के साथ)

मुझे लगता है कि आपका मतलब है कि यह बाईं ओर शुरू होता है?

जो मुझे अभी तक समझ में नहीं आया: रंग पैलेट और विशेष रूप से पृष्ठभूमि रंग इसमें कैसे खेलेंगे?

• यदि मैं वैश्विक स्तर पर विभिन्न तत्वों के रंगों को नियंत्रित करने में सक्षम हूं, तो क्या मैं एक रंग पैलेट भी परिभाषित कर सकता हूं जिसका उपयोग संपादक रंग पैलेट के रूप में किया जाएगा?
• यदि मेरे पास पृष्ठभूमि रंगों के लिए रंग पैलेट है, तो क्या मैं वैश्विक स्तर पर नियंत्रित कर सकता हूं कि एक तत्व विभिन्न पृष्ठभूमि पर कैसा दिखता है?

उदाहरण के लिए एक बटन लें। यदि मैं अपने डिफ़ॉल्ट बटन के लिए पृष्ठभूमि के रूप में लाल रंग चुनता हूं, तो यह विभिन्न पृष्ठभूमियों पर कैसा दिखेगा, उदाहरण के लिए नारंगी पर?

क्या मैं नारंगी पृष्ठभूमि पर बटन पृष्ठभूमि के रंग को विश्व स्तर पर नियंत्रित कर सकता हूं? या क्या मुझे अभी भी प्रत्येक बटन के लिए अलग-अलग पृष्ठभूमि रंगों का चयन करना है, जब वे अलग-अलग पृष्ठभूमि पर दिखाई देते हैं?

रंग पैलेट और विशेष रूप से पृष्ठभूमि रंग इसमें कैसे खेलेंगे?

@gchtr यह एक अच्छा सवाल है + उदाहरण! अगर मैं आपके प्रश्न/उपयोग-मामले को सही ढंग से समझता हूं ... ऐसा लगता है कि हमें उस मामले को संभालने की जरूरत है जहां:

• सभी बटन विश्व स्तर पर लाल पृष्ठभूमि के लिए स्टाइल किए गए हैं
• लेकिन, जब वे टकराने वाली पृष्ठभूमि (जैसे नारंगी) के साथ किसी चीज़ में दिखाई देते हैं, तो उन्हें एक अलग रंग (जैसे सफेद, काले पाठ के साथ ) प्रस्तुत करने की आवश्यकता होती है।

यहीं से कस्टम वैश्विक शैलियों को "स्कोपिंग" करने का विचार चलन में आता है।

HTML/CSS के संदर्भ में, आप इसकी कल्पना कर सकते हैं:

<button>...</button>
<div class="orange-section">
    <button>...</button>
</div>

button { background: red; }

.orange-section button {
    background: white;
    color: black;
}

मुश्किल हिस्सा है। हम इस मॉडल/शैली पदानुक्रम को गुटेनबर्ग ग्लोबल स्टाइल सिस्टम में कैसे दोहराते हैं?
गुटेनबर्ग के संदर्भ में, ये बिट्स ब्लॉक होंगे।

तो एक तरह से... यह होगा:

<Block>
<Block>
    <Block />
</Block>

या इसे देखने का दूसरा तरीका ...

<Block>
<ContainerBlock>
    <Block />
</ContainerBlock>

इसका मतलब है, कि हमें "कंटेनर" ब्लॉक के लिए विशिष्ट शैलियों को स्कोप करने में सक्षम होना चाहिए, ताकि कोई भी (लक्षित) चाइल्ड ब्लॉक इन शैलियों को प्राप्त कर सके। शैली प्रणाली को UI परिप्रेक्ष्य (शैली संपादन नियंत्रण) और प्रतिपादन परिप्रेक्ष्य से इसका समर्थन करना चाहिए।

उम्मीद है कि यह समझ में आता है !!! 🙏

मुझे लगता है कि आपका मतलब है कि यह बाईं ओर शुरू होता है?

@ZebulanStanphil हाँ! बहुत - बहुत धन्यवाद! मैंने इसे ठीक कर दिया है :)

अरे @ItsJonQ ,

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

रंग पैलेट घटक मेरे सेटअप में एक बड़ी भूमिका निभाता है क्योंकि हेडलाइंस और बटन पृष्ठभूमि के लिए एक ही रंग का उपयोग किया जा सकता है, इसे थोड़ा स्पष्ट करने के लिए यहां एक उदाहरण दिया गया है:

ऑक्सीजन पहले से ही ऐसा अद्भुत तरीके से कर रही है, जिससे वैश्विक रंग बदलने और इसके प्रभाव को लाइव देखने की अनुमति मिलती है। मुझे उम्मीद है कि यह व्यवहार किसी तरह ग्लोबल स्टाइल सिस्टम में भी आएगा।

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

@dnnsjsk आपके समर्थन और उस प्यारे उदाहरण के लिए धन्यवाद!

हाँ, हम इस बातचीत का समर्थन किया है।

अंततः, यह संपूर्ण प्रयास उपयोगकर्ता अनुभव को बेहतर (अंत) करने के लिए है। समायोजनों को न केवल आपकी अपेक्षा के अनुरूप बदलना चाहिए, बल्कि उन समायोजनों को करते समय अनुभव अच्छा लगना चाहिए। इसे रचनात्मक, मुक्त और मजेदार महसूस करना चाहिए। जो गुटेनबर्ग संपादन अनुभव के लक्ष्यों के अनुरूप है :)।

बेशक, इस अंक में मेरे द्वारा साझा किए गए पाठ की दीवार के आधार पर इस अनुभव को चुनना मुश्किल है । मैंने ज्यादातर तकनीकी पहलुओं पर ध्यान केंद्रित किया है और वे टुकड़े एक साथ कैसे काम करेंगे। एक अच्छे एंड-यूज़र अनुभव के अलावा, डेवलपर का अनुभव अच्छा होना चाहिए। हम जो कार्यप्रवाह स्थापित करते हैं, वे Themers और Block devs के लिए आसान और बेहतर महसूस करते हैं।

@karmatosed , @shaunandrews , और अन्य लोग यहां इस अनुभव के डिज़ाइन/UX का पता लगाना शुरू कर रहे हैं:

https://github.com/WordPress/gutenberg/issues/19255

हम अभी भी बहुत जल्दी हैं! मुझे लगता है कि हालिया रोडमैप देव एक्स डिजाइन प्रयासों को एक साथ काम करने में मदद करेगा।

नमस्कार! मैंने अभी-अभी https://github.com/WordPress/gutenberg/issues/19255#issuecomment -582315718 पर एक लंबी टिप्पणी लिखी है, जिसे शायद मुझे यहाँ पोस्ट करना चाहिए था? किसी भी मामले में उस टिप्पणी से मुख्य बात यह है कि बुनियादी ब्लॉक पैटर्न को डिजाइन करने के प्रयास के हिस्से के रूप में, मैंने अनजाने में उन वस्तुओं की एक इच्छा सूची बनाई है जिन्हें मैं वैश्विक शैली प्रणाली को पूरा करने में सक्षम देखना चाहता हूं (जैसे फ़ॉन्ट-वेट, लाइन -हाइट, ड्रॉपकैप-साइज़), ज्यादातर चीजें जो मैंने पहले ही देख ली हैं।

कृपया स्लाइडर्स को "थोड़ा चिपचिपा" बनाएं (चिकनी स्लाइडर्स बड़ी रेंज पर एक भयानक उपयोगकर्ता अनुभव हैं) और वर्तमान मूल्य प्रदर्शित करें।

@ carike-codes हमारे पास अद्यतन RangeControl घटक में वे विशेषताएं हैं
https://github.com/WordPress/gutenberg/pull/19916

स्लाइडर बिल्कुल वैसा ही व्यवहार करता है जैसा कि एक डिफ़ॉल्ट HTML input[type="range"] होता है। ऐसी स्थिति में जहां कई चरण हैं, उदाहरण के लिए, min: 0, max: 1000, step: 1 , यह "चिकनी" महसूस करेगा, क्योंकि 1000 में वृद्धि करने के लिए मान हैं

(उम्मीद है की वो मदद करदे)

_नोट: यह टिप्पणी प्रतिक्रिया-मूल संगतता के बारे में है_

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

तो अगर मैं इसे सही ढंग से समझता हूं तो हम रिज़ॉल्वर के क्लाइंट-साइड संस्करण को लागू करना चाहेंगे जो उस एपीआई का उपभोग करेगा? क्या यह एफएसई को ब्लॉक शैलियों को अपडेट करने में सक्षम होने में भी मदद नहीं करेगा क्योंकि वैश्विक शैलियों को नियंत्रण में अपडेट किया जाता है?

यदि ऐसा है तो गुटेनबर्ग मूल निवासी इस क्लाइंट-साइड रिज़ॉल्वर का पुन: उपयोग करना चाहेगा।

अभी भी सीएसएस चर का मुद्दा है जो प्रतिक्रिया-मूल पर समर्थित नहीं हैं। एक पोस्टसीएसएस ट्रांसफॉर्म काम नहीं करेगा क्योंकि हमें एपीआई में एक नए फ़ेच के साथ अपडेट करने के लिए गतिशील होने की आवश्यकता है।

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

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

--wp-gs-color-text: #fff;
--wp-gs-background-color: yellow;
--wp-gs-paragraph-color-text: #000;

.wp-gs p {
    color: var(--wp-gs-color-text);
    background-color: var(--wp-gs-background-color);
}

<!-- wp:paragraph {"textColor":"red"} -->
<p style="--wp-gs-paragraph-color-text: red;">
Lorem ipsum dolor sit amet</p>
<!-- /wp:paragraph -->

मोबाइल पर हमें वही सटीक कोड जेनरेट करने की आवश्यकता होती है, इसलिए save अपरिवर्तित होना चाहिए। हालांकि, edit को css वेरिएबल का उपयोग करने से बचना चाहिए:

<RichText style={ { color: "red", backgroundColor: "yellow" } } .../>

मुझे यकीन नहीं है कि अभी तक एक्स-प्लेटफ़ॉर्म ब्लॉक लिखने के संदर्भ में क्या प्रभाव हैं। ऐसा मॉड्यूल लिखना जो किसी विशेष ब्लॉक के लिए सभी शैलियों को स्वचालित रूप से हल करता है, कम से कम अगर हम खुद को कुछ सीएसएस गुणों तक सीमित रखते हैं और यदि हमारे पास रिचटेक्स्ट घटक के अंदर कई अनुकूलन योग्य तत्व नहीं हैं।
वेब और मोबाइल शायद इसे साझा कर सकते हैं, हालांकि इसका प्रदर्शन प्रभाव हो सकता है, इस स्थिति में हमें इसे केवल मोबाइल पर सक्रिय करने की आवश्यकता होगी। @jorgefilipecosta @koke सुनिश्चित नहीं हैं कि क्या आपके पास इस पर कोई विचार है?

@koke सुनिश्चित नहीं हैं कि क्या आपके पास इस पर कोई विचार है?

हां, मैं समान चिंताओं को साझा करता हूं, लेकिन मेरे पास अभी तक कोई स्पष्ट उत्तर नहीं है। मेरी वर्तमान प्रवृत्ति यह है कि हमारी सबसे अच्छी शर्त वास्तव में सीएसएस पार्सर में सुधार कर सकती है जिसका उपयोग हम मूल रूप से सीएसएस चर (और कुछ अन्य चीजें, जैसे डार्क मोड, मीडिया क्वेरी और @supports ) का समर्थन करने के लिए करते हैं। सीएसएस को एक चरण में StyleSheet में बदलने की कोशिश करने के बजाय, हम इसे DynamicStyleSheet उत्पन्न कर सकते थे जो रनटाइम पर कुछ चर और प्रश्नों को समायोजित करने में सक्षम होगा। यह एक बड़े प्रयास की तरह लगता है, इसलिए मैं अभी भी ऐसे विकल्पों की तलाश में हूं जो आसान हो सकते हैं।

क्या मैं बूटस्ट्रैप में परिभाषित एससीएसएस चरों को अधिलेखित करने के लिए इसका उपयोग कर सकता हूं?

मैंने अभी-अभी ब्लॉक-आधारित वेबसाइटों में एडवेंचर्स विद कॉम्प्लेक्स ग्लोबल सिस्टम्स - पार्ट वन पढ़ना समाप्त किया है, और मैंने सोचा कि इसे यहाँ साझा करना एक अच्छा विचार होगा। यह एक लंबा, लेकिन दिलचस्प पठन है, जो यहां कुछ लोगों को कुछ विचार दे सकता है।

हम ग्लोबल स्टाइल्स के साथ खेल रहे हैं और हमारे पास कुछ विचार/विचार/प्रश्न हैं।

वैश्विक शैलियों की वर्तमान दिशा

अगर मैं वर्तमान दिशा को समझता हूं, तो विचार वैश्विक शैली चर को ब्लॉक में हार्डकोड करना है ताकि वे उनका उपयोग कर सकें।

इसके बारे में कठिन हिस्सा यह है कि दानेदार नियंत्रण बहुत अधिक और व्यापक हो सकते हैं, और कस्टम स्थानों में उपयोग करना भी कठिन हो सकता है। उदाहरण के लिए, यह हो सकता है कि जिस तरह से दानेदार नियंत्रण काम करता है (वैचारिक रूप से बोलना, एक वाक्यात्मक उदाहरण नहीं):

gs-another-background-color
gs-yet-another-background-color
gs-h1-font-color
gs-h1-font-color-exception
gs-yet-another-h1-font-color-variation
...many more variables required

वैश्विक शैलियों की दिशा के लिए एक और विचार

उस दृष्टिकोण के साथ खेलने के बाद हम सोच रहे थे कि क्या वैश्विक शैली अधिक "चीज-अज्ञेयवादी" हो सकती है, और इस तरह सरलीकृत हो सकती है:

gs-color-2
gs-color-3
...more variables required, but no values are ever duplicated

यहां विचार यह है कि ब्लॉक चुन सकते हैं कि क्या वे चाहते हैं कि पृष्ठभूमि gs-color-1 , gs-color-2 , या gs-color-3 । संभवतः वैश्विक-शैली-चयनकर्ता UI के माध्यम से भी। यह कैसा दिख सकता है, इसका _really_ रफ मॉकअप यहां दिया गया है।

इस दृष्टिकोण के कुछ फायदे:

• कम कुल वैश्विक शैलियाँ चर आवश्यक हैं।
• शैलियों का अनुप्रयोग ब्लॉकों में चला जाता है, जिससे अधिक डिज़ाइन लचीलेपन की अनुमति मिलती है।
• मूल्यों के दोहराव की आवश्यकता नहीं है ( #fffff को gs-color-1 के रूप में कई बार के बजाय एक बार चुनें)
• ब्लॉक उपयोगकर्ताओं के पास वैश्विक शैली का उपयोग करने की सुविधा होती है, जहां वे उपयुक्त दिखते हैं। उदाहरण के लिए, यह पृष्ठभूमि, या फ़ॉन्ट, या सीमा के लिए हो सकता है, लेकिन सभी gs-color-1 उपयोग कर सकते हैं, बजाय #fffff 3 अलग-अलग समय को परिभाषित करने के।

अगर मुझे दोनों के बीच चयन करना है, तो मैं दृष्टिकोण बी के साथ जाऊंगा, लेकिन इसका संस्करण जो मैंने विषयों के लिए उतारा है, वह दृष्टिकोण ए का एक कम दानेदार संस्करण है जो दृष्टिकोण बी के शीर्ष पर बनाया गया है।

सबसे पहले, मैं रंगों का एक गुच्छा परिभाषित करता हूं:

--white: #ffffff;
--gray-light: #d4d4d4;
--gray-dark: #333333;
--black: #141414;
--aqua: #7fdbff;
--blue: #0074d9;
--navy: #00203f;
--teal: #38cccc;
--fuchsia: #f012bc;
--purple: #b00dc9;
--maroon: #85144b;

(मैं वर्डप्रेस के लिए आपके प्रस्तावित अधिक सामान्य --color-1 प्रकार के सेटअप का लाभ बड़े पैमाने पर देख सकता हूं, लेकिन प्रिंसिपल समान है।)

फिर, मैं उन जैसे कुछ अपेक्षाकृत सामान्य उच्च-स्तरीय चर पर मैप करता हूं:

--text-color: var(--black);
--text-color-secondary: var(--gray-dark);
--accent-color: var(--aqua);
--background-color: var(--white);
--heading-color: var(--navy);
--action-color: var(--purple);
--action-color--invoked: var(--maroon); /* hover & focus states */

थीम की आवश्यकता के अनुसार इन्हें और अधिक विशिष्ट चर के माध्यम से कैस्केड किया जा सकता है:

--focus-ring-color: var(--accent-color);

--link-color: var(--action-color);
--link-color--hover: var(--action-color--invoked);

--input-color: var(--text-color);
--input-border-color: var(--input-color);
--input-background-color: var(--background-color);

--button-color: var(--action-color);
--button-color--hover: var(--action-color--hover);

/* whatever other theme-specific variables I want to make up */

थीम लेखक यहां जितना चाहें उतना दानेदार हो सकता है (--h2-color, --page-title-color, --subhead-color, जो भी हो), लेकिन वे हमेशा कैस्केड को ध्यान में रखते हुए कोर का निर्माण करने का प्रयास कर सकते हैं . उदाहरण के लिए, यदि मैं अपने विषय में एक गहरे रंग योजना के साथ एक ब्लॉक जोड़ रहा था:

.is-theme-dark {
    --text-color: var(--white);
    --text-color--secondary: var(--gray-light);
    --accent-color: var(--aqua);
    --background-color: var(--navy);
    --heading-color: var(--blue);
    --action-color: var(--fuchsia);
    --action-color--invoked: var(--purple);
    /* whatever other theme-specific variables I want to switch */
}

स्विचिंग गियर, कोई नुस्खा प्लगइन बना रहा है जिसने शीर्ष-स्तरीय रंगों का उपयोग किया है, तो थीम लेखक के .is-theme-dark समूह ब्लॉक में छोड़े जाने पर ठीक काम करने का एक अच्छा मौका होगा:

.recipe {
   color: var(--text-color);
}
.recipe__image {
    border: 0.5rem solid var(--accent-color);
}
.recipe-print-button {
   color: var(--action-color);
}
.recipe-print-button__icon {
   color: var(--accent-color);
}

IE11 समर्थन के बारे में:

क्या आपने इस समाधान की जाँच की है: https://github.com/jhildenbiddle/css-vars-ponyfill ?

मुझे ब्लॉक स्टाइल सिस्टम के बारे में स्पष्टता लाने का सुझाव दिया गया था। मैं दो मुख्य धागों में जो हमारे पास है उसे समेकित करने का प्रयास कर रहा हूं: दृष्टि https://github.com/WordPress/gutenberg/issues/9534 और विशिष्ट चरण https://github.com/WordPress/gutenberg/issues/20331 जो मैं अगले दिनों में अपडेट करूंगा।

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

इस मुद्दे ने अपना उद्देश्य पूरा कर लिया है, इसलिए मैं इसे बंद कर रहा हूं। उपरोक्त संकेत इस बात के प्रमाण के रूप में काम करने चाहिए कि यह वार्तालाप कितना मौलिक है कि हमें चलने के लिए आवश्यक ठोस कदमों को उजागर करना है।