HTML tags er standard
Typografi bør være vores projekts mest enkle og organiserede form for utility system. Hjemmesider med ensartede typografisystemer hjælper os med at være tydelige for brugeren.
Vi kan tænke på HTML-typografitags som vores standardtypografi-værdier.
I en perfekt verden ville vi aldrig behøve at tilføje en klasse til en overskrift eller tekstelement. Ved at følge standardtypografien i alle tilfælde opnår vi et rent og organiseret projekt.
Det er dog almindeligt, at branddesigns har variationer og tilpasninger til forskellige tekstforekomster.
Vi bruger en klasse, når der er en variation fra standardtypografi-stilen. En klasse ændrer standardtypografi-værdien.
For eksempel en global utility klasse som text-size-medium.
Vi anvender text-size-medium på tekstelementet, fordi størrelsen er en variation af den font-size som er sat på vores body element.
Utility klasser til at tilpasse standardstilene
Vi bruger globale utility klasser til typografistile for at hjælpe med at ensarte, organisere og administrere disse typografivariationer.
Client-First kommer med et globalt utility klasse system for typografisk organisering. Vi bruger text- og heading- som præfikser for vores typografi utility klasse.
Fordele ved Client-First typografisystem
1. Global styring
Styr CSS-egenskaberne, der udgør typografivariationerne, globalt. Vi kan foretage globale ændringer af typografien på tværs af hele webstedet ved at ændre én enkelt værdi.
2. Forhindrer unødvendig oprettelse af nye klasser
Undgå at oprette flere klasser til genbrugte stilarter. Globale hjælpeklasser reducerer antallet af unikke brugerdefinerede typografi-klasser. For eksempel text-color-blue.
Vi ønsker at undgå at oprette flere brugerdefinerede klasser, der styrer tekstens color: blue.
3. Arbejdsflow, hastighed og organisering
Vi kan søge efter og administrere vores typografiklasser i Designer Styles panelet ved at skrive præfikset text- eller heading-. Dette gør det muligt for os hurtigt at bruge typografiklasser i vores arbejdsprocess.
Denne præfiksningskonvention hjælper os med at administrere vores typografi inde i Styles panelet og mapperne. Vi kan organisere vores utility klasser til typografi i en dedikeret mappestruktur.
Organisering af typografien gør det muligt for os at arbejde hurtigere og mere effektivt i Webflow Designer.
Grunde til at tilpasse standardtypografien
Variation i stil
Den mest almindelige årsag.
Når der er en stilvariation i forhold til standardtypografielementet, ønsker vi måske at anvende en global utility klasse.
Vi kan bruge én eller flere globale utility klasser til at tilpasse vores standardstile. For eksempel text-color-blue, text-weight-semibold.
Ved at tilføje forskellige kombinationer af klasser til typografielementet har vi mange muligheder for at style vores tekst.
De fleste af vores overskrifter skal være uden klasse, hvis det er muligt. Jo mere vi bruger standardstile, desto mere ensartet bliver vores typografi.
Overskriftstags til SEO matcher ikke designets overskriftstags
For eksempel skal vi bruge en H1-tag til sidens titel. H1 er nødvendig for SEO og side crawling. Dog skal denne titels stilarter følge H2-stilen i projektet.
Vi står over for et problem, hvor vi har brug for at bruge udseendet af en bestemt overskriftsstil på en anden overskriftsstil i forhold til søgemaskineoptimering (SEO).
For at løse dette kan vi bruge stilen heading-style-h2 på H1-elementet for at få det til at se ud som en H2, samtidig med at vi bevarer den oprindelige betydning af H1-taggens SEO.
heading-style-h#-klasserne er nyttige til at implementere enhver overskriftsstil, samtidig med at den passende heading tag til SEO bevares for tekstelementet.
Det er vigtigt at forstå, at heading-style-h#-klassen ikke ændrer HTML-tagget for elementet. Den ændrer kun de CSS-stile, der anvendes på elementet.
Anvendelse af heading-style-h#-klassen bør ikke bruges i de fleste tilfælde. De fleste af vores overskrifter skal være uden klasse og følge standarden. Vores standardoverskriftsstile bør være mere almindelige end overskriftsvariationer.
Undgå brug af overskriftstags
Vi ønsker kun at bruge overskriftstags til overskrifter. Hvis der er tekst på siden, der ikke er en overskrift, men har brug for overskriftsstile, skal du ikke tvinge et overskriftstag på elementet.
Vi ønsker at holde vores H1 - H6 organiseret og bruge dem korrekt til SEO.
I dette eksempel vises teksten "Tak". Vi ønsker ikke at bruge et overskriftstag til dette tilfælde, fordi det ikke er en overskrift med relevant indhold. Dog har vi brug for stilen fra H2.
I stedet for at bruge et overskriftstag til ikke-overskriftselementer kan vi bruge et tekstelement og en brugerdefineret klasse til at style det.
Tilpasning af typografisystemet
Det officielle Client-First startprojekt giver os et godt udgangspunkt. Det er ikke dit endelige sæt af typografistile til projektet.
Med hvert nyt projekt skal vi opdatere style guiden baseret på projektets stilarter.
Opret et nyt utility klasse system
Efter vi har opdateret alle typografiklasserne, der følger med Client-First, bør vi overveje at tilføje nye typografiklasser til projektet.
Vi kan oprette nye typografisystemer indenfor hjælpeklassemodellen.
For eksempel, hvis vi bygger en hjemmeside med forskellige værdier af (opacity) gennemsigtighed i hele projektet, kan vi oprette en hjælpemappe til typografisk opacity.
text-opacity-low
text-opacity-medium
text-opacity-high
text-opacity-full
Oprettelse af disse klasser vil se sådan ud i mapperne:
Vi kan oprette nye mapper indenfor utility klasse mappen til enhver CSS-egenskab, vi ønsker at styre globalt.
Opret en ny utility klasse for at undgå deep stacking
I Client-First vil vi altid undgå deep stacking af klasser. Vi kan deep stacke globale utility klasser for at få den præcise teksttilpasning, vi har brug for.
Mere detaljeret forklaring af dette koncept på Klassestrategi 2 siden.
Når vi deep stacker typografiklasser, vil vi have svært ved at ændre tidligere klasser i listen over stablede klasser.
Hvis denne kombination af stablede klasser gentages i vores projekt, kan vi overveje at oprette en ny utility klasse, der repræsenterer gruppen af stablede klasser.
For eksempel kan vi tage vores tidligere eksempel og kombinere alle stilarter til text-style-subtitle — eller text-style-alternative — eller et hvilket som helst andet navn for at beskrive brugen af de kombinerede stilarter.
Vi kan bruge denne klasse hver gang denne dybe stablingssituation opstår.
Mappe-navnet inde i tekst-mappen er vores beslutning.
Vi kan bruge 'style'-mappen til at gemme disse grupperede stilarter — "text-style-alternativ".
Vi kan også oprette en ny mappe — text-custom-alternative.
Forstå, at jo mere vi bruger denne strategi, desto mindre global bliver vores typografisystem. Vi bliver nødt til at tage ekstra skridt for at ændre vigtige globale stil-egenskaber.
For eksempel, hvis egenskaberne for text-size-large blev brugt til at oprette text-style-subtitle, og vi ønsker at opdatere alle text-size-large fra 3rem til 4rem, ville vi skulle foretage denne ændring to gange - en gang til text-size-large og en gang til text-style-alternative.
Vi arver ikke længere text-size-large, når vi grupperer vores stablede klasser for at oprette text-style-alternative.
Vi mister et enkelt globalt typografisystem, hvis vi misbruger denne strategi med grupperede stilarter. Men når den bruges intelligent, kan den hjælpe os med at arbejde hurtigere. Tag altid meningsfulde beslutninger, når du opretter nye utility klasser til grupperede stilarter.
Opret en brugerdefineret klasse
Vi kan ikke bruge utility klasse systemet til enhver situation.
Grunde til, at en brugerdefineret klasse kan være bedre for tekst:
- Unik og specifik tekst
- Administrere en særlig gruppe af tekst
- Tilpas standard responsive stilarter
"At oprette en brugerdefineret klasse" bør ikke være en almindelig praksis for projektet. I den ideelle situation hører størstedelen af vores klasser til utility klasse systemet for typografi.
Dog er der tilfælde, hvor en brugerdefineret klasse er bedst. Herunder identificerer vi tre situationer, hvor en brugerdefineret klasse kan være ideel.
Unik og specifik tekst
Når vi har unik tekst, der ikke passer ind i vores utility klasse system, kan vi oprette en brugerdefineret klasse til at anvende de nøjagtige stilarter, der kræves til teksten.
For eksempel footer_copyright-text. Ophavsretsteksten er meget lille, har en speciel grå farve, er skrevet med store bogstaver og har forskellige stilarter på tværs af hjemmesidens breakpoints. Det er et specifikt identificerbart tekstelement med en unik kombination af stilarter.
Det kan være muligt at style denne kombination af stilarter med utility klasser ved at stable 4-5 klasser. Vi ønsker aldrig at tvinge et tekstelement ind i utility klasse systemet.
Det er hurtigt og nemt at bruge en brugerdefineret klasse titl dette specifikke tilfælde.
Administrere en særlig gruppe af tekst
Med én enkelt stilændring kan vi opdatere alle forekomster af en særlie gruppe af tekst.
Footer link Example
For eksempel footer_link. Footer- inket vises [8] gange i bunden af siden. Ved at anvende denne ene klasse på hvert footer link kan vi administrere gruppen af tekst samlet.
Hvis størrelsen af footer_link teksten skal justeres, kan det gøres på ét element, og alle footer_link elementer vil ændre sig.
Det er nyttigt at kunne opdatere alle forekomster af tekst, især når der er stor sandsynlighed for responsiv tilpasning.
Tilpas standard responsive stilarter
Vores utility klasse typografisystem er ideelt til at opretholde standardtypografi på tværs af alle breakpoints.
Hvis teksten ikke følger standarden på alle breakpoints, kan en brugerdefineret klasse hjælpe os med at opnå denne tilpasning.
For eksempel følger H1 på siden normale H1 stile på desktop og tablet. På mobil formindskes H1 teksten markant. H1 er en lang tekststreng, og størrelsen skal justeres for mobil. Vi kan bruge en brugerdefineret klasse til at opnå denne tilpasning på lavere breakpoints. For eksempel faq-template_heading-text.