मिरीअम सुज़ैन, डेनवर, कोलोराडो में लेखिका, कलाकार, और वेब डेवलपर हैं. फ़िलहाल, वे कंटेनर क्वेरी और कैस्केड लेयर जैसे दिलचस्प सीएसएस स्पेसिफ़िकेशन पर काम कर रही हैं.
यह पोस्ट, Designcember का हिस्सा है. यह वेब डिज़ाइन का जश्न है, जिसे web.dev ने आपके लिए पेश किया है.
मिरीअम सुज़ैन, कोलोराडो के डेनवर में रहने वाली लेखिका, कलाकार, और वेब डेवलपर हैं. वह OddBird (एक वेब एजेंसी) की सह-संस्थापक हैं. साथ ही, CSS Tricks के लिए स्टाफ राइटर, Sass की कोर टीम की सदस्य, और CSS वर्किंग ग्रुप में W3C की आमंत्रित विशेषज्ञ हैं. हाल ही में, उन्होंने सीएसएस की नई सुविधाएं डेवलप करने पर ध्यान दिया है. जैसे, कैस्केड लेयर, कंटेनर क्वेरी, और स्कोप. ऑफ़लाइन, मिरियम एक पब्लिश की गई उपन्यासकार, नाटककार, और संगीतकार हैं. हमने Sass और CSS के साथ काम करने के बारे में उनसे बात की.
राहेल: मैंने पहली बार आपके काम के बारे में, आपके ग्रिड फ़्रेमवर्क Susy की वजह से जाना. आपको इसे बनाने की प्रेरणा कहां से मिली?
मरियम: साल 2008 में, वेब पर लेआउट का अनुभव बहुत अलग था. डेवलपर ने टेबल लेआउट का इस्तेमाल बंद कर दिया था. इसके बजाय, वे फ़्लोट की गई ऐसी ग्रिड का इस्तेमाल कर रहे थे जो ज़्यादा सिमैंटिक थीं, लेकिन अब भी हैकी थीं. एक ही साइज़ में फ़िट होने वाले 12 कॉलम वाले "ग्रिड फ़्रेमवर्क" का चलन बढ़ गया था. इनमें पहले से तय की गई (आम तौर पर स्टैटिक) ग्रिड होती थी. साथ ही, पहले से तय की गई सीएसएस क्लास का सेट होता था. अगर आपको अपनी ज़रूरत के मुताबिक कोई और सुविधा चाहिए, तो आपको खुद ही उसे ढूंढना पड़ता था. यह साफ़ तौर पर पता चल गया था कि वेबसाइटों को ज़्यादा रिस्पॉन्सिव बनाने की ज़रूरत है. हालांकि, मीडिया-क्वेरी अभी उपलब्ध नहीं थीं. साथ ही, फ़्लूड फ़्लोट से जुड़ी ब्राउज़र के साथ काम करने की कई समस्याएं थीं.
मैंने Natalie Downe के CSS Systems का इस्तेमाल किया था. यह फ़ॉन्ट और व्यूपोर्ट, दोनों के साइज़ के हिसाब से काम करता था. हालांकि, मुझे बार-बार गणित के सवालों को हल करने और ब्राउज़र हैक करने की वजह से परेशानी हो रही थी. उसी समय, Sass को कुछ लोकप्रियता मिल रही थी और यह मेरी ज़रूरतों के हिसाब से एकदम सही था. Susy का पहला ड्राफ़्ट बहुत आसान था: इसमें सिर्फ़ कुछ मिक्सइन थे, जो हिसाब-किताब करते थे और मेरी ज़रूरत के हैक जोड़ते थे. इसका मकसद कम से कम कोड जनरेट करना और सिर्फ़ ज़रूरी कोड का आउटपुट देना था. पूरी तरह से पसंद के मुताबिक़ बनाए जा सकने वाले ग्रिड, जिनमें पहले से तय की गई कोई क्लास नहीं होती.
राहेल: आपने सीएसएस प्रीप्रोसेसर पर काम करने से लेकर सीएसएस स्पेसिफ़िकेशन पर काम करने तक का सफ़र कैसे तय किया? क्या आपको लगता है कि प्रीप्रोसेसर पर काम करना, स्पेसिफ़िकेशन लिखने के लिए एक अच्छा बैकग्राउंड था?
मरियम: मेरे अनुभव के मुताबिक, दोनों में काफ़ी समानता है. साथ ही, मैं अब भी दोनों तरह के काम में सक्रिय हूं. हालांकि, मुझे लगता है कि इसका ज़्यादातर श्रेय Sass टीम को जाता है. इस टीम का नेतृत्व Natalie Weizenbaum करती हैं. यह टीम, लंबे समय तक काम करने वाले टूल बनाने पर फ़ोकस करती है. साथ ही, ऐसे टूल बनाने की कोशिश करती है जो वेब स्टैंडर्ड के साथ आसानी से इंटिग्रेट हो सकें. जब मुख्य वेब स्टैंडर्ड के भविष्य के बारे में सोचा जा रहा हो, तो "राय पर आधारित" ऐसे समाधानों से आगे बढ़ना ज़रूरी है जो सभी के लिए एक जैसे हों. साथ ही, लंबे समय तक काम करने वाले फ़्लेक्सिबल समाधान तैयार करना भी ज़रूरी है.
हम ऐसे टूल कैसे बना सकते हैं जो डेवलपर की अलग-अलग ज़रूरतों और तरीकों का ध्यान रखें? साथ ही, वे सुलभता और अन्य ज़रूरी बातों को बढ़ावा दें और उन्हें आसान बनाएं?
राहेल: सीएसएस में कई नई सुविधाएं जोड़ी गई हैं. ये सुविधाएं, पहले Sass में उपलब्ध थीं. क्या अब भी Sass का इस्तेमाल करने की कोई वजह है?
मरियम: हां, कुछ लोगों के लिए—लेकिन इसका कोई एक जवाब नहीं है. उदाहरण के लिए, वैरिएबल लें. Sass वैरिएबल, लेक्सिकल स्कोप वाले होते हैं. इन्हें सर्वर पर कंपाइल किया जाता है. इनमें लिस्ट और ऑब्जेक्ट जैसे व्यवस्थित डेटा स्ट्रक्चर, रंग में बदलाव करने की सुविधा वगैरह होती है. यह डिज़ाइन सिस्टम के ऐसे लॉजिक के लिए बहुत अच्छा है जिसे ब्राउज़र में चलाने की ज़रूरत नहीं होती.
सीएसएस वैरिएबल में कुछ समानताएं होती हैं. ये वैल्यू भी सेव कर सकते हैं. हालांकि, ये कैस्केड पर आधारित ताकत और कमज़ोरियों का पूरी तरह से अलग सेट उपलब्ध कराते हैं. Sass, कस्टम प्रॉपर्टी को हैंडल नहीं कर सकता. वहीं, सीएसएस स्ट्रक्चर्ड डेटा को हैंडल नहीं कर सकता. दोनों ही फ़ायदेमंद और असरदार हैं. हालांकि, आपकी ज़रूरतें अलग-अलग हो सकती हैं.
मुझे लगता है कि यह बहुत अच्छा है कि लोग उन टूल को हटा सकते हैं जिनकी उन्हें अब ज़रूरत नहीं है. साथ ही, कुछ प्रोजेक्ट के लिए सर्वर-साइड और क्लाइंट-साइड, दोनों तरह के वैरिएबल की ज़रूरत नहीं हो सकती. शानदार! हालांकि, यह मान लेना बहुत आसान है कि दोनों एक जैसे हैं और एक की जगह दूसरे का इस्तेमाल किया जा सकता है. कुछ डिज़ाइन लॉजिक को सर्वर-साइड पर और कुछ को क्लाइंट-साइड पर लागू करने के लिए, हमेशा इस्तेमाल के उदाहरण मौजूद रहेंगे. भले ही, हम उस स्थिति में पहुंच जाएं जहां भाषाएं मूल रूप से एक जैसी सुविधाएं देती हैं. प्री-प्रोसेसर हमारे साथ लंबे समय तक काम करते हैं.
राहेल: क्या आपको स्टैंडर्ड बनाने के काम में शामिल होने के बाद, कोई ऐसी बात पता चली जिसके बारे में आपको पहले नहीं पता था? इसके अलावा, क्या आपको लगता है कि इस प्रोसेस के बारे में लोगों को आम तौर पर जानकारी नहीं होती?
मरियम: इस प्रोसेस में शामिल होने से पहले, मुझे स्टैंडर्ड प्रोसेस के बारे में कुछ भी नहीं पता था. मुझे नहीं पता था कि इसमें क्या-क्या शामिल है. मुझे डर था कि मेरे पास ब्राउज़र के इंटरनल के बारे में योगदान देने के लिए ज़रूरी जानकारी नहीं है. हालांकि, असलियत यह है कि उन्हें ज़्यादा ब्राउज़र इंजीनियर की ज़रूरत नहीं है. उन्हें ऐसे और डेवलपर और डिज़ाइनर की ज़रूरत है जो वेबसाइटें और ऐप्लिकेशन बना रहे हैं.
मुझे यह देखकर हैरानी हुई कि इसमें शामिल बहुत कम लोग मुख्य रूप से मानकों पर फ़ोकस करते हैं. साथ ही, बहुत कम लोग मुख्य रूप से वेबसाइटें डेवलप या डिज़ाइन करते हैं. W3C में सदस्य संगठनों के 'स्वयंसेवक' शामिल होते हैं. इन्हें अक्सर इन संगठनों से पेमेंट मिलती है, लेकिन यह इनका मुख्य काम नहीं होता. साथ ही, इसकी सदस्यता लेना सस्ता नहीं है. इससे, रोज़मर्रा के डिज़ाइनर और डेवलपर के बजाय, अन्य लोग इस प्रोग्राम में हिस्सा लेते हैं. खास तौर पर, छोटी एजेंसियों में क्लाइंट के लिए काम करने वाले या फ़्रीलांस काम करने वाले डिज़ाइनर और डेवलपर. अगर मुझे इस काम के लिए बाहर से फ़ंड नहीं मिलता, तो एक न्योता पाए विशेषज्ञ के तौर पर मेरी भूमिका पूरी तरह से स्वयंसेवा वाली होती. साथ ही, यह एक महंगा शौक होता.
असल में, यह प्रोसेस काफ़ी खुली और सार्वजनिक होती है. इसमें डेवलपर की भागीदारी ज़रूरी होती है. हालांकि, एक साथ कई बातचीत होने की वजह से, अपनी जगह ढूंढना मुश्किल हो सकता है. खास तौर पर, अगर यह आपका मुख्य काम नहीं है.
राहेल: कंटेनर क्वेरी, कई सालों से वेब डेवलपर के लिए सबसे अहम रही हैं. हमें ये सुविधाएं मिल रही हैं, इसलिए हम बहुत खुश हैं. मुझे लगता है कि कई लोग कंटेनर क्वेरी के फ़ायदे के बारे में सोच रहे हैं. क्या आपको लगता है कि इससे क्रिएटिविटी को भी बढ़ावा मिल सकता है?
मरियम: हां, हालांकि मुझे ये दोनों पूरी तरह से अलग नहीं लगते. हम सभी के पास समय सीमित है. इसलिए, हम ऐसा कोड लिखने की कोशिश कर रहे हैं जिसे आसानी से मैनेज किया जा सके और जो बेहतर परफ़ॉर्म करे. जब कोई काम करना मुश्किल होता है, तो हम उस काम को करने के लिए नए-नए तरीके नहीं सोचते.
हालांकि, वेब इंडस्ट्री पर अब बड़े कॉर्पोरेट का दबदबा है. इसलिए, कारोबार से जुड़ी इन चिंताओं को वेब कलाकारों की तुलना में हमेशा ज़्यादा अहमियत दी जाती है. मुझे लगता है कि अगर हम सुविधाओं के मुख्य इस्तेमाल के तौर पर वेब क्रिएटिविटी को नज़रअंदाज़ करते हैं, तो हमें काफ़ी नुकसान होगा. मुझे यह देखकर बहुत खुशी हुई कि सीएसएस आर्ट के कुछ लोग, कंटेनर क्वेरी के प्रोटोटाइप का इस्तेमाल कर रहे हैं. जे टॉमपकिंस ने सीएसएस वेनिसियन ब्लाइंड का एक खास और इंटरैक्टिव डेमो बनाया है. यह सीएसएस के विरोध में बने पुराने मीम पर टिप्पणी के तौर पर बनाया गया है. मुझे लगता है कि इस स्पेस में एक्सप्लोर करने के लिए बहुत कुछ है. मैं यह देखने के लिए बेताब हूं कि लोग और क्या-क्या करते हैं.
इस बातचीत में, साइज़ के हिसाब से क्वेरी करने पर भी फ़ोकस किया गया है, क्योंकि यह ओरिजनल यूज़-केस है. हालांकि, मुझे यह देखकर खुशी होगी कि लोग स्टाइल क्वेरी का इस्तेमाल कैसे करते हैं. स्टाइल क्वेरी की मदद से, सीएसएस प्रॉपर्टी या वैरिएबल की वैल्यू के आधार पर, शर्तों के हिसाब से स्टाइल लिखी जा सकती हैं. यह एक बहुत ही काम की सुविधा है. हालांकि, अब तक इसका इस्तेमाल ज़्यादा नहीं किया गया है. हमें लगता है कि इससे क्रिएटिविटी के और भी अवसर मिलते हैं!
राहेल: क्या सीएसएस में कोई ऐसी सुविधा है जिसे हम इस्तेमाल नहीं कर सकते या आने वाले समय में इस्तेमाल कर सकते हैं और आपको लगता है कि वह सुविधा हमारे लिए फ़ायदेमंद हो सकती है?
मरियम: मैं कुछ अन्य स्पेसिफ़िकेशन के बारे में बहुत उत्साहित हूं. इन पर मैं काम कर रही हूं. कैस्केड लेयर की मदद से, लेखकों को स्पेसिफ़िसिटी से जुड़ी समस्याओं को बेहतर तरीके से कंट्रोल करने में मदद मिलेगी. साथ ही, स्कोप की मदद से, सिलेक्टर को ज़्यादा सटीक तरीके से टारगेट किया जा सकेगा. हालांकि, ये दोनों ही आर्किटेक्चर से जुड़ी समस्याएं हैं. एक कलाकार के तौर पर, मैं सीएसएस टॉगल, इंटरैक्टिव स्टाइल बनाने का एलान करने वाला तरीका या कंटेनर 'टाइमलाइन' जैसी चीज़ों के लिए ज़्यादा उत्साहित हूं. इससे हमें मीडिया या कंटेनर ब्रेकपॉइंट के बीच वैल्यू को आसानी से ट्रांज़िशन करने की सुविधा मिलती है. इससे रिस्पॉन्सिव टाइपोग्राफ़ी पर काफ़ी असर पड़ेगा. साथ ही, रिस्पॉन्सिव आर्ट और ऐनिमेशन के लिए क्रिएटिव के कई अवसर भी मिलेंगे.
रेचल: फ़िलहाल, वेब पर और कौन-कौन मज़ेदार, दिलचस्प या क्रिएटिव काम कर रहा है?
मरियम: ओह, मुझे तो यह भी नहीं पता कि इसका जवाब कैसे दूँ. अलग-अलग क्षेत्रों में कई लोग क्रिएटिव काम कर रहे हैं. सीएसएस वर्किंग ग्रुप (सीएसएसडब्ल्यूजी) और ओपन-यूआई, दोनों ही कई दिलचस्प स्टैंडर्ड पर काम कर रहे हैं. इनमें फ़्रैगमेंटेशन पर किया गया आपका काम भी शामिल है. हालांकि, मुझे अक्सर वेब आर्टिस्ट से प्रेरणा मिलती है. साथ ही, मुझे यह भी प्रेरणा मिलती है कि लोग इन टूल का इस्तेमाल किस तरह से कर रहे हैं. ये ऐसे तरीके हैं जो सीधे तौर पर कारोबार से नहीं जुड़े हैं. जे, लिन फ़िशर, युआन चुआन जैसे लोगों या अन्य लोगों को वेब टेक्नोलॉजी के ज़रिए विज़ुअल और इंटरैक्टिव कॉन्टेंट बनाने में दिलचस्पी है. कारोबार से जुड़े काम करने वाले लोग भी, उनकी कलात्मक तकनीकों से बहुत कुछ सीख सकते हैं.
मैं बेन ग्रॉसर जैसे लोगों की कॉन्सेप्ट पर आधारित वेब आर्ट की भी सराहना करता हूं. वे हमें यह सोचने के लिए प्रेरित करते हैं कि हमें वेब और खास तौर पर सोशल मीडिया से क्या चाहिए. उदाहरण के लिए, उनका नया minus.social देखें.
राहेल: मिरियम के सीएसएस से जुड़े काम के बारे में जानने के लिए, css.oddbird.net पर जाएं. साथ ही, उसकी वेबसाइट miriam.codes और Twitter @TerribleMia पर जाकर, उसके अन्य कामों के बारे में जानें.