ძირითადი CSS-ის პრინციპების შესწავლისას ადამიანს ასწავლიან მოდულარული, მრავალჯერადი გამოყენების და აღწერითი სტილის დაწერას, რათა უზრუნველყოს შენარჩუნების უნარი. მაგრამ როდესაც დეველოპერები ჩაერთვებიან რეალურ სამყაროში არსებულ აპლიკაციებში, ხშირად შეუძლებელი ხდება ინტერფეისის ფუნქციების დამატება არასასურველ ადგილებში სტილის გაჟონვის გარეშე. ეს საკითხი ხშირად თოვლის ბურთებში გადადის თვითშესრულების მარყუჟში; სტილები, რომლებიც თეორიულად ერთ ელემენტს ან კლასს მოიცავს, ჩნდება იქ, სადაც მათ არ ეკუთვნის. ეს აიძულებს დეველოპერს შექმნას კიდევ უფრო სპეციფიკური სელექტორები გაჟონილი სტილების უგულებელყოფისთვის, რომლებიც შემდეგ შემთხვევით არღვევენ გლობალურ სტილებს და ა.შ. ხისტი კლასის სახელების კონვენციები, როგორიცაა BEM, არის ამ საკითხის ერთი თეორიული გადაწყვეტა. BEM (Block, Element, Modifier) მეთოდოლოგია არის CSS კლასების დასახელების სისტემატური გზა CSS ფაილებში ხელახალი გამოყენებისა და სტრუქტურის უზრუნველსაყოფად. მსგავსი კონვენციების დასახელებამ შეიძლება შეამციროს შემეცნებითი დატვირთვა დომენის ენის გამოყენებით ელემენტებისა და მათი მდგომარეობის აღსაწერად და თუ სწორად განხორციელდა, შეუძლია გააადვილოს დიდი აპლიკაციების სტილის შენარჩუნება. თუმცა რეალურ სამყაროში ეს ყოველთვის ასე არ გამოდის. პრიორიტეტები შეიძლება შეიცვალოს და ცვლილებებით, განხორციელება ხდება არათანმიმდევრული. HTML სტრუქტურის მცირე ცვლილებებმა შეიძლება მოითხოვოს CSS კლასის მრავალი სახელის გადახედვა. უაღრესად ინტერაქტიული წინა აპლიკაციებით, კლასების სახელები, რომლებიც მიჰყვება BEM შაბლონს, შეიძლება გახდეს გრძელი და მოუხერხებელი (მაგ., app-user-overview__status--is-autenticating) და დასახელების წესების სრულად შეუსრულებლობა არღვევს სისტემის სტრუქტურას, რითაც უარყოფს მის სარგებელს. ამ გამოწვევების გათვალისწინებით, გასაკვირი არ არის, რომ დეველოპერები მიმართავენ ფრეიმვეზებს, Tailwind არის ყველაზე პოპულარული CSS ჩარჩო. იმის ნაცვლად, რომ სცადოთ ბრძოლა, როგორც ჩანს, დაუმარცხებელი სპეციფიურობის ომი სტილებს შორის, უფრო ადვილია უარი თქვათ CSS კასკადზე და გამოიყენოთ ინსტრუმენტები, რომლებიც უზრუნველყოფენ სრულ იზოლაციას. დეველოპერები უფრო მეტად ეყრდნობიან კომუნალურ მომსახურებას როგორ ვიცით, რომ ზოგიერთ დეველოპერს სურს თავიდან აიცილოს კასკადური სტილი? ეს არის "თანამედროვე" წინა ინსტრუმენტების აღზევება - როგორიცაა CSS-in-JS ჩარჩოები - შექმნილია სპეციალურად ამ მიზნით. იზოლირებულ სტილებთან მუშაობა, რომლებიც მჭიდროდ არის მორგებული კონკრეტულ კომპონენტებთან, შეიძლება სუფთა ჰაერის სუნთქვას ჰგავს. ის ხსნის ნივთების დასახელების აუცილებლობას - ჯერ კიდევ ერთ-ერთი ყველაზე საძულველი და შრომატევადი ფრონტ-ენდის ამოცანა - და საშუალებას აძლევს დეველოპერებს იყვნენ პროდუქტიულები CSS მემკვიდრეობის უპირატესობების სრულად გაგების ან გამოყენების გარეშე. მაგრამ CSS კასკადის გათიშვა თავისი პრობლემებით მოდის. მაგალითად, JavaScript-ში სტილის შედგენა მოითხოვს მძიმე კონსტრუქციის კონფიგურაციას და ხშირად იწვევს სტილის უხერხულ შერევას კომპონენტის მარკირებასთან ან HTML-თან. დასახელების კონვენციების გულდასმით განხილვის ნაცვლად, ჩვენ ვუშვებთ Build ინსტრუმენტებს სელექტორებისა და იდენტიფიკატორების ავტომატური გენერირებისთვის ჩვენთვის (მაგ., .jsx-3130221066), რაც მოითხოვს დეველოპერებს, რომ დაიცვან კიდევ ერთი ფსევდოენა თავისთავად. (თითქოს შემეცნებითი დატვირთვა იმის გაგებით, თუ რას აკეთებს თქვენი კომპონენტის გამოყენების ეფექტები, უკვე საკმარისი არ იყო!) კლასების ინსტრუმენტად დასახელების სამუშაოს შემდგომი აბსტრაქცია ნიშნავს, რომ ძირითადი გამართვა ხშირად შემოიფარგლება აპლიკაციის კონკრეტული ვერსიებით, რომლებიც შედგენილია განვითარებისთვის, ვიდრე ბრაუზერის მშობლიური ფუნქციების გამოყენება, რომლებიც მხარს უჭერენ ცოცხალ გამართვას, როგორიცაა Developer Tools. ეს თითქმის ისეა, როგორც ჩვენ გვჭირდება ინსტრუმენტების შემუშავება იმ ინსტრუმენტების გამართვისთვის, რომლებსაც ვიყენებთ აბსტრაქტულად, რასაც ვებ უკვე გვაწვდის – ეს ყველაფერი იმისთვის, რომ თავი დააღწიოთ სტანდარტული CSS-ის დაწერის „ტკივილს“. საბედნიეროდ, თანამედროვე CSS ფუნქციები არა მხოლოდ სტანდარტული CSS-ის წერას უფრო მოქნილს ხდის, არამედ ჩვენს მსგავს დეველოპერებსაც აძლევს დიდ ძალას, მართონ კასკადი და ის ჩვენთვის იმუშაონ. CSS კასკადის ფენები შესანიშნავი მაგალითია, მაგრამ არის კიდევ ერთი ფუნქცია, რომელიც იწვევს გასაოცარ ყურადღების ნაკლებობას – თუმცა ის ახლა იცვლება, როდესაც ის ახლახან გახდა საბაზისო თავსებადი. CSS @scope At-Rule მე მიმაჩნია, რომ CSS @scope at-rule არის პოტენციური განკურნება იმ ტიპის სტილის გაჟონვით გამოწვეული შფოთვისთვის, რომელიც ჩვენ განვიხილეთ, რომელიც არ გვაიძულებს კომპრომისზე წავიდეს მშობლიური ვებ უპირატესობები აბსტრაქციებისთვის და დამატებითი კონსტრუქციის ინსტრუმენტებისთვის. "@scope CSS at-rule გაძლევთ საშუალებას აირჩიოთ ელემენტები კონკრეტულ DOM ქვეხეებში, მიზნად ისახავდეს ელემენტებს ზუსტად ისე, რომ არ დაწეროთ ზედმეტად სპეციფიკური სელექტორები, რომლებიც ძნელია გადალახვა, და თქვენი სელექტორების ძალიან მჭიდროდ შეერთების გარეშე DOM სტრუქტურასთან." - MDN.
სხვა სიტყვებით რომ ვთქვათ, ჩვენ შეგვიძლია ვიმუშაოთ იზოლირებულ სტილებთან კონკრეტულ შემთხვევებში, მემკვიდრეობის, კასკადის ან თუნდაც პრობლემების ძირითადი გამიჯვნის გარეშე.ეს იყო წინა მხარის განვითარების გრძელვადიანი სახელმძღვანელო პრინციპი. გარდა ამისა, მას აქვს ბრაუზერის შესანიშნავი დაფარვა. ფაქტობრივად, Firefox 146-მა დაამატა მხარდაჭერა @scope-ს დეკემბერში, რამაც იგი პირველად გახადა Baseline თავსებადი. აქ არის მარტივი შედარება ღილაკს შორის BEM შაბლონის გამოყენებით @scope წესის წინააღმდეგ:
<სტილი> .button .button__text { /* ღილაკის ტექსტის სტილები */ } .button .button__icon { /* button icon styles */ } .button--primary { ძირითადი ღილაკის სტილები */ }
<სტილი> @scope (.primary-button) { span:first-child { /* ღილაკის ტექსტის სტილები */ } span:last-child { /* ღილაკის ხატულის სტილები */ } }
@scope წესი იძლევა სიზუსტეს ნაკლები სირთულით. დეველოპერს აღარ სჭირდება საზღვრების შექმნა კლასების სახელების გამოყენებით, რაც, თავის მხრივ, საშუალებას აძლევს მათ დაწერონ სელექტორები მშობლიური HTML ელემენტების საფუძველზე, რითაც აღმოფხვრილია CSS კლასის დანიშნულების შაბლონების საჭიროება. კლასის სახელების მართვის საჭიროების მოხსნით, @scope-ს შეუძლია შეამსუბუქოს CSS-თან დაკავშირებული შიში დიდ პროექტებში.
ძირითადი გამოყენება
დასაწყებად, დაამატეთ @scope წესი თქვენს CSS-ს და ჩასვით root ამომრჩეველი, რომელზედაც სტილები იქნება მორგებული:
@scope (
ასე რომ, მაგალითად, თუ ჩვენ გვსურს გავაფართოვოთ სტილები
@scope (nav) { a { /* ბმულის სტილის ნავიგაციის ფარგლებში */ }
a:active { /* აქტიური ბმულის სტილები */ }
a:active::fore { /* აქტიური ბმული ფსევდოელემენტით დამატებითი სტილისთვის */ }
@media (მაქს. სიგანე: 768 პიქსელი) { a { /* საპასუხო კორექტირება */ } } }
ეს, თავისთავად, არ არის ინოვაციური თვისება. თუმცა, მეორე არგუმენტი შეიძლება დაემატოს საზღვრებს ქვედა საზღვრის შესაქმნელად, რაც ეფექტურად განსაზღვრავს სფეროს საწყისი და საბოლოო წერტილებს.
/* ul-ის შიგნით არსებულ ნებისმიერ ელემენტს არ ექნება გამოყენებული სტილები */ @scope (nav) to (ul) { a { შრიფტის ზომა: 14px; } }
ამ პრაქტიკას ჰქვია დონატ სკოპინგი და არსებობს რამდენიმე მიდგომა, რომელიც შეიძლება გამოვიყენოთ, მათ შორისაა მსგავსი, ძალიან სპეციფიკური სელექტორების სერია, რომლებიც მჭიდროდ არის დაკავშირებული DOM სტრუქტურასთან, :არა ფსევდო-სელექტორი, ან ელემენტების
დასკვნა Utility-first CSS Frameworks, როგორიცაა Tailwind, კარგად მუშაობს პროტოტიპებისა და მცირე პროექტებისთვის. თუმცა, მათი სარგებელი სწრაფად მცირდება, როდესაც გამოიყენება უფრო დიდ პროექტებში, რომელშიც მონაწილეობს რამდენიმე დეველოპერი. ფრონტ-ენდის განვითარება სულ უფრო მეტად რთულდება ბოლო რამდენიმე წლის განმავლობაში და CSS არ არის გამონაკლისი. მიუხედავად იმისა, რომ @scope წესი არ არის ყველაფრის განკურნება, მას შეუძლია შეამციროს რთული ხელსაწყოების საჭიროება. როდესაც გამოიყენება კლასის სტრატეგიული დასახელების ნაცვლად ან ერთად, @scope-ს შეუძლია გააადვილოს და უფრო სახალისო გახადოს შენარჩუნებული CSS. შემდგომი კითხვა
CSS @scope (MDN) "CSS @scope", ხუან დიეგო როდრიგესი (CSS-Tricks) Firefox 146-ის გამოშვების შენიშვნები (Firefox) ბრაუზერის მხარდაჭერა (CanIUse) პოპულარული CSS Frameworks (CSS 2024) "C" CSS-ში: კასკადი", თომას იიპი (CSS-Tricks) BEM შესავალი (მიიღეთ BEM)
