Share
"Ik haat de console, ik doe geen Ruby en ik geef niet om variabelen. Waarom zou ik in de wereld Sass moeten leren?" Stoppen met fafferen en luisteren ...
Je kent Sass al! Jawel.
Sass heeft precies dezelfde syntaxis als CSS. Toeval? Nee. Sass is zo gebouwd dat ontwerpers zoals jij het gemakkelijk kunnen oppakken en alle extra voordelen in hun eigen tempo leren, als zij willen.
Toen ik Sass voor het eerst zag, draaide ik zodra ik het woord 'terminal' had de andere kant op. Het is niet dat ik bang ben voor de terminal, het is een zeer nuttige tool en ik gebruik het (wanneer absoluut noodzakelijk) al jaren, maar ik verkies simpelweg een gebruikersinterface. Als er geen gebruikersinterface is, zal ik deze niet gebruiken.
Raad eens? Ik kwam erachter dat er verschillende opties zijn.
Ik heb CodeKit gebruikt sinds het in Beta was. In al die tijd heb ik de terminal voor Sass ongeveer drie keer gebruikt en dat had ik ook helemaal kunnen vermijden.
Dus je houdt niet van variabelen. En waarom zou je in vredesnaam tijd moeten besteden aan het omwikkelen van mixins, functies en al die jazz? Nou, dat doe je niet. Sass gaat je daarvoor niet straffen. Ik kan je echter beloven dat je, zelfs met je puurste bedoelingen, merkt dat je ze vroeg of laat gebruikt. Niet omdat je zou moeten, maar omdat je het wilt. Hetzelfde geldt voor mixins.
Zelfs als je nooit, ooit een enkele Sass-functie of een mixin gaat schrijven, ga je ze uiteindelijk toch gebruiken, omdat je steeds meer kaders zult vinden die het zware werk voor je doen, waardoor je van dat werk kunt profiteren. door een mixin te gebruiken.
Dus laten we ons voorstellen dat je normalize.css wilt gebruiken voor je volgende project. Hoe ga je dat doen? Voeg nog een koppelingstag toe aan uw HTML? Of misschien gewoon een @importeren verklaring in uw CSS? In beide gevallen voegt u extra HTTP-verzoeken toe; misschien niet zo'n grote deal, maar het is niet optimaal en geen beste manier van werken.
Je kunt gewoon de inhoud van normaliseren kopiëren en in je stylesheet plakken, maar ineens wordt je CSS-bestand een puinhoop en ben je nog niet eens aan je project begonnen! Wat gaat u dan doen als normalize.css-updates? Kopieer en plak alles opnieuw?!
In Sass zou je gewoon de goede ol kunnen gebruiken @importerenstatement en laat Sass je normalize.css naar je stylesheet.css slepen (je zou de bestanden in plaats daarvan moeten hernoemen naar .scss, maar nogmaals - geen big deal).
DRY (Do not Repeat Yourself) -principes worden vaak in de echte programmeertalen genoemd, maar er is geen reden waarom ze in CSS enigszins niet zouden worden toegepast. Was dat niet de reden waarom CSS in de eerste plaats werd uitgevonden? In plaats van stijlen steeds opnieuw in uw HTML op te geven, kunt u ineens een klassenaam maken en al uw stijlen daar aangeven.
Zodra u echter begint met het importeren van door anderen gemaakte codes (zoals frameworks, resets, enz.), Zult u waarschijnlijk iets herhalen.
Normalize.css stelt bijvoorbeeld het standaardlettertype in op "sans-serif". Ik vind het leuk, het is een goede standaard. Maar wat als we een aangepast lettertype willen gebruiken? Moeten we normalize.css bewerken? En wat als normaliseren is bijgewerkt? We zullen het allemaal opnieuw moeten doen.
Uiteindelijk gebruiken we waarschijnlijk @import in CSS.
Nu moeten we er gewoon voor zorgen dat we onze normalisatie opnemen bovenaan ons stylesheet en we zijn goed om te gaan. We overschrijven de lettertypefamilie, maar laten we er zeker voor zijn dat we een klapje maken !belangrijk verklaring op het einde, toch? Fout!
Helaas is normalize.css nog niet in Sass geschreven, maar er zijn goede mensen die normalized.css naar Sass hebben geconverteerd, wat je gewoon in je CSS kunt gebruiken. Bijvoorbeeld:
$ font-family: "Comic Sans";
Natuurlijk zou je Normalize 2.0.1+ al moeten gebruiken, wat geen lettertype-familieverklaring meer bevat, maar dit was meer een illustratie van het probleem en de oplossing ervoor.
CSS is een evoluerende taal. Als u nog steeds denkt dat variabelen slecht zijn, overweeg dan deze CSS-specificatie, die het volgende voorbeeld biedt:
: root var-header-color: # 06c; h1 achtergrondkleur: var (koptekstkleur);
Nou, als dat geen lelijke versie van een variabele is, weet ik niet wat het is!
Het punt is dat CSS een taal is die evolueert, dus zelfs als je pre-processors negeert zo lang als je kunt, zal er in de toekomst een punt zijn waar je hoe dan ook gedwongen zult worden om variabelen te leren. Mijn advies is om voorop te blijven lopen en dingen zoals variabelen al snel goed te keuren!
En het zijn niet alleen de variabelen! Sass en andere preprocessors hebben een grote invloed op de toekomstige CSS-specificaties. Hier is nog een specificatie in ontwikkeling, die CSS-code zal nesten in de toekomst. Het ziet er ongeveer zo uit:
/ * In het volgende voorbeeld wordt Hiërarchieën gebruikt: * / div, p & .keyword color: green; font-size: 10px; & .constant color: red; &: hover: after content: "[" attr (value) "]"; background-color: green; / * ... produceert dezelfde resultaten als de volgende CSS: * / div, p font-size: 10px; div. Keyword, p .keyword color: green; div .constant, p .constant color: rood; achtergrondkleur: groen; div .constant: hover: after, p .constant: hover: after content: "[" attr (value) "]";
In het geval van de specificatie is er eigenlijk geen code gecompileerd, dit is gewoon hoe CSS er in de toekomst waarschijnlijk uit zal zien!
CSS-specificaties worden niet gemaakt door een stel bijzonder creatieve buitenaardse wezens die onze weblevens op afstand willen besturen vanuit een heel ver weg gelegen melkwegstelsel. Nee. Specificaties zijn ontwikkeld door mensen, wat betekent dat andere mensen, met name ontwikkelaars en ontwerpers (zoals jijzelf) invloed hebben op welke specificaties worden ontwikkeld. Door pre-processors zoals Sass te gebruiken, doe je mee aan iets veel meer. Je duwt de technologie verder.
Als u een idee of een functieverzoek bedenkt, kunt u hierom vragen of gewoon deelnemen aan de discussie over hoe een bepaalde functie zich zou moeten gedragen en of deze überhaupt nodig is.
Dankzij de gemeenschap rondom Sass zijn er hulpmiddelen ontwikkeld door anderen waar u gebruik van kunt maken.
ZURB heeft bijvoorbeeld een groot raamwerk gebouwd met de naam Foundation for Sass.
Als u de voorkeur geeft aan iets lichters, zou u Inuit.css kunnen overwegen.
Dan is er natuurlijk Compass, dat een raamwerk biedt met heel veel nuttige opties ...
... zoals inderdaad de slankere Bourbon.
Laten we zeggen dat je vandaag een avontuurlijk gevoel hebt en overweegt om "rem"'s als meeteenheid te gebruiken. Hoe gebruik je rems met fallbacks voor verouderde browsers die deze niet ondersteunen? Gelukkig verklaar je de lettergrootte slechts twee keer; eenmaal in pixels, dan weer in rems voor browsers die het zullen begrijpen en analyseren.
h1 font-size: 16px; lettergrootte: 1rem;
Dit zou waarschijnlijk je beste gok zijn, maar dat betekent dat je overal waar je rem wilt gebruiken, het twee keer moet typen. Ook, terwijl 16px = 1rem een eenvoudige berekening is, wat als je 19px nodig hebt? Doe nu de wiskunde in je hoofd. Kun je? Ja, ik heb ook een rekenmachine gebruikt (1.1875rem).
Omdat er in de Sass-community een aantal geweldige jongens zijn, kun je snel Github zoeken en dit _rem.scss-bestand downloaden (dat ziet er behoorlijk intimiderend uit, nietwaar?), Importeer het (we zullen het over importeren in een ogenblik hebben) en nu kun je magisch doen:
h1 @ include rem (font-size, 2rem)
op welk punt Sass dat automatisch omzet naar
h1 font-size: 36px; font-size: 2rem;
Als de dag ooit zou moeten komen dat u rem fallback-ondersteuning kunt laten vallen, hoeft u geen Regex-zoekopdracht uit te voeren en al uw documenten te vervangen. Je kunt dit gewoon toevoegen aan de bovenkant van je stylesheet.
$ print-rem-px-fallbacks: false;
Ik denk dat je zou kunnen raden wat deze "print rem px fallbacks" instelling doet :)
Ja. We hebben in dit voorbeeld drie Sass-functies gebruikt, een variabele, een aangepaste mixin en een "import" -instructie, maar was het echt zo moeilijk??
Dus dit is iets dat je gaat doen voor de rest van je leven als Web Developer. Verbindingskleuren definiëren. Weet je, dit soort dingen:
een kleur: blauw; a: hover color: yellow;
Het is een vaak herhaalde taak, maar ik zal niet suggereren dat je je eigen Sass Mixin voor dit soort dingen laat rollen. Gebruik in plaats daarvan Compass (een Sass-raamwerk)?
een @ include link-kleuren (blauw, geel);
Dit zal worden gecompileerd met precies hetzelfde als hierboven. En het las ook redelijk goed ("include link-kleuren: blauw en geel"), voor het geval je je afvraagt hoe dat werkt, bezoek kompasdocumentatie.
Als u een editor gebruikt die fragmenten ondersteunt, kunt u een fragment instellen (of downloaden) om het automatisch toe te voegen @include naar uw verklaringen (laat je niet afschrikken).
Sass zelf biedt een heleboel zeer, zeer nuttige functies. Ook al is de Sass-documentatie niet de mooiste van alle dingen (vanuit het perspectief van een ontwerper), het bevat veel zeer nuttige informatie over Sass-functies, bijvoorbeeld een van mijn favoriete functies in Sass - Color Functions. Ik hoef Photoshop niet meer te openen om met kleuren te experimenteren als ik een variatie nodig heb. Ik kan dit soort dingen gewoon doen:
a kleur: lichter (zwart, 10%);
Waarin is gecompileerd
een color: # 1a1a1a;
Sass is niet dat robijnachtige ding dat hardcore ontwikkelaars gebruiken. Het moet u inspireren, de ontwerper, en u helpen met uw dagelijkse werk. Het is geen programmeertaal, het is een Web Frontier.
Sass kan zo eenvoudig zijn als u wilt. Als je nieuwsgierig bent naar de vraag of je iets in Sass kunt doen, ga dan snel op google, je zult er misschien versteld van staan!
Het belangrijkste van allemaal - stop faffing over en gebruik Sass vandaag nog, vooral als je de bocht voor wilt blijven! En houd je ogen open voor alle Sass-zelfstudies, kies welke functies van Sass je leuk vindt en gebruik ze!
Accentsconagua