મૂળભૂત CSS ના સિદ્ધાંતો શીખતી વખતે, જાળવણીક્ષમતા સુનિશ્ચિત કરવા માટે મોડ્યુલર, ફરીથી વાપરી શકાય તેવી અને વર્ણનાત્મક શૈલીઓ લખવાનું શીખવવામાં આવે છે. પરંતુ જ્યારે વિકાસકર્તાઓ વાસ્તવિક-વિશ્વની એપ્લિકેશનો સાથે સંકળાયેલા બને છે, ત્યારે અણધાર્યા વિસ્તારોમાં લીક થતી શૈલીઓ વિના UI સુવિધાઓ ઉમેરવાનું ઘણીવાર અશક્ય લાગે છે. આ મુદ્દો ઘણીવાર સ્વ-સંપૂર્ણ લૂપમાં સ્નોબોલ કરે છે; શૈલીઓ કે જે સૈદ્ધાંતિક રીતે એક તત્વ અથવા વર્ગને આવરી લેવામાં આવે છે તે બતાવવાનું શરૂ કરે છે જ્યાં તેઓ સંબંધિત નથી. આ વિકાસકર્તાને લીક થયેલી શૈલીઓને ઓવરરાઇડ કરવા માટે હજી વધુ ચોક્કસ પસંદગીકારો બનાવવા માટે દબાણ કરે છે, જે પછી આકસ્મિક રીતે વૈશ્વિક શૈલીઓને ઓવરરાઇડ કરે છે, વગેરે. સખત વર્ગના નામ સંમેલનો, જેમ કે BEM, આ મુદ્દાનો એક સૈદ્ધાંતિક ઉકેલ છે. BEM (બ્લોક, એલિમેન્ટ, મોડિફાયર) પદ્ધતિ એ CSS ફાઈલોની અંદર પુનઃઉપયોગીતા અને માળખું સુનિશ્ચિત કરવા માટે CSS વર્ગોને નામ આપવાની પદ્ધતિસરની રીત છે. આના જેવા નામકરણ સંમેલનો તત્વો અને તેમની સ્થિતિનું વર્ણન કરવા માટે ડોમેન ભાષાનો લાભ લઈને જ્ઞાનાત્મક ભારને ઘટાડી શકે છે, અને જો યોગ્ય રીતે અમલમાં મૂકવામાં આવે તો, મોટી એપ્લિકેશનો માટે શૈલીઓ જાળવવામાં સરળ બનાવી શકે છે. વાસ્તવિક દુનિયામાં, જો કે, તે હંમેશા તેના જેવું કામ કરતું નથી. પ્રાથમિકતાઓ બદલાઈ શકે છે, અને પરિવર્તન સાથે, અમલીકરણ અસંગત બની જાય છે. HTML સ્ટ્રક્ચરમાં નાના ફેરફારો માટે ઘણા CSS વર્ગના નામના પુનરાવર્તનની જરૂર પડી શકે છે. અત્યંત ઇન્ટરેક્ટિવ ફ્રન્ટ-એન્ડ એપ્લીકેશન્સ સાથે, BEM પેટર્નને અનુસરતા વર્ગના નામ લાંબા અને અનિશ્ચિત બની શકે છે (દા.ત., app-user-overview__status--is-authenticating), અને નામકરણના નિયમોનું સંપૂર્ણ પાલન ન કરવાથી સિસ્ટમનું માળખું તૂટી જાય છે, જેનાથી તેના ફાયદાઓને નકારી શકાય છે. આ પડકારોને જોતાં, વિકાસકર્તાઓ ફ્રેમવર્ક તરફ વળ્યા તેમાં કોઈ આશ્ચર્યની વાત નથી, Tailwind સૌથી લોકપ્રિય CSS ફ્રેમવર્ક છે. શૈલીઓ વચ્ચે અજેય વિશિષ્ટતા યુદ્ધ જેવું લાગે છે તે લડવાનો પ્રયાસ કરવાને બદલે, CSS કાસ્કેડનો ત્યાગ કરવો અને સંપૂર્ણ અલગતાની ખાતરી આપતા સાધનોનો ઉપયોગ કરવો વધુ સરળ છે. વિકાસકર્તાઓ ઉપયોગિતાઓ પર વધુ ઝુકાવ કરે છે આપણે કેવી રીતે જાણી શકીએ કે કેટલાક વિકાસકર્તાઓ કાસ્કેડ શૈલીઓને ટાળવા માટે ઉત્સુક છે? તે "આધુનિક" ફ્રન્ટ-એન્ડ ટૂલિંગનો ઉદય છે — જેમ કે CSS-in-JS ફ્રેમવર્ક — જે ખાસ કરીને તે હેતુ માટે રચાયેલ છે. અલગ શૈલીઓ સાથે કામ કરવું જે ચોક્કસ ઘટકોને ચુસ્તપણે અવકાશમાં રાખે છે તે તાજી હવાના શ્વાસ જેવું લાગે છે. તે વસ્તુઓને નામ આપવાની જરૂરિયાતને દૂર કરે છે - હજુ પણ સૌથી વધુ નફરત અને સમય માંગી લેનારા ફ્રન્ટ-એન્ડ કાર્યોમાંનું એક - અને વિકાસકર્તાઓને CSS વારસાના લાભોને સંપૂર્ણ રીતે સમજ્યા વિના અથવા તેનો લાભ લીધા વિના ઉત્પાદક બનવાની મંજૂરી આપે છે. પરંતુ CSS કાસ્કેડને ડિચ કરવું તેની પોતાની સમસ્યાઓ સાથે આવે છે. દાખલા તરીકે, JavaScript માં શૈલીઓ કંપોઝ કરવા માટે ભારે બિલ્ડ રૂપરેખાંકનોની જરૂર પડે છે અને ઘણી વખત કમ્પોનન્ટ માર્કઅપ અથવા HTML સાથે અણઘડ રીતે મિશ્રિત શૈલીઓ તરફ દોરી જાય છે. નામકરણ સંમેલનોને ધ્યાનપૂર્વક ધ્યાનમાં લેવાને બદલે, અમે બિલ્ડ ટૂલ્સને અમારા માટે પસંદગીકારો અને ઓળખકર્તાઓને સ્વતઃ જનરેટ કરવાની મંજૂરી આપીએ છીએ (દા.ત., .jsx-3130221066), વિકાસકર્તાઓને પોતાની અંદર અને અન્ય સ્યુડો-ભાષા સાથે રાખવાની જરૂર છે. (જેમ કે તમારા બધા ઘટકોના ઉપયોગની અસરો શું કરે છે તે સમજવાનો જ્ઞાનાત્મક ભાર પહેલેથી પૂરતો ન હતો!) ટૂલિંગમાં વર્ગોના નામકરણના કાર્યને વધુ અમૂર્ત કરવાનો અર્થ એ છે કે વિકાસ માટે સંકલિત ચોક્કસ એપ્લિકેશન સંસ્કરણો માટે મૂળભૂત ડિબગીંગ ઘણીવાર મર્યાદિત હોય છે, લાઇવ ડિબગીંગને સપોર્ટ કરતા મૂળ બ્રાઉઝર સુવિધાઓનો લાભ લેવાને બદલે, જેમ કે વિકાસકર્તા સાધનો. તે લગભગ એવું જ છે કે અમે જે ટૂલ્સનો ઉપયોગ કરીએ છીએ તે વેબ પહેલાથી જ શું પ્રદાન કરે છે તે અમૂર્ત કરવા માટે અમે ઉપયોગમાં લઈએ છીએ તે ડિબગ કરવા માટે ટૂલ્સ વિકસાવવાની જરૂર છે - બધું પ્રમાણભૂત CSS લખવાના "પીડા"થી દૂર ભાગવા ખાતર. સદભાગ્યે, આધુનિક CSS સુવિધાઓ માત્ર પ્રમાણભૂત CSSને વધુ લવચીક બનાવતી નથી પણ અમારા જેવા વિકાસકર્તાઓને કાસ્કેડનું સંચાલન કરવા અને તેને અમારા માટે કાર્ય કરવા માટે ઘણી વધારે શક્તિ આપે છે. CSS કાસ્કેડ લેયર્સ એ એક ઉત્તમ ઉદાહરણ છે, પરંતુ બીજી એક વિશેષતા છે જે ધ્યાનની આશ્ચર્યજનક અભાવ મેળવે છે - જો કે તે હવે બદલાઈ રહ્યું છે કારણ કે તે તાજેતરમાં બેઝલાઇન સુસંગત બન્યું છે. સીએસએસ @સ્કોપ એટ-રૂલ હું CSS @scope at-rule ને અમે આવરી લીધેલી શૈલી-લીક-પ્રેરિત અસ્વસ્થતાના સંભવિત ઉપાય તરીકે માનું છું, જે અમને એબ્સ્ટ્રેક્શન્સ અને વધારાના બિલ્ડ ટૂલિંગ માટે મૂળ વેબ લાભો સાથે સમાધાન કરવા દબાણ કરતું નથી. "@સ્કોપ CSS એટ-રૂલ તમને ચોક્કસ DOM સબટ્રીઝમાં તત્વોને પસંદ કરવા સક્ષમ બનાવે છે, ઓવરરાઇડ કરવા મુશ્કેલ હોય તેવા વધુ પડતા-વિશિષ્ટ પસંદગીકારોને લખ્યા વિના અને તમારા પસંદગીકારોને DOM સ્ટ્રક્ચર સાથે ખૂબ જ ચુસ્તપણે જોડ્યા વિના ચોક્કસ રીતે તત્વોને લક્ષ્ય બનાવે છે."- MDN
બીજા શબ્દોમાં કહીએ તો, અમે વારસા, કાસ્કેડિંગ અથવા ચિંતાઓના મૂળભૂત વિભાજનને બલિદાન આપ્યા વિના ચોક્કસ ઉદાહરણોમાં અલગ શૈલીઓ સાથે કામ કરી શકીએ છીએ.જે ફ્રન્ટ એન્ડ ડેવલપમેન્ટનો લાંબા સમયથી ચાલતો માર્ગદર્શક સિદ્ધાંત રહ્યો છે. ઉપરાંત, તેમાં ઉત્તમ બ્રાઉઝર કવરેજ છે. વાસ્તવમાં, Firefox 146 એ ડિસેમ્બરમાં @scope માટે સમર્થન ઉમેર્યું, જે તેને પ્રથમ વખત બેઝલાઇન સુસંગત બનાવે છે. @સ્કોપ નિયમ વિરુદ્ધ BEM પેટર્નનો ઉપયોગ કરીને બટન વચ્ચેની સરળ સરખામણી અહીં છે:
@સ્કોપ નિયમ ઓછી જટિલતા સાથે ચોકસાઇ માટે પરવાનગી આપે છે. વિકાસકર્તાને હવે વર્ગના નામોનો ઉપયોગ કરીને સીમાઓ બનાવવાની જરૂર નથી, જે બદલામાં, તેમને મૂળ HTML ઘટકો પર આધારિત પસંદગીકારોને લખવાની મંજૂરી આપે છે, જેનાથી પ્રિસ્ક્રિપ્ટિવ CSS વર્ગના નામ પેટર્નની જરૂરિયાત દૂર થાય છે. વર્ગ નામ વ્યવસ્થાપનની જરૂરિયાતને ખાલી કરીને, @scope મોટા પ્રોજેક્ટ્સમાં CSS સાથે સંકળાયેલા ભયને દૂર કરી શકે છે. મૂળભૂત ઉપયોગ શરૂ કરવા માટે, તમારા CSSમાં @scope નિયમ ઉમેરો અને રૂટ સિલેક્ટર દાખલ કરો કે જેમાં શૈલીઓને સ્કોપ કરવામાં આવશે: @સ્કોપ (<સિલેક્ટર>) { /* શૈલીઓ <પસંદક> */ માટે વ્યાપિત }
તેથી, ઉદાહરણ તરીકે, જો આપણે
@સ્કોપ (એનએવી) { a { /* નેવી સ્કોપમાં લિંક શૈલીઓ */ }
a:સક્રિય { /* સક્રિય લિંક શૈલીઓ */ }
a:active::before { /* વધારાની સ્ટાઇલ માટે સ્યુડો-એલિમેન્ટ સાથે સક્રિય લિંક */ }
@media (મહત્તમ-પહોળાઈ: 768px) { a { /* રિસ્પોન્સિવ એડજસ્ટમેન્ટ */ } } }
આ, તેના પોતાના પર, એક ગ્રાઉન્ડબ્રેકિંગ લક્ષણ નથી. જો કે, નીચલી સીમા બનાવવા માટે અવકાશમાં બીજી દલીલ ઉમેરી શકાય છે, જે કાર્યક્ષેત્રના પ્રારંભ અને અંતિમ બિંદુઓને અસરકારક રીતે વ્યાખ્યાયિત કરે છે.
/* ul ની અંદરના કોઈપણ તત્વમાં શૈલીઓ લાગુ પડશે નહીં */ @સ્કોપ (nav) થી (ul) { a { ફોન્ટ-સાઇઝ: 14px; } }
આ પ્રથાને ડોનટ સ્કોપિંગ કહેવામાં આવે છે, અને એવા ઘણા અભિગમો છે જેનો ઉપયોગ કરી શકાય છે, જેમાં DOM સ્ટ્રક્ચર સાથે ચુસ્તપણે જોડાયેલા સમાન, અત્યંત ચોક્કસ પસંદગીકારોની શ્રેણી, a :not pseudo-selector, અથવા ભિન્ન CSS ને હેન્ડલ કરવા માટે
/*
નિષ્કર્ષ ઉપયોગિતા-પ્રથમ CSS ફ્રેમવર્ક, જેમ કે Tailwind, પ્રોટોટાઇપિંગ અને નાના પ્રોજેક્ટ્સ માટે સારી રીતે કામ કરે છે. તેમના લાભો ઝડપથી ઘટે છે, જો કે, જ્યારે મોટા પ્રોજેક્ટ્સમાં ઉપયોગ કરવામાં આવે છે જેમાં થોડાક વિકાસકર્તાઓ સામેલ હોય છે. છેલ્લા કેટલાક વર્ષોમાં ફ્રન્ટ-એન્ડ ડેવલપમેન્ટ વધુને વધુ જટિલ બન્યું છે, અને CSS પણ તેનો અપવાદ નથી. જ્યારે @સ્કોપનો નિયમ એ તમામ ઉપાય નથી, તે જટિલ ટૂલિંગની જરૂરિયાતને ઘટાડી શકે છે. જ્યારે વ્યૂહાત્મક વર્ગના નામકરણની જગ્યાએ અથવા તેની સાથે ઉપયોગમાં લેવામાં આવે છે, ત્યારે @scope જાળવવા યોગ્ય CSS લખવાનું સરળ અને વધુ મનોરંજક બનાવી શકે છે. વધુ વાંચન
CSS @scope (MDN) “CSS @scope”, જુઆન ડિએગો રોડ્રિગ્ઝ (CSS-યુક્તિઓ) ફાયરફોક્સ 146 પ્રકાશન નોંધો (ફાયરફોક્સ) બ્રાઉઝર સપોર્ટ (CanIUse) લોકપ્રિય CSS ફ્રેમવર્ક (CSS 2024ની સ્થિતિ) CSS માં "C": કાસ્કેડ", થોમસ યીપ (CSS-યુક્તિઓ) BEM પરિચય (BEM મેળવો)
