Oprettelse af brugerdefinerede klasser
Sørg for at forstå definitionen af en brugerdefineret klasse i Client-First. Se definitionen på siden Klassestrategi 1.
Client-First anbefaler at oprette og bruge brugerdefinerede klasser til mange af elementerne i projektet.
Selvom der er en blanding af brugerdefinerede klasser og utility klasser, vil størstedelen af de fleste projekter være brugerdefinerede klasser.
Fordele ved brugerdefinerede klasser
1. Hurtig oprettelse
Webflow som platform blev designet omkring visuel styling af vores webside med Style-panelet. Style-panelet er vores store gevinst i Webflow. Vi kan oprette nye klasser og anvende stilarter på den klasse meget hurtigt.
Vi mener, at anvendelse af klasser gennem Style-panelet bør ske frit og ofte i vores workflow.
I traditionel hjemmesideudvikling er det tidskrævende at oprette brugerdefinerede klasser til mange elementer. Klasser og stilarter skrives i hånden, og det er tidskrævende at skrive CSS-egenskaber i hånden. Det er derfor, at fuldt ud Utility klassebaseret klassesystemer anbefales i traditionel webudvikling.
I Webflow har vi fordelen af Style-panelet, og det skal vi udnytte.
I denne video skriver vi stilene til team-list_ i hånden.
I denne video opretter vi visuelt stilarterne til team-list_ i Webflow.
2. Lettere at tilpasse og mere sikkert at redigere
Der er stor forskel på at redigere stilarter for en brugerdefineret klasse og en utility klasse.
Tilpasning af en instansspecifik brugerdefineret klasse kan ofte være meget ligetil og hurtig. I vores team-list_-eksempel skal vi tilføje en ekstra stil til vores display: flex settings.
Vi påvirker dette element specifikt og behøver ikke at bekymre os om at lave en global fejl på hele sitet. Ved at redigere globale klasser kan vi ved et uheld komme til at opdatere elementer i projektet, som vi ikke ønsker at redigere. Redigering af globale utility-klasser kræver mere omtanke og forsigtighed.
3. Responsive opdateringer til tablet og mobil
Desktop-design kan være meget forskelligt fra tablet- og mobildesign. Der er sandsynligvis tilpasninger på tværs af breakpoints for mange elementer i vores projekt.
Ved hjælp af brugerdefinerede klasser kan vi frit lave opdateringer på tværs af breakpoints. Elementer med en dedikeret brugerdefineret klasse har fleksibiliteten til at blive stylet unikt på tablet eller mobil.
I dette eksempel ændrer vi team-list_, så den ser forskellig ud på tablet og mobil. Den brugerdefinerede klasse giver os mulighed for at foretage denne ændring med style-panelet.
Når vi bruger utility-klasser og laver responsive stilopdateringer, har vi brug for yderligere utility-klasser, der giver variationer for responsive breakpoints.
4. At arbejde med kunder
Kunder har ofte feedback og ønsker, der ikke følger standarden.
"Gør denne afstand mindre", "Gør denne boks større", "Skift farven fra blå til rød", "Skift rækkefølgen af dette på mobil" osv.
Kundeanmodninger kan være "tilfældige", fordi de ikke altid følger standardindstillingerne i et utility klassesystem. Brug af brugerdefinerede klasser kan hjælpe os med bedre at håndtere disse tilfældige anmodninger.
Kunder beder om opdateringer under udviklingen og efter lanceringen. Vi føler os mere trygge ved at opdatere et specifikt element med en brugerdefineret klasse frem for en utilty klasse.
Hvis kundens opdatering ikke passer ind i projektets utility klassesystem, bliver opdateringen mere besværlig. Vi får brug for en ny klasse for at gennemføre opdateringen.
Med en brugerdefineret klasse kan vi implementere stilopdateringer hurtigt.
Brug af globale klasser
Sørg for at forstå definitionen af en global klasse i Client-First. Se definitionen på siden Klassestrategi 1.
Fordele ved globale klasser
1. Administrer stilværdier globalt på tværs af hjemmesiden.
En global klasse skal være meningsfuld — den kan indeholde en værdi for et vigtigt sæt stilarter, der administreres på et globalt niveau.
For eksempel Client-First containerklasserne. container-large har en max-width-værdi på 80rem (1280px). Hvis vi ønsker at reducere containerens max-width på hele hjemmesiden, kan vi opdatere container-large til 75rem (1200px) i én stilændring.
Dette er en global ændring, som opdaterer alle forekomster af container-large i hele projektet.
container-large er en stærk global controller i vores projekt.
2. Hurtigere udviklingstid, effektiv brug af fælles stilarter, brugervenlighed.
Vi ønsker måske at bruge en CSS-stil som en utility klasse for at hjælpe os med at bygge hurtigere. For eksempel hide-tablet eller hide-mobile-portrait.
Disse klasser giver os mulighed for selektivt at ændre synligheden af elementer på hele hjemmesiden, mens vi arbejder — uden at oprette yderligere klasser og kombinationer specifikt til at skjule et element. Denne utility klasse kan hjælpe os med at arbejde hurtigere i Webflow Designer.
I eksemplet nedenfor ønsker vi at skjule de sidste to elementer på listen, så de ikke er synlige på mobilen. Vi bruger hide-mobile-portrait til at skjule de sidste to uden at oprette en ny klasse.
Forstå, at dette ikke er en CSS-egenskab, der skal opdateres globalt. Det er usandsynligt, at vi ønsker at vise alle forekomster af skjulte mobilelementer i projektet. Målet med denne utility klasse er at forbedre arbejdsgangen og samtidig reducere antallet af ekstra brugerdefinerede klasser.
Meningsfuld brug af globale klasser
Hvis en global klasse ikke falder ind under en af disse to fordele, er det måske ikke en fordelagtig brug af en global klasse.
Vi kan stille os selv disse spørgsmål:
Har denne stilart nogen fordel af at blive administreret globalt?
Fører det til hurtigere udviklingstid, effektiv brug af tilbagevendende styles eller bekvemmelighed for kunden?
Vi ønsker kun at oprette og administrere en global klasse, hvis den falder ind under et af disse brugsscenarier.
Eksempel med absolut position
Lad os f.eks. se på en global utility klasse kaldet position-absolute, som tilføjer CSS-egenskaben position: absolute til et element.
Der er ingen grund til at ændre stilarterne i denne klasse globalt. Hvilke CSS-egenskaber vil vi opdatere i position-absolute? Der er ingen meningsfuld grund til at opdatere denne klasse globalt i hele projektet.
position: absolute er normalt ikke en CSS-egenskab, der kan eksistere uafhængigt. Det kræver sandsynligvis yderligere CSS-egenskaber at skabe en meningsfuld position.
Det er usandsynligt, at en position-absolute stil vil forbedre vores udviklingshastighed, da den kræver tilføjelse af stablede klasser. Der vil sandsynligvis være yderligere klassestabling til tablet- og mobilresponsive opdateringer.
Derfor foreslår vi at anvende CSS-egenskaber som position direkte på en brugerdefineret klasse.
Vi anbefaler ikke at bruge en klasse som position-absolute som en global klasse.
Eksempel på mørk sektion
Globale klasser bør have et formål i forbindelse med globale opdateringer. En opdatering af klassen skal være til stor gavn for globale opdateringer på hele sitet.
For eksempel kan vi bruge klassen section-dark til at anvende color: #ffffff og background-color: #000000 på en sektion. Hvis section-dark anvendes på mange sektioner i hele projektet, kan vi lave effektive globale opdateringer til vores mørke sektioner.
Stablede globale klasser
Stablede globale klasser kan hjælpe os med at anvende flere globale stilarter på et enkelt element.
Vi skal have en strategi, når vi stabler klasser. Vores build kan blive uhåndterligt, hvis vi stabler for mange klasser på et element.
Stabl lignende klasser
Vi anbefaler at stable globale klasser fra den samme CSS-egenskab eller kategoritype. Vi ønsker for eksempel at stable:
- Margin-klasser med margin-klasser
- Padding-klasser med padding-klasser
- Breddeklasser med breddeklasser
- Typografiklasser med typografiklasser
Stabling af lignende klasser er ikke en streng regel. Det er en praksis, der hjælper os med at forblive mere organiserede og fleksible i projektet. Ved at bruge denne metode eliminerer vi mange tilfælde af deep stacking.
Hvis vi har en blanding af klasseegenskaber på et element, vokser vores klasseliste og introducerer et problem med deep stacking.
Eksempler
Lad os se på to eksempler — margin og typografi.
Margin
Client-First spacing-systemet bruger en stablet global klassetilgang. Først anvender vi retningsklassen, margin-top. Derefter anvender vi størrelsesklassen, margin-large.
Vi ønsker ikke at tilføje flere klasser oven på dette.
For eksempel ville vi ikke tilføje en max-width kategoriklasse oven på vores margin-klasser.
Vi nærmer os deep stacking, hvis vi tilføjer yderligere klasser oven på margin-top margin-large. Hvis vi placerer max-width-small ud over spacing wrappers, forhindrer vi hurtige ændringer i vores margin-large klasse. Vi er nødt til at fjerne max-width-small, før vi ændrer margin-large.
Dette koncept gælder for alle andre klassekategorier. Vi ønsker, at Div-blokken med margin klasserne kun skal have margin-klasser.
Typografi
Et tekstelement kan kræve flere globale typografiklasser. I dette tilfælde kan vi stable flere klasser på tekstelementet.
For eksempel en stor tekst, der også har en grå farve. Et tekstelement kan få klasserne text-size-large og text-color-gray til at modtage stilarterne.
Ligesom med margin, ønsker vi ikke at tilføje flere klasser oven i dette.
Vi ønsker, at vores typografiklasser skal være lettilgængelige i style-panelet. Hvis vi skal opdatere text-size-large, vil vi ikke fjerne mange klasser efter den for at få adgang til basisklassen.
Tilføj ikke nye stilarter til stablede globale klasser
We don't want to add new styles to stacked global classes because it will create a new class (a combo class) to the CSS of the project.
Vi ønsker ikke at tilføje nye stilarter til stablede globale klasser, fordi det vil skabe en ny klasse (en kombi-klasse) til projektets CSS.
Når man opretter instansspecifikke kombinationsklasser fra globale brugsklasser, modarbejder man formålet med ægte globale utility klasser. Denne praksis kan føre til organisationsproblemer, når hjemmesiden skaleres.
Lad os fortsætte med eksemplerne ovenfor — margin og typografi.
Eksempel med margin
Vi ønsker aldrig at oprette en ny klasse med vores stablede margin-klasser. Hvis vi har margin-top og margin-large, bør vi ikke anvende nogen styles på denne stablede kombination.
Hvis vi anvender styles på denne måde, opretter vi en ny klasse. Vi skriver et nyt sæt stilarter til CSS-stilarket.
Eksempel med typografi
Vi ønsker aldrig at oprette en ny brugerdefineret klasse med stablede typografiklasser. Hvis vi har text-size-large og text-color-gray, bør vi ikke anvende en ny brugerdefineret stil på de stablede klasser.
Dette resulterer også i oprettelsen af en ny kombinationsklasse.
Løsninger
I stedet for at oprette en ny klasse ud fra stablede globale klasser, foreslår vi at bruge disse to strategier.
1. Start med en brugerdefineret klasse fra begyndelsen.
I stedet for at oprette kombinationsklassen text-size-large text-color-gray, skal du oprette en brugerdefineret home-header_text klasse med størrelse, farve og den ekstra CSS-stil. Det giver os fuld stilfleksibilitet til at tilføje tilpassede stilarter til elementet.
Vi vil dog ikke arve nogen globale stilarter for teksten. Hvis vi bruger denne metode for meget, vil vi ikke længere have fordelene ved globalt kontrolleret typografi.
2. Brug en ekstra klasse til at skabe combo-klassen.
Vi opretter vores kombinationsklasse ved at tilføje en ny klasse ud over vores utility klasser. Klassen hedder is-home-header, og der oprettes en kombi klasse for alle tre klasser.
Denne metode bevarer vigtige stilegenskaber i text-size-large text-color-gray, mens den tilpasser instansen med is-home-header. is-home-header indeholder alle vores tilpassede stile til denne instans.
Denne metode er mest værdifuld, når vi ønsker, at visse CSS-stilarter skal forblive globale i hele projektet. I dette eksempel forbliver CSS-egenskaberne font-size (text-size-large) og color (text-color-gray) globalt kontrolleret.
Kombi-klasser
Hvad er en kombinationsklasse?
En kombi-klasse er en variant af en basisklasse. En kombi-klasse arver stilarter fra basisklassen og tilføjer flere stilarter oven på den.
Vi definerer "basisklassen" som den første klasse på vores liste over stablede kombinationsklasser i en kombinationsklasse. Vi tilføjer en klasse oven på basisklassen for at skabe en unik variation.
Kombinationsklassen vil kun fungere, når den kombineres med basisklassen(e) før den. I videoen nedenfor skal du forstå, at is-blue ikke fungerer alene. Den fungerer kun som en tilføjelse til basisknappen.
Den vigtigste forskel mellem en stablet global utility klasse og en kombi-klasse er:
- En kombi-klasse opretter en ny klasse og tilføjer en ny stildeklaration til projektets CSS-fil.
- Stablede globale klasser opretter ikke en ny klasse eller stildeklaration i projektet.
-is præfiks
For at være organiseret og ligetil med vores brug af kombinationsklasser, bruger vi is- som et præfiks i klassenavnet. Når vi ser is-, ved vi, at denne klasse er oprettet som en kombinationsklasse oven på en anden klasse.
Arvning af stilarter fra basisklassen
Kombinationsklasser har ét grundlæggende krav til oprettelse — kombinationsklassen skal have en klar fordel ved at arve stilarter fra basisklassen.
I en kombinationsklasse definerer vi "basisklassen" som den første klasse på vores liste over stablede kombinationsklasser. Basisklassen skal indeholde de standardstilarter, som enhver brugerdefineret variant bygger oven på.
Den klasse, der tilføjes ovenpå, og som skaber kombinationsklassen, er varianten. Hver variant skal have en god use case for at arve stilarterne fra basisklassen.
Eksempel med en knap
Lad os se på et eksempel på et kombinationsklassesystem med en knap.
button klassen er vores basisklasse. Alle stilvarianterne nedenfor ligger oven på button klassen.
is-primary, is-alternative, is-inactive, is-black
Vi kan tilføje disse stilarter til button for at vise en variation. Det er vigtigt at forstå, at is- klasserne ikke fungerer alene. De vil kun fungere som en tilføjelse til button klassen.
button klassen er en vigtig basisklasse i dette eksempel.
Vi ønsker, at alle vores knapper, uanset variant, skal have den samme polstring og skriftstørrelse. Vi definerer disse egenskaber i vores button basisklasse.
Hver af is- varianterne arver disse vigtige globale stilarter fra knappen.
Dette kombinationsklassesystem giver os mulighed for globalt at opdatere CSS-egenskaberne padding og font-size for alle knapper i hele projektet. Alle standardknapper og alle variantknapper vil modtage den globale stilopdatering.
Der er en klar fordel ved at kunne administrere disse stilarter globalt. Vi kan foretage væsentlige ændringer på hele sitet for alle knapper med én klasseopdatering.
Denne kombinationsstrategi for knapper er et glimrende eksempel på effektiv brug af kombinationsklasser.
Kombinationsklasser med et formål
Kombinationsklasser er kraftfulde, og vi skal bruge dem med omhu og formål. Et dårligt opbygget kombinationsklassesystem kan forårsage skalerings- og organisationsproblemer i projektet.
Der skal være et formål med at arve stilarter fra basisklassen. Hvis der ikke er en use case, er der måske ikke nogen grund til at bruge et kombinationsklassesystem. Det kan være bedre at oprette en enkelt brugerdefineret klasse, der indeholder alle stablede stilarter.
Container eksempel — Unødvendigt kombinationsklassesystem
Vi vil gennemgå et eksempel på et kombinationsklassesystem med en container uden et klart formål med kombi-klasse fordelen.
Vores container klasse ændrer flere indstillinger: margin: 0 auto, width: 100% og en variabel max-width værdi.
Det er fristende at lave kombinationer af container is-large, is-medium, is-small. Det virker som en perfekt use case for kombi-klasser, fordi vi har to delte CSS-egenskaber og en variabel størrelsesegenskab.
Men de to delte CSS-egenskaber — margin og width — er ikke CSS-egenskaber, vi bør administrere globalt i en basisklasse. Det er ikke god praksis at ændre disse egenskaber til andre værdier. For eksempel ønsker vi ikke at ændre width: 100% til width: 90%. Derudover ønsker vi ikke at ændre margin: 0 auto værdierne.
Da vi ikke har brug for at administrere margin eller width i container basisklassen, er der ingen fordele ved et styringssystem med kombinationsklasser. Den eneste egenskabsværdi, vi har brug for at ændre, er vores max-width klasse.
I stedet for container is-large kombinationsklassen anvender vi alle stilarter direkte på en enkelt klasse — container-large. Vi foretrækker altid at arbejde med en enkelt klasse i stedet for en kombinationsklasse. Hvis der ikke er brug for en kombination, vil vi ikke bruge den.
Med størrelsesnavnet i klassenavnet forbedrer vi desuden muligheden for at scanne vores klassenavne i Navigator-panelet. Vi vil se container-large som klassenavn i stedet for kun at se container.
Typografi-eksempel — Arver fra desktop, tilpasser til mobil
Vi er nødt til at tilpasse et tekstelement, fordi det er unikt på mobilen. På desktop og tablet følger dette element standardstilen text-size-large. På mobilen kræver det en unik opdatering, som ikke passer ind i vores globale utility klasse som standard.
1. Start med en brugerdefineret klasse fra begyndelsen.
Vi har mulighed for at oprette en ny brugerdefineret klasse til at styre typografien på tværs af alle breakpoints. For eksempel home-header_text-subtitle. Med denne strategi bruger vi ikke utility klassesystemet. Ulempen ved denne strategi er, at vi ikke længere vedligeholder de globale størrelsesværdier for desktop og tablet. Hvis vi ønsker at lave en global opdatering af vores text-size-large på desktop, får den brugerdefinerede klasse ikke den ændring.
2. Brug en ekstra klasse til at oprette kombinationsklassen.
Hvis globalt administreret typografi er vigtigt i vores projekt, kan vi overveje en ny kombinationsklasse. For eksempel text-size-large is-home-header. Fordelen ved denne implementering er, at vi kan bevare vores globale stilarter på desktop og tablet og derefter kun tilpasse dem til mobil. Når vi foretager en global ændring af vores text-size-large klasse på desktop, vil dette element modtage opdateringerne gennem det globale system.
Brug af denne strategi med andre utility klasser
Dette koncept fungerer også for andre utility klassesystemer i projektet. For eksempel:
icon-medium is-footer
button-primary is-nav
heading-medium is-mobile-effect
Sørg for, at der er et formål med at oprette en kombinationsklasse fra en global utility klasse. Der skal være en klar use case for at vedligeholde de globale stilarter og derefter tilføje yderligere stilarter.
Lad være med at deep stacke! Strategien med is- kombinationsklasser bliver mindre effektiv, når der er en række stablede globale klasser. For eksempel er text-size-large text-color-black text-style-underline is-testimonials-title for mange stablede klasser.
Vi vil til enhver tid undgå deep stacking.
Lad være med at deep stacke
Grunde til ikke at deep stacke
1. Workflow-problemer i Webflow Style-panelet
Vi har ikke fri kontrol over kombinationsklasser i Webflow.
- Vi kan ikke ændre rækkefølgen af stablede klasser i Style-panelet.
- Vi kan ikke redigere dybt stablede klasser på mobile breakpoints.
- Vi har ikke fuld kontrol til at styre stablede klasser visuelt i Designer.
Det er en vanskelig proces at fjerne alle de senere klasser i en liste med dybt stablede klasser. Efterhånden som klasselisten bliver længere, er der større risiko for fejl og frustration, når man foretager redigeringer.
Vi mener, at dette ikke er en effektiv arbejdsgang og et problem med Webflow UX.
Vi har designet dette Client-First princip specifikt omkring den måde, Webflows Designer UI giver os mulighed for at interagere med stablede klasser.
2. Mange trin til små ændringer
Begrænsningerne i afsnittet resulterer i en tidskrævende proces, når man redigerer dybt stablede klasser.
At slette en liste over klasser for at fjerne en enkelt klasse tidligt i den dybt stablede liste er ikke en sjov praksis. Vi kan blive frustrerede over disse ekstra trin, hvis det er en konstant praksis i vores arbejdsgang.
Derudover har vi workflow-problemer med klasseredigering for mobile breakpoints. Når vi skal lave tilpasninger, der er specifikke for mobiler, kan der opstå stilkonflikter fra tidligere stablede elementer.
3. Øget indlæringskurve
Vi mener, at deep stacking fører til en større indlæringskurve, fordi der er et større behov for at forstå, hvad klasserne gør.
En bruger, der går ind i projektet, skal
- Have en stærk forståelse af CSS
- Forstå, hvad hver klasse i den stablede liste gør
- Forstå nuancerne ved klassestabling i Webflow
Vi mener, at dette øger indlæringskurven for vores projekt.
Når vi bruger Client-First, ønsker vi at sænke indlæringskurven hele tiden. Vi bør presse os selv til at skabe elementer, bruge klasser og implementere strategier, der er nemme at forstå, administrere og skalere. Det er det, der skaber et stærkt Webflow-projekt.
4. Det er hurtigt at skrive CSS i Webflow
Vi behøver ikke at spare tid på at skrive CSS i Webflow.
Forklares i sin helhed ovenfor Oprettelse af brugerdefinerede klasser > Fordele ved brugerdefinerede klasser > 1. Hurtig oprettelse.
5. Der er en lille CSS-besparelse
Eksempel på små CSS-besparelser — For eksempel er indlæsningstiden for en CSS-fil på 52 kb i forhold til en CSS-fil på 65 kb ubetydelig.
Vi mener ikke, at de relativt lave besparelser i CSS style sheetet opvejer fordelene ved oprettelse af brugerdefinerede klasser.
Grænser for deep stacking
I Client-First stacker vi, men vi ønsker ikke at stacke dybt. Nedenfor ser vi på antallet af klasser, der stables på et element.
1 eller 2 klasser på et element
Super. Det er almindeligt.
3 klasser på et element
Ok, men hvorfor har vi brug for 3 stablede klasser? Er det nødvendigt?
4 klasser på et element
Absolut maksimal stabling. Har vi virkelig brug for 4 stablede klasser?
5 klasser på et element
Det er for meget. Det vil være svært at styre. Opret en brugerdefineret klasse.
Strategier til at undgå deep stacking
1. Brug en enkelt brugerdefineret klasse
I stedet for at stable flere klasser, kan vi starte med en enkelt brugerdefineret klasse. Vi kan style elementet med én klasse uden nogen form for klassestabling. Vores stablede stilarter vil blive anvendt på en enkelt brugerdefineret klasse.
2. Indlejr en anden Div-blok
Når vores klasser stables for højt, kan vi oprette en indlejret Div Block, der administrerer en vigtig stil.
Den kernestruktur, der bruges i Client-First, har denne tilgang. I stedet for at stable mange klasser på ét element, deler vi klasserne op efter type og bruger flere indlejrede lag af elementer.
Et indlejret lag adskiller stilarter, der har forskellige formål. Vi bevarer vores globale utility klassesystem, mens vi undgår deep stacking.
Det samme koncept gælder for Client-First spacing-systemet. Ved at implementere et spacing wrapper-koncept adskiller vi for eksempel margin-top og margin-large fra andre elementer.
3. Opret en kombi-klasse
For eksempel:
section_header + is-mobile-reverse + background-blue + text-color-white
Kan blive til:
section_header + is-home-header
Vi arver de vigtige globale stilarter fra section_header, f.eks. padding, z-index og transition.
Vores is-home-header klasse er en kombinationsklasse, som tilføjer background-color, tekst color og responsive layoutændringer til instansen.
I stedet for at stable fire klasser, har vi reduceret stablingen til to klasser. Det er nemmere at administrere og mere fleksibelt i forhold til opdateringer.
Intet layout-system
Ingen flex-, grid-, column- eller layoutklasser
Ingen flex-, grid-, column- eller layoutklasser er inkluderet i Client-First.
Vi anbefaler ikke et fuldt globalt styret flex- eller gridklassesystem i Webflow. Vi opfordrer til brugerdefineret klasseoprettelse ved hjælp af flex, grid eller et column layoutsystem.
Eksempel 1 på, hvad vi ikke kan lide
Lad os bygge et grid-layout med utility klasser. Dette eksempel er ikke en praksis for Client-First. I stedet er det et eksempel på, hvorfor vi ikke har et formelt layoutsystem inkluderet i Client-First.
grid-3-col gap-large tablet-grid-2 mobile-grid-1
Forestil dig nu, at kunden beder om at skabe mindre plads mellem elementerne på tablet. Det gap-large, som vi havde brug for på desktop, er ikke længere nødvendigt på tablet. Vi har brug for et meget mindre mellemrum. Men vi arver vores gap-large fra desktop.
Vores klasseliste kan blive lang, når vi tilføjer brugerdefinerede tablet- og mobiltilføjelser til vores utility layoutsystem. Variationer i tablet- og mobilrespons kan resultere i superdyb stabling.
For at tilfredsstille alle brugssituationer for alle layoutstørrelser på tværs af alle breakpoints, har vi brug for et stort og komplekst layoutsystem. Vi bliver nødt til at oprette en ny klasse for at opnå layoutet, hvis der ikke er nogen anvendelig klasse til rådighed for vores responsive tilpasning.
Der kræves mange trin for at gå fra en tom Div Block til et færdigt responsivt element.
Eksempel 2 på, hvad vi ikke kan lide
Det er muligt at reducere antallet af klasser i et utility klassesystem ved at gruppere flere CSS-egenskaber i én klasse.
For eksempel etablerer flex-a-l-j-c + flex-mobile-a-c flex-indstillingerne på basis breakpoint og den mobile variation.
Denne navngivning er uklar for nogen, der ikke kender dette layoutsystem. Som den oprindelige udvikler kender vi det måske, men det betyder ikke, at andre udviklere eller vores kunder gør det.
Vi ønsker heller ikke at se col-2-d + col-5-t + col-12m.
Selvom denne konvention måske er klarere, er vi stadig nødt til at forstå, hvordan dette system fungerer. Det er uklart, hvad vores muligheder er for at fortsætte med at bygge i projektet.
Hvad betyder tallene? Hvad betyder bogstaverne? Hvad er kolonnerne? Hvordan fungerer responsive opdateringer? Hvad gør jeg, når jeg har brug for en unik tilpasning?
Eksempel på, hvad der kan fungere med Client-First
Vi kan bruge globale klasser til at skabe layouts i Client-First. Globale layoutsystemer kan være Client-First venlige. Hvis det er det, der er bedst for vores build, så gør det.
For eksempel kan grid_col-2 og grid_col-3 bruges som standardlayout med 2 og 3 kolonner. På Desktop er de alle ens. En kombinationsklasse is-specific-instance kan oprettes til tablet- og mobilforekomster, der er forskellige fra standarden.
Vi ønsker ikke at låse alle fast i et dybt globalt klasselayoutsystem for hvert layout, afsnit eller side i vores build. Ved at bruge et kombinationsklassesystem som dette kan vi være Client-First venlige og samtidig bevare layoutets enhed.
Opret layouts med brugerdefinerede klasser
Vi kan skabe enkle og komplekse layouts ved hjælp af brugerdefinerede klasser. Vi kan bruge brugerdefinerede klasser til alle layouts i vores projekter, hvis vi vil.
Brugerdefinerede klasser er fremragende til opbygning af layouts. Brugerdefinerede klasser giver os mulighed for at:
- Hurtigt opbygge sidestrukturer
- Hurtigt foretage redigeringer i fremtiden
- Foretage alle responsive tilpasninger
- Forhindre utilsigtede brud på layoutet på hele sitet
- Aflevere vores projekt med en minimal indlæringskurve