Met de laatste tijd dat ik eindelijk CSS Grid kon gebruiken, moest ik denken: welke andere fantastische CSS-functies kan ik nu gebruiken? CSS-variabelen waren diegene die onmiddellijk voor de geest kwamen.
Het is al een tijdje geleden dat ik iets over CSS-variabelen heb gehoord en het voegt een hele nieuwe toolset en manier van denken toe aan de front-end ontwikkeling die me prikkelt.
CSS-variabelen kloppen al een paar jaar, maar lijken niet veel gebruikt te worden. Met de populariteit van pre-processors zoals Sass, kraakten ontwikkelaars van de frontend die variabele lang geleden.
Ik was voor het eerst enthousiast over CSS-variabelen in 2014 en sindsdien zijn ze ondergedompeld in en uit mijn interessegebied. Ik overweeg nu alleen om ze in productiesites te krijgen en ik zal je laten zien hoe eenvoudig en gemakkelijk ze te gebruiken zijn.
Het declareren van de aangepaste eigenschap is eenvoudig: we hoeven alleen de eigenschap te maken die we willen en twee streepjes aan het begin toe te voegen. Deze kunnen overal worden gedeclareerd maar door ze toe te voegen: root lijkt op dit moment een goede aanpak.
--my-reusable-value: 20px;Het gebruik van de woning is ook vrij eenvoudig. We benaderen het via de var () -functie en gebruiken de eigenschap die we hierboven hebben aangegeven.
padding: var(--my-reusable-value);Is dat niet eenvoudig en glorieus?
CSS-variabelen zijn eenvoudig te gebruiken en vrij gemakkelijk te onthouden. De grootste uitdaging met CSS-variabelen (zoals bij de meeste CSS) is het kennen van de juiste tijd en plaats om ze te gebruiken. Als ze lukraak worden weggegooid, is een zekere manier om een knoeiboel van een stylesheet te maken en met deze variabelen die in het debuggen worden gegooid, zal het waarschijnlijk moeilijker worden.
Juiste gebruiksgevallen en strategieën om ze te gebruiken, moeten worden overwogen en dit is waar het grootste deel van uw inspanningen op gericht moet zijn.
In het volgende voorbeeld laat ik een eenvoudig voorbeeld zien van hoe ik momenteel een responsieve component bouw met Sass-variabelen. Vervolgens laat ik je zien hoe het kan worden verbeterd met CSS-variabelen op een manier die niet mogelijk is met een pre-processor. Dit is een specifieke use-case die niet van toepassing is op alle variabelen die worden gebruikt, maar die aangeeft hoe CSS-variabelen anders kunnen worden gebruikt.
Zie de pen CSS-variabelen - responsief gebruik zonder CSS-variabelen door Adam Hughes ( @lostmybrain ) aan CodePen .
Bij het gebruik van Sass zijn er een paar verschillende methodologieën die ik heb geprobeerd. Mijn huidige versie gaat over het plaatsen van mediaquery's binnen de CSS-blokken die ik wil wijzigen. Hier kan ik een variabele, standaard CSS, mixin of een uitbreiding gebruiken om dit element te wijzigen zonder de stijlen voor de component overal te verspreiden.
Een probleem hierbij is het hebben van meerdere mediaquery's en veel variabelen die verwant zijn maar niet. Ik zou kaarten kunnen gebruiken voor de variabelen die meer organisatie zouden geven, maar ik denk dat het belangrijkste probleem is dat we een meervoudige variabelen gebruiken om één eigenschap te definiëren. Dit voelt gewoon verkeerd.
Sass-variabelen worden van tevoren gebruikt, wat betekent dat we elke manier moeten plannen waarop we ze gaan gebruiken. Ze maken het ontwikkelen eenvoudiger maar leveren technisch gezien geen nieuwe superkrachten op.
Zie de pen CSS-variabelen - responsief gebruik door Adam Hughes ( @lostmybrain ) aan CodePen .
CSS-variabelen hoeven niet vooraf te worden gedeclareerd, ze zijn dynamisch. Dit is op een heel andere manier nuttig. We kunnen nu voorwaardelijk variabelen van overal en in specifieke contexten wijzigen, zoals mediaquery's.
Door onze mediaquerystijlen direct in te zetten, kunnen we het aantal verspreide mediaquery's reduceren voor responsieve styling. Het geeft ook een heel mooie en schone manier om algemene spatiëring en typografie te bekijken in verschillende formaten.
Ik denk dat responsieve ontwerpen en thema's twee uitstekende use cases zijn voor CSS-variabelen, maar er zijn zoveel mogelijkheden.
Sass-variabelen en CSS-variabelen zijn twee verschillende beesten, elk met hun eigen voor- en nadelen.
Vanwege de populariteit van Sass en de meer programmatische aard van Sass, zijn diepere organisatiepatronen in de loop van de tijd geëvolueerd. Ik hou vooral van sass-kaarten en het combineren van vergelijkbare typevariabelen in de kaarten. Kleuren, formaten en snelkoppelingen voor paden lijken populaire keuzes voor het opnemen in kaarten.
Vanwege het relatief kleinere gebruik van CSS-variabelen moeten de beste praktijken nog evolueren. Kaarten en matrices zijn niet op dezelfde manier mogelijk in CSS, dus deze nieuwe organisatiepatronen moeten innovatief zijn en de problemen op een andere manier oplossen dan Sass.
CSS-variabelen worden tijdens runtime dynamisch behandeld door de browser, terwijl Sass-variabelen worden gebruikt wanneer de CSS wordt gecompileerd.
Dit is het belangrijkste verkoopargument van CSS-variabelen voor mij. Het zal interessant zijn om te zien hoe mensen deze functie in de loop van de tijd gebruiken en of deze functie zijn potentieel zal waarmaken.
Ik ben persoonlijk van mening dat hoe meer dingen we uit Webpack , Gulp en wat dan ook kunnen verwijderen - nieuw-framework-is-out-nu , hoe beter. Dankzij interessante nieuwe browserfuncties hoeven we niet afhankelijk te zijn van compilatie- en JavaScript-frameworks om dingen te doen waarvan ontwikkelaars denken dat ze essentieel zijn. Ik zou een gok wagen dat een hoog percentage van de ontwikkelaars van frontends variabelen in hun CSS gebruiken op een of andere manier, dus iedereen die dit een kernfunctie gebruiken lijkt een verstandige manier om te doen. Het betekent één ding minder in de bouwstap (waarvan ik denk dat we er allemaal mee eens kunnen zijn dat het behoorlijk immens wordt deze dagen) en meer consistentie op het web.
De ondersteuning ziet er opmerkelijk goed uit met één opvallende uitzondering: IE 11. De meeste moderne browsers ondersteunen CSS-variabelen met Edge met een paar bugs.
Bij 78,11% is dit hoger dan CSS Grid (op het moment van schrijven) maar dat IE11-ondersteuning een probleem zou kunnen zijn.
Ik denk dat de tijd nu rijp is. Die IE11-ondersteuning zal niet beter worden en we weten uit eerdere versies van Windows dat het voor sommige mensen erg lang duurt om te upgraden. Maar de ondersteuning in moderne browsers is geweldig, wat betekent dat we moeten kijken naar CSS-variabelen en experimenteren met de mogelijkheden.
Dat betekent echter niet dat we onze verantwoordelijkheid voor oudere browserondersteuning niet mogen vergeten. Een basis fallback-systeem met behulp van een ondersteuningstag, of zelfs een polyfill, voor oudere browsers moet worden overwogen, des te meer als uw daadwerkelijke sitegebruik veel scheverer is voor oudere browsers.
Het is een opwindende tijd voor de ontwikkeling van de front-end en ik kan niet wachten om meer van deze technologieën in mijn productiesites te gebruiken.