Share
Nog niet zo lang geleden hadden we een blik op The Basics of LESS en, hoewel dit een solide referentie is voor beginners, is er veel meer dat je kunt doen met MINDER! Het doel van deze tutorial is om de kennis uit het vorige artikel verder uit te diepen en enkele praktische tips te geven over het gebruik van alle geweldige dingen over MINDER.
De concepten in het vorige artikel zijn essentieel om deze niet te kunnen lezen. Variabelen, mixins, functies en het nesting in MINDER moeten allemaal bekend zijn en je moet op zijn minst enige kennis hebben van MINDER.
Notitie: er is een behoorlijk aantal subjectieve adviezen in dit artikel. Veel dingen die we zullen bespreken hebben te maken met methodologie in tegenstelling tot regels en voorschriften van een taal. Ik zal je laten zien hoe ik bestanden orden en mixins maak, maar er kunnen andere, betere manieren zijn om dingen te doen. Als je denkt dat je een betere structuur gebruikt, of als je zelf wat tips en trics hebt, laat het dan los in de comments.
Het organiseren van uw bestanden is altijd uiterst belangrijk, zeker ook voor MINDER. Ik maak meestal een map 'styles' in mijn hoofdprojectdirectory waarin ik alle stijlen opsla die voor dat project zijn vereist. Dus wat gebeurt er als uw project vereist dat u css-bestanden opneemt van meerdere locaties?
De beste manier om uw leven gemakkelijk te maken, is door een tool als Winless of CodeKit te gebruiken. Met deze hulpmiddelen kunt u verschillende bestanden naar verschillende locaties compileren. Op deze manier kunt u al uw stijlbestanden op één locatie bewaren terwijl u ze naar verschillende mappen in uw projecten compileert.
Zoals u kunt zien, is in dit WordPress-project het gemarkeerde 'style.less'-bestand opgenomen in de map' styles '. Omdat WordPress een 'style.css'-bestand in de hoofddirectory nodig heeft, moeten we het daar compileren. CodeKit of een vergelijkbare tool maakt dit gemakkelijk, omdat je het maar één keer hoeft in te stellen en dan kun je het vergeten tot het einde van het project.
Een ander probleem dat zich kan voordoen met CSS-bestanden is hoe om te gaan met bestanden van derden. Rastersystemen, stijlen voor JavaScript-schuifregelaars, resets en meer vereisen het gebruik van (soms meerdere) CSS-bestanden. Er zijn meestal twee methoden om dit te laten gebeuren. Ofwel koppelt u de bestanden afzonderlijk aan uw webpagina, of plaatst u alle code in één bestand en minimaliseert u deze voor prestatiedoeleinden. Met een LESS-compiler-tool wordt dit weer gemakkelijker!
Met behulp van importregels kunt u alle bestanden naar uw belangrijkste LESS-stylesheet slepen. U kunt ook minder bestanden importeren, waardoor hun regels, mixins en andere elementen bruikbaar zijn in alle volgende bestanden.
Notitie: Hoewel deze methode nuttig is, is het geen universele oplossing. In sommige gevallen moet u mogelijk alle bestanden afzonderlijk opnemen, in andere gevallen kan het best alles in één bestand opnemen.
Het grootste probleem met CSS is het extreme gebrek aan consistentie in bijna alle projecten. Deze situatie komt meestal voort uit de aard van de taal zelf, niet noodzakelijk uit de onbekwaamheid van de programmeur. CSS is een zeer losse en vergevingsgezinde taal, wat betekent dat het configuratie via conventie bevordert, terwijl andersom de voorkeur heeft. Bovendien wordt CSS nog meer procedureel dan normaal gecodeerd, wat betekent dat wereldwijde patronen niet altijd zo eenvoudig worden opgemerkt en geïmplementeerd als ze zouden kunnen zijn..
Hoewel LESS geen cureall is, kun je veel consistenter zijn door je tools zoals functies en nesten te geven. Laten we een paar voorbeelden bekijken waarin u betere consistentie kunt bereiken met MINDER tools.
.radius (@radius: 5px) -webkit-border-radius (@radius); -khtml-border-radius (@radius); -moz-border-radius (@radius); -ie-border-radius (@radius); -o-border-radius (@radius); grensradius (@radius);
Zonder MINDER zou je deze regels moeten kopiëren als dat nodig is. Veel mensen schrijven gewoon wanneer ze gaan, dus het is veel waarschijnlijker dat u een van de voorvoegsels zou vergeten of ze in een andere volgorde zou schrijven. Hoewel dit geen dealbreakers voor uw website zijn, voegt elke kleine inconsistentie onnodige ruis toe aan uw code.
Het nestbare karakter van regels geeft je ook de kans om je code aan te vullen. Ik probeer zo min mogelijk divs en andere containerelementen te gebruiken en probeer elk element zo specifiek mogelijk te targeten
.commentaarlijst .comment .comment-date .comment-time color: # 888;
Dit lijkt in eerste instantie een beetje overbodig en ik ben het ermee eens, in zekere zin is het dat wel. Het maakt alles echter super duidelijk.
Het nut hiervan zal alleen duidelijk zijn als je het in een groter project gebruikt, maar hier is een snel fragment dat laat zien hoe een reactie responsief is gemaakt. Onder een specifieke breedte is het tijdsgedeelte van de reactiedatum verborgen om ruimte te besparen.
@media-scherm en (max. breedte: 600px) .commentlist .comment-container .comment-main .comment-header .comment-date . time display: none;
Ik ben het ermee eens dat dit er vreselijk uitziet. Er is echter niet nagedacht over het creëren van de regel. Geen nadenken betekent eenvoudig terugreizen, omdat je geen slimme trucs hoeft uit te vinden die je onderweg hebt toegevoegd. Ook kun je vertellen wat deze regel doet door ernaar te kijken.
Mijn laatste argument voor consistentie is een complexere, maar ik denk dat het de moeite waard is om ernaar te kijken. Ik bouw WordPress-thema's te koop op ThemeForest en een functie is dat je elke kleur voor je thema kunt kiezen. Elementen worden opnieuw gekozen naar keuze. De manier waarop dit wordt gedaan, is dat telkens wanneer een 'primaire kleur' wordt gedefinieerd, deze wordt overschreven met dynamische CSS-code die we met PHP uitvoeren. Dit ziet er ongeveer zo uit:
Inhoud van ons LESS-bestand:
@ color-primary: red; .button background: @ color-primary; opvulling: 8px 20px;
Inhoud van een PHP aan het einde van de HTML-header:
Kortom, wanneer er een verwijzing is naar '@ color-primary' in het LESS-bestand, moeten we een PHP-regel maken om ervoor te zorgen dat de door de gebruiker gekozen kleuren worden weergegeven op de site. Dit kan een tijdje duren en wat nog belangrijker is uiterst saai. Om de verveling te bestrijden, maken we een script dat ons LESS-bestand parseert en de PHP-code maakt die we in één keer kunnen kopiëren en plakken. Dit is een beetje moeilijk omdat er enkele dynamische regels zijn met functies en zo niet, maar om dit te voorkomen moet ons LESS-bestand goed gestructureerd en consistent zijn.
Een geweldige tijdwinst en een manier om de consistentie tussen projecten te vergroten, is door een gemeenschappelijke bibliotheek met regels te gebruiken. Eerder vroeg ik; waarom schrijf je alle grensstraalregels uit wanneer we een mixin kunnen gebruiken? Nu kunnen we een niveau hoger springen. Waarom de grensradiusmixin voor elk project herschrijven wanneer u dezelfde kunt gebruiken?
Er zijn een aantal mixins (vooral degene die leverancierspecificaties aanpakken) die voor alle projecten hetzelfde zullen zijn. Deze kunnen worden gescheiden in een 'mixins.less'-bestand dat u overal kunt gebruiken. Hier zijn enkele voorbeelden van mixins die altijd handig zijn om rond te hebben.
.opacity (@opacity: 0.8) @ieopacity: @opacity * 100; filter: ~ "alpha (opacity = @ ieopacity)"; -khtml-dekking: @opacity; -moz-opacity: @opacity; dekking: @opacity;
.gradient (@start, @end) background: @start; filter: ~ "progid: DXImageTransform.Microsoft.gradient (startColorstr =" @ start ", endColorstr =" @ end ", GradientType = 0)"; achtergrond: -webkit-gradiënt (lineair, linker boven, links onder, kleur-stop (0%, @ start), kleur-stop (100%, @ einde)); achtergrond: -webkit-lineaire gradiënt (boven, @start 0%, @end 100%); achtergrond: -moz-linear-gradient (boven, @start 0%, @end 100%); achtergrond: -ms-lineaire gradiënt (boven, @start 0%, @end 100%); achtergrond: -o-lineaire gradiënt (bovenkant, @start 0%, @end 100%); achtergrond: lineair verloop (boven, @ start 0%, @end 100%);
.element-kleur (@color) wanneer (lichtheid (@color)> = 60%) color: @color - # 888; .element-color (@color) when (lichtheid (@color) < 60% ) color: #fff;
Deze laatste is vooral cool. Als de achtergrondkleur licht is, is de tekstkleur een erg donkere versie van dezelfde kleur.
Ik stel voor om altijd na te denken over de plaatsing van de regel die u schrijft. Weet je zeker dat het wereldwijd wordt gebruikt voor alle projecten? Het is misschien verleidelijk om daar heel wat regels in te zetten, maar in werkelijkheid kan het beter zijn om ook een projectspecifiek bestand aan te maken.
Weet je nog eerder het plaatje van de opmerking? De container van dat element heeft een specifiek formaat. Het heeft een witte rand en een grijze omtrek. Veel andere elementen in dit thema delen dit patroon. Dit kan worden gemaakt met een regel zoals:
.box border: 1px solid #fff; outline: 1px solid #dedede; .comment .box; achtergrond: #eeeeee;
Terwijl dit is hier overal gebruikt, zal het niet hetzelfde zijn voor meerdere projecten. Daarom zou het beter zijn om een bestand aan te maken als 'mytheme.less' dat deze veel gebruikte, maar themaspecifieke regels bevat. Als je echt iets als in het globale bestand wilt gebruiken, zou je het als volgt kunnen uitbreiden:
.box-bounded (@ border-color: #fff, @ outline-color: #dedede) border: 1px solid @ border-colour; outline: 1px solid @ outline-kleur;
Met deze regel kunt u dezelfde kaderstijl net zo eenvoudig maken, maar u kunt ook parameters toevoegen om doosvakken met verschillend gekleurde randen te maken. Je kunt dit nog een stap verder doen door nog meer dingen te abstraheren en een 'bootstrap.less'-bestand te maken; dit brengt ons mooi bij ons volgende onderwerp, het creëren van een raamwerk voor onszelf.
@ border-box-border-colour: #fff; @ border-box-outline-color: #edede;
.box-bounded (@bc: @ border-box-border-colour, @oc: @ border-box-outline-colour) border: 1px solid @bc; overzicht: 1px solid @oc;
Je eigen framework maken is meestal een no-no, tenzij je erg geavanceerd bent in je hoofdveld (en 5-6 anderen) en daar heb je heel goede redenen voor. Met CSS en LESS is het een beetje anders; je kunt vanaf dag één beginnen met het maken van je eigen frame. Omdat LESS een superset van CSS is, past alles wat je doet netjes in de bestaande code. Omdat CSS vergevingsgezind en trager verloopt, kun je geen permanente schade aanrichten die niet ongedaan kan worden gemaakt.
Ik stel voor om eerst een 'mixins' bestand te maken. Je kunt er altijd dingen uit verwijderen of er waar nodig aan toevoegen. Later kunt u projectspecifieke bestanden, externe bestanden, een bootstrap-bestand enzovoort toevoegen. Dit is hoe mijn framework is georganiseerd.
Zoals met elke taal, bevatten de praktische aspecten van coderen veel verschillende uitdagingen en technieken die niet kunnen worden ontdekt en overwonnen door alleen naar documentatie te kijken. Om LESS volledig te gebruiken, moet je suggesties lezen en de logica proberen op te nemen, maar uiteindelijk zul je ervaring moeten opdoen. Consistentie, logica en eenvoud moeten uw leidende woorden zijn en LESS biedt u alle tools om dit te bereiken.
Tot slot zou ik uw input toejuichen en zou ik graag horen hoe u LESS organiseert en hoe u het in uw projecten implementeert. Bedankt voor het lezen!
Accentsconagua