Forskellige klassetyper
Utility klasse
En utility klasse oprettes til en specifik kombination af CSS-egenskaber, som kan anvendes på elementer på tværs af projektet
Utility klasser er globale af natur. en utility klasse, gør det nemt at anvende globale CSS-egenskaber i projektet.
Klassen background-color-gray Kan du finde i Client-First starter projektet. Denne klasser hjælper med at organisere og administrere almindeligt anvendte baggrundsfarver på tværs af projektet.
Klassen font-size-large Kan du finde i Client-First starter projektet. Denne klasser hjælper med at organisere og administrere ensartet typografistørrelse gennem hele projektet.
Utility klasser har ikke underscore i deres klassenavn.
Brugerdefineret klasse
En brugerdefineret klasse oprettes til specifikke komponenter, sider, grupperinger eller enkelte elementer.
Vi kalder dette en brugerdefineret klasse, fordi den er tilpasset uden for vores projekts utility klasser. Vi opretter brugerdefinerede klasser, når vi har behov for at tilpasse funktionaliteten på en måde, der ikke kan eller bør opnås ved at bruge vores eksisterende hjælpeklasser.
For eksempel, en klasse til at style et bestemt element i de globale overskrifter, header_background-layer.
For eksempel en klasse til at style et bestemt element i vores testimonial-slider, testimonial-slider_headshot.
Brugerdefinerede klasser har altid underscore i deres klassenavn.
Global klasse
En global klasse er beregnet til at blive brugt på tværs af hele projektet. Både utility klasser og brugerdefinerede klasser kan være globale klasser.
En global klasse er ikke beregnet til kun at blive brugt til et specifikt tilfælde. Den anvender stilarter, der forbliver “globale” og/eller “konsekvente” på tværs af projektet.
"Global" betyder overalt og hvor som helst i projektet.
En utility klasse er altid en global klasse. Utility klasser er globale af natur.
For eksempel betyder det, at vores margin- og padding-klasser er globale utility klasser. margin-large har en margen værdi på 3rem. Når vi opdaterer den værdi til 4rem, vil alle komponenter, der bruger margin-large, også blive opdateret til 4rem.
margin-large er en global controller, der ændrer værdien af vores margin og padding på tværs af projektet. Vi kan lave betydningsfulde, globale ændringer i vores projekt, når vi bruger globale utility klasser korrekt.
Globale klasser er ikke begrænset til utility klasser. Globale klasser defineres nu mere tydeligt som enhver type klasse, der har til hensigt at have fuldstændig global styring af stilarter på hele webstedet.
I Client-First v2 forklarer og opfordrer vi bedre til brugen af brugerdefinerede klasser som globale klasser.
For eksempel kan faq_item være en global brugerdefineret klasse. Vi har mange FAQ-sektioner på hele hjemmesiden, og faq_item bruges til at styre FAQ-elementerne på tværs af hele projektet.
For eksempel kan header_content være en global brugerdefineret klasse. Vi har en header komponent på hver side af projektet. Denne klasse administrerer tilpasningen af dette indhold globalt i hele projektet.
Kombi-klasse
En klasse, der er oprettet som en variant af en basisklasse. En kombi-klasse arver stilarter fra basisklassen og tilføjer flere styles.
Vi definerer en "basisklasse" som den første klasse i vores stablede kombi-klasse. Vi tilføjer en klasse oven på basisklassen for at skabe en unik variant.
Klassen, der skaber den unikke variation, har et klassepræfiks på is-.
Den stablede vil kun fungere, når den kombineres med den foregående basisklassen. I videoen nedenfor kan du se at is-blue ikke virker alene. Den fungerer kun som en tilføjelse til basisklassen button.
Kombi-klasser kan oprettes ud fra en brugerdefineret eller hjælpebaseklasse. Eksemplet ovenfor, button is-blue, viser en utility klasse som en kombi-klasser.
Vi kan også oprette en kombi-klasse til en brugerdefineret klasse. For eksempel, header_content is-home. Dette er en variant af vores brugerdefinerede klasse header_content.
-is præfiks
We define a combo class in Client-First with the is- prefix. When we see is- we know this class is created as a combo class on top of a base class.
Vi definerer en kombi-klasse i Client-First med præfikset is-. Når vi ser is-, ved vi, at denne klasse er oprettet som en kombi-klasse oven på en baseklasse.
Undgå deep stacking (overdreven stabling af klasser)
Client-First har en universel regel — man må ikke lave deep stacking.
Deep stack — mange klasser 'stablet' oven på et element.
Deep stacking — handlingen med at stable mange klasser oven på et element.
Dette er et begreb, der er skabt af Client-First for at håndtere de problemer, vi står over for med stabled klasser i Webflow Designer.
Client-First anbefaler ikke at bruge en deep stack strategi i Webflow.
For eksempel:
I Client-First ønsker vi at undgå deep stacking af klasser som denne. Læs den fulde dokumentation for at vide hvordan du undgår deep stacking.
Her er en hurtig liste over grunde:
Årsager til at vi undgår deep stacking.
Manglende evne til at ændre rækkefølgen af stilarter i vores Designer Style Panel.
Vi har ikke fuld kontrol over stablede klasser i Webflow. Vi kan ikke ændre rækkefølgen eller håndtere dem korrekt i vores Designer Style Panel. Hvis vi ønsker at ændre eller fjerne klasser i den stablede liste, skal vi fjerne alle klasser fra listen for at kunne få adgang til tidligere klasser.
I eksemplet nedenfor kan vi se, at vi skal fjerne nogle klasser, hvis vi vil ændre tekstens vægt fra text-weight-medium til text-weight-bold:
Dette problem bliver særligt udfordrende, når vi foretager ændringer på lavere breakpoints-niveauer. Vi har endnu mindre kontrol, når vi redigerer breakpoint uden for de basale breakpoints*.
* Breakpoints er de punkter, hvor dit webdesign tilpasses for at passe godt til forskellige skærmstørrelser og enheder (Desktop, Tablet, Mobil).
Tidskrævende proces — Kræver mange trin for små ændringer.
Den ovenstående proces er tidskrævende. Hvis dette er en hyppig praksis i vores arbejde, vil det øge både bygge- og vedligeholdelsestiden.
Højere indlæringskurve.
Vi mener, at deep stacking fører til en stejlere indlæringskurve. Det kræver en dybere forståelse af, hvordan klasserne fungerer, og hvordan de håndteres.
At skrive CSS i Webflow er hurtigt.
At skrive CSS er hurtigt og effektivt gennem Webflows Style Panel. Vi kan oprette en ny klasse og visuelt tilføje CSS-egenskaber til klassen. Denne proces er meget hurtig i Webflow, og vi drager fordel af det i Client-First.
Besparelsen af CSS-størrelsen er ikke særlig betydelig.
Når vi bruger globale klasser i et projekt, kan vi reducere størrelsen på vores CSS-fil. Vi mener dog ikke, at disse små besparelser i CSS opvejer fordelene ved at oprette brugerdefinerede klasser i Webflow.
Lær mere om deep stacking senere:
Mere detaljeret forklaring af hvert af disse punkter på klassestrategi 2 siden.
Brug brugerdefinerede klasser
Brugerdefinerede klasser er en kraftfuld og anbefalet metode i Client-First.
Vi bruger brugerdefinerede klasser til disse formål.
- Gør det nemt at redigere specifikke elementer — Hvis vi bruger et organiseret system med brugerdefinerede klasser, kan vi hurtigt foretage unikke ændringer på specifikke elementer og komponenter i vores projekt.
- For at undgå brugen af utility klasser overalt i vores projekt — Utility klasserne er kraftfulde, men de bør ikke bruges til at opbygge hele projektet. Når brugen af en utility klasse gør vores arbejde som Webflow-udviklere mere kompliceret, opfordrer vi til oprettelsen af en brugerdefineret klasse. Der skal være en tydelig fordel ved at bruge en utility klasse.
- For at undgå deep stacking — Deep stacking kan erstattes med en brugerdefineret klasse.
Baggrundstekstur — Eksempel
For eksempel ønsker vi at style baggrundsteksturen på en komponent.
Vi kan muligvis style vores baggrundstekstur med tre stablede klasser. For eksempel, background-absolute + fit-size + opacity-low. Når de kombineres, giver disse tre klasser os den ønskede stil-kombination.
I stedet for at stable flere klasser til denne baggrundstekstur, kan vi oprette en brugerdefineret klasse kaldet services-item_background-texture. Klassen angiver tydeligt, at denne klasse er til "en tekstur, der er på et baggrundsbillede på en af vores services."
Nu kan vi hurtigt og mere frit foretage ændringer i denne brugerdefinerede klasse i stedet for at omorganisere de stablede klasser. Hvis vi har brug for en unik styling, har vi en brugerdefineret klasse klar til at acceptere denne unikke styling.
Traditionel CSS-udvikling
I traditionel CSS-udvikling kan en stablet klasse-løsning være den bedste løsning. stablede klasser kræver mindre CSS at skrive manuelt, hvilket fører til hurtigere udvikling.
Men dette er ikke traditionel CSS-udvikling. Dette er Webflow. Client-First er en samling af principper, der er skabt specifikt til Webflow.
I Webflow mener vi, at det tager mindre tid og indsats at oprette og administrere stilarter af en brugerdefineret klasse på et element end at håndtere en deep stacked klasseliste.
Mere detaljeret forklaring af dette koncept på klassestrategi 2 siden.
Navnekonvention
Opret klare og specifikke navne til klasserne.
En Webflow-udvikler, kunde eller hvem som helst bør kunne forstå, hvad klassen gør ud fra klassens navn, selv hvis de aldrig har hørt om Client-First før.
Navnemindset
Client-Firsts navnekonventions mål
- Give en ikke-teknisk person mulighed for at administrere vores hjemmeside.
- Være tydelige, informative og beskrivende i vores navngivning af klasser.
- Give læseren så meget kontekst som muligt i forhold til klassens formål.
- Sikre et klassenavn, der utvetydigt forklarer klassens formål.
- Ingen forkortelser, ingen stenografi, ingen forvirring.
- Give så meget kontekst som muligt om forholdet mellem den pågældende klasse og hjemmesiden.
- Skabe navne ved hjælp af præfikser og nøgleord.
- Visualisere formålet med en klasse baseret på dens navn.
Spørgsmål at stille os selv, når vi navngiver klasser
:Klassenavne skal fortælle, hvad de gør. Når vi opretter et navn til en klasse, kan vi tænke på følgende spørgsmål:
- "Hvad gør denne klasse i projektet?"
- "Hvad er formålet med denne klasse i projektet?"
- "Hvordan kan jeg give mest mulig kontekst til, hvad denne klasse er ansvarlig for i projektet?"
Navnet på en klasse skal besvare disse spørgsmål.
En Webflow-udvikler, klient eller marketer skal kunne forstå, hvad klassen gør ud fra klassens navn, selvom de aldrig har hørt om Client-First før.
Meningsfulde navne og nøgleord
Et stærkt nøgleord giver os kontekst for, hvad denne klasse/element gør. Ved at være så beskrivende som muligt i vores navngivning hjælper det os med at holde orden.
Nøgleord og klare navne er dybt forankrede koncepter i Client-First. Hvert klassenavn skal tjene et meningsfuldt formål. Vi bør give den næste person, der går ind i projektet, så meget kontekst som muligt om formålet med klassen.
Nøgleord går fra det generelle til det specifikke inden for et klassenavn.
Lad os se på text-size-large som et eksempel.
Det mest generelle nøgleord i dette klassenavn er text. Dette ord fortæller os, at denne klasse har noget at gøre med et tekstelement.
size fortæller os, at vi arbejder med tilpasning af tekstens størrelse. Ordet "size" er mere specifikt, da det relaterer sig til en bestemt CSS-egenskab for teksten - font-size.
Sidst har vi large, der giver os mere specifik information om værdien af tekststørrelsen. Det er en stor tekststørrelse.
Bemærk, hvordan vi ikke kalder denne klasse large-size-text. Selvom dette måske er lige så klart som text-size-large, har vi betydelige fordele i Client-First, når vi følger en generelt-til-specifik klasse-navngivningskonvention. Vi muliggør mere intelligent søgning efter klasser og organisering af mapper. Vi vil lære mere om dette i dokumentationen.
Lad os se på et eksempel med en brugerdefineret klasse, team-list_headshot-wrapper.
Mappernavnet er team-list_, hvilket fortæller os, at dette element har noget at gøre med team-siden eller et team-afsnit og er en liste. "team list" er navnet på gruppen, der indeholder de specifikke elementer.
headshot bliver mere specifikt og fortæller os, at dette har noget at gøre med headshot-elementet inden for team-listen.
wrapper bliver endnu mere specifikt og fortæller os, at dette omslutter headshot'.
Når vi læser klassenavnet team-list_headshot-wrapper, er det klart og logisk, selvom brugeren ikke forstår CSS'en bagved. Brugeren vil forstå, at redigering af denne klasse vil gøre [noget] ved teamlistens headshots. Det er en fremragende indikation for den næste person, der går ind i projektet.
Forestil dig nu, at vi tilføjer flere elementer inde i vores headshot-wrapper. Vi kan holde en meget organiseret struktur ved hjælp af en generelt-til-specifik navngivningskonvention.
team-list_headshot-wrapper
team-list_headshot-image
team-list_headshot-texture-layer
team-list_headshot-background
Vores liste over klasser til teamlisten er meget organiseret og logisk i vores projekt. Denne navngivningskonvention passer rigtig godt ind i vores mappemuligheder.