Et svar på “Hvordan man bliver god med CSS”

Tip - det kræver praksis, men også et greb om det større billede.

Du har sandsynligvis hørt om Quora nu, det er en temmelig pæn platform til at opnå og dele viden. Der er hundreder af aktive kategorier, hvor du kan spørge og svare på alt, hvad der dukker op for dit sind.

Et af de oftere type spørgsmål, jeg ser, er for det større billede af tingene. Mens begrebet spørgsmål-svar-type ligner dette med StackOverflow, er arten af ​​spørgsmålene og svarene forskellige.

De gode spørgsmål, og mere præcist - svarene i Quora er ikke i linjerne "Hvordan laver jeg min baggrundsstokk, mens jeg ruller" eller "Sådan indstilles bløde rammer for min knap". Misforstå mig ikke her, der er sådanne spørgsmål, men de har ikke meget værdi.

Hvad der dog er interessant, er ”Hvordan får jeg det godt” eller ”Hvordan organiserer jeg min kode”. En type spørgsmål, som ikke er så velkomne i StackOverflow, som du sandsynligvis ved, da de ikke er specifikke nok.

Og dette er mit mål her - at besvare det enkle spørgsmål "Hvordan man bliver god." Jeg vil ikke gå ind på tekniske detaljer, da de ikke er vigtige.

Forstå koncepterne

Dette er hvad der er vigtigt. Tag fat i det større billede.

Du ved sandsynligvis hvad baggrundsfarve er, du ved måske hvad transformX gør, flyder, flexbox og gitter. Du kan læse om dem, hvordan du bruger og implementerer. Dette er ikke den svære del. (+ der er google til at hjælpe.)

Men hvad de fleste kæmper for er, hvordan alt er forbundet med hinanden. Hvorfor nogle beslutninger tages, og hvorfor folk elsker at opfinde deres egne rammer og navnekonventioner.

Du er nødt til at forstå, at den måde, du starter på, mere eller mindre vil definere hele strukturen af ​​projektet. Derfor er du nødt til at sikre dig, at du er opmærksom på de potentielle problemer, og hvordan du løser dem.

Først, lad os starte med, hvordan man får grundlæggende ned korrekt.

Der er masser af CSS-egenskaber derude. Du skal ikke gå og huske dem alle. Selve siden kaldes ”reference”. Du er ikke i skole, ingen vil bede dig om at navngive alle de grænseindstillinger, du kan angive via dit typografiark.

Men du vil huske dem, når du har brugt dem utallige gange. Når du ikke er sikker på, hvordan du bruger noget - Google det. Skriv det selv, leg rundt med indstillingerne og se resultatet.

Efter nogle måneders hårdt arbejde vil det være som at skrive hjemme.

Dette er vigtigt, fordi du ofte skal levere hurtigt. Det er, hvad projektlederen / lederen vil kræve af dig. Du skal ikke søge efter basale egenskaber meget tid.

At kende de fleste af egenskaberne vil også øge dine fejlfindingsevner meget. At vide, hvordan hver ejendom fungerer, og at den findes, sparer dig meget tid. Dette er grunden til, at erfarne udviklere kan håndtere mange problemer på få minutter.

https://xkcd.com/1350/

Du skal skrive en masse kode

Der er ingen vej omkring det. Det er det samme med alt i livet, du skal bruge en masse tid på det. Og her ligger et af de vigtigste spørgsmål, jeg ser, når folk spørger, hvordan de bliver bedre.

Hvad skal jeg skrive nøjagtigt?

Hvis du arbejder i et agentur eller som freelancer, har du sandsynligvis hvad du skal arbejde på, men hvis ikke, så her er et par tip:

Se hvordan de store fyre gør det

Hvis det er den første, har du sandsynligvis masser af tid til rådighed. Og det er godt, det betyder, at du er fri til at gøre, hvad du vil.

Og det føles fantastisk, mange vil misundes dig.

I så fald skal du gøre følgende: Gå til et sted, du beundrer. Bonuspoint, hvis det er med høj trafik. Begynd med at inspicere elementerne, se hvordan ingeniørerne har implementeret de specifikke komponenter / layout.

Nogle retninger om, hvad man skal kigge efter:

  • Brugte de en bestemt navnekonvention? Virksomheder som Airbnb, BBC og andre har retningslinjer for offentlig kode, du kan kigge efter dem.
  • Overskriver de en masse kode? Se, hvor mange egenskaber der overskrives af en bestemt klasse. Jo mindre - jo bedre, se hvordan de opnåede det.
  • Hvordan blev der virkelig opnået noget? En simpel tekst til venstre og et billede til højre kan vise sig at være meget vanskeligt, når billedet flyder uden for websitetens container, det klæber til bunden af ​​sektionen og overlejrer toppen, mens teksten er lodret centreret og hele dette reagerer.
  • Find forskellen mellem deres kode og din. Bruger du flere flydere, mere positionering, flere hacks? Det er meget sandsynligt, at hvad du gør hver dag, kan skrives på en meget enklere måde.

Men alt dette bliver kedeligt. Du kan ikke blive god ved bare at læse, du skal gøre noget. Og her er hvad du kan gøre hver eneste gang:

Prøv derefter at gøre det selv

Åben dribler for eksempel. Der er lige så mange fantastiske designs! Hvad laver du med dem? Gennemfør dem. Vælg nemme og prøv at gøre alt perfekt på alle skærme.

Hvorfor? Fordi det ser godt ud, og du vil føle dig stor, når du ser det fungere.

Bare sørg for ikke at bruge det, som om det er dit eget design, det vil ikke være cool. Opbevar det i dit lokale dev-miljø, eller skriv til designeren, hvis du vil gøre noget med det.

Se det på: https://dribbble.com/shots/3466131-Prism-Web-Tema-Template-designerbundle-com

Vælg derefter en udført af designer, der ikke synes godt om udviklerne. Et hvor alt overlejrer overalt, hvor gitter er et fremmed ord, der beskriver vægten af ​​en hval i bananer og farvekonsistens er et udtryk, der bruges af hipstere.

Hvorfor? Fordi det er svært. Det får dig til at tænke meget mere over, hvordan du organiserer din markup og stylings. Prøv at få det til at være pixel perfekt! Bonuspoint til animationer.

Eller hvis du også er en designer, så brug dine egne designs til at kode dem. Det er også en god praksis. Det var hvad jeg også gjorde, da jeg lavede min redesign til League of Legends-mesterens valgskærm for et par år tilbage.

Udfærdiget på mindre end to timer, kodet på cirka 6 timer, mens live streaming af det.

Du kan se den implementerede version her. Det reagerer ikke, da dette ikke var en del af den oprindelige plan. Du kan også se en timelapse-optagelse af hele processen.

Gennemgå din kode

Det er ikke kun det arbejde, du laver, det er også kvaliteten. Gennemse din gamle kode igen, og se efter mulige forbedringer.

Hvad fik dig til at omskrive dele af det? Hvad fik dig til at tilføje det skræmmende! Vigtigt? Kæmpede du med medieforespørgsler? Skrev du dybere vælgere på 4-5 niveauer?

Der er mange bedste fremgangsmåder at kigge efter. Her er bare et par af dem:

  1. 20 protips til skrivning af moderne CSS
  2. Modulære CSS-navnekonventioner
  3. Eller denne enorme retningslinje for stort set alt CSS.

At få bedre midler til at arbejde hurtigere, mere effektivt og med mindre fejl. Du skal prøve at få din side færdig fra første gang uden at skulle omskrive, redigere eller slette dele af koden.

Du skal planlægge fra starten!

Hvordan fungerer komponenterne med hinanden? Hvad er indlejret, hvad vil arve stilarter?

Du skal lære at planlægge godt

Det er afgørende. Helt fra starten, når du ser på de medfølgende mockups, prototyper eller designs, skal du planlægge dit layout og markup-struktur.

Hvad er elementerne, hvor bruges de mere end én gang. Er de på en eller anden måde forskellige? Er de forskellige ved de samme regler?

Alt dette vil fortælle dig, hvilken slags modifikatorer du har brug for, hvordan du strukturerer din markering, så du kan genbruge så meget som muligt.

Bemærk “fejlsøgning” og “nytænkning” :) Og ja, i stedet for at prøve at opfinde et supersmart automatiseringsværktøj, prøv at optimere alt først. Bare derefter, hvis det er nødvendigt, skal du tænke på automatisering .— https://xkcd.com/1319/

Denne planlægning sparer dig tid og penge senere. Jo mere projektet vokser, desto vigtigere er det at have et godt fundament. Det er noget, du ikke lærer med små projekter.

Og medmindre du har det godt med at kæmpe for at opretholde større codebase med mange mennesker, der arbejder på det, skal du sørge for at undersøge hele projektets rækkevidde og planlægge korrekt, hvordan du strukturerer alt.

For at få mest muligt ud af dette er andre udviklere kommet med navnekonventioner. Et sæt regler for, hvordan du navngiver dine komponenter, deres underordnede elementer, modifikatorer, værktøjer osv.

Og hver enkelt af dem tjener godt i forskellige projekter. Men hvis du kender omfanget og begrænsningerne godt nok, kan du vælge den bedste til dit projekt.

  • Igen, de modulære navnekonventioner fra sass-bloggen
  • En introduktion til objektorienteret CSS (OOCSS)
  • SMACSS
  • BEM
Hvordan det føles at kæmpe med CSS, når intet er organiseret. Overskrivning, finjustering, ændring og tilføjelse af flere og flere egenskaber vil ofte resultere i et rod, der let går i stykker.

Der er mange andre, du skal finde det, der passer bedst til dine behov. Men det, jeg foreslår dig, er at læse dokumentationen, årsagen og de problemer, disse konventioner løser.

Du bruger muligvis ikke nogen af ​​dem, men det er vigtigt at vide grunden til, at de findes.

TL; DR

  • Skriv så meget CSS som muligt. Hvis du ikke kan finde gode projekter at arbejde på, skal du få fat i et design et eller andet sted og implementere det.
  • Forbedre din kode hver gang. Prøv at skrive hver komponent på en smartere måde hver gang, mens du lærer, indtil du er tilfreds med din tilgang i det lange løb.
  • Lær af de store drenge - se, hvordan store websteder gør det. Se hvad du kan lære derfra og implementere det på dine projekter.
  • Brug eller i det mindste forstå, hvorfor der findes navnekonventioner. Ved, hvilke problemer de løser. Bestem, hvilken der er bedst til dit projekt.

CSS virker let, men der er lige så meget, der kan gå galt. Når du er gået forbi 5000 linjer, kan ting virkelig blive rodet. Dårlig planlægning får dig til at overskrive ting, forkerte medieforespørgsler vil udløse på uventede punkter, lydhøre regler kan blive mareridt.

For at blive bedre skal du læse meget om alle disse problemer, identificere dem ud fra din egen kode og planlægge, hvordan du strukturerer din applikation / site, så du ikke behøver at bekymre dig om dem i første omgang.

Hvis du kunne lide denne artikel, skal du ikke glemme at ramme hjerteikonet nedenfor.