Hvordan man skriver virkelig forfærdelige CSS

Alle taler om 'tip' og 'pro-tip' til at skrive god CSS.

Det er fint, men måske at se, hvordan dårlig CSS ser ud, vil give dig et andet perspektiv. Pokker, det kan endda gøre dig noget godt!

Lad mig tage dig gennem en rejse om, hvordan man skriver virkelig dårlig CSS.

Parat?

Bemærk: selvom du sværger ved CSS-in-JS og ikke elsker vanilje CSS, er vi alle enige om ting: vi skal alle stadig kende nogle CSS ...

Så uanset om du skriver CSS, eller noget supersæt som SASS, eller bare CSS-in-JS, vil du stadig drage fordel af at vide nøjagtigt, hvordan dårlig CSS ser ud.

Hvem skriver kommentarer? Ingen.

Ingen kommentarer? Faktisk kode skrev jeg for engang siden, men fjernede alle kommentarer

Det er så let at glide her, at du ikke bemærker meget hurtigt.

Vi ved alle det. Du er så smart, alle andre kommer ikke tæt på. Selvom CSS ikke er det mest udtryksfulde af "sprog", kan du tage antagelser om browservirksomheder, rette dem og antage, at du forstår, hvad du har gjort et par uger nede.

Hvor smart, ikke?

Læg din stolthed til side, og spar dig selv og andre holdkammerater stressen.

Hvis du bruger en ikke-så-åbenlyst teknik, eller har rettet et eller andet browservind, eller noget som helst, du synes ikke er udtrykkelig nok, skal du skrive den kommentar! Det gør ikke ondt.

Landet med komplekse vælgere

Yeah! Du har lige lært CSS og føler dig på toppen af ​​verden. Så tid til at vise nogle valgmuskler.

Dårligt træk.

Ved at foretage valg med for mange CSS-vælgere, har du muligvis gjort din CSS ekstrem uholdbar. Det er nu meget afhængig af HTML-strukturen i din app.

Hvis strukturen i markeringen ændres lidt, skal du også refaktorere din CSS. Ikke den nemmeste af arbejdsgange.

Bare tilføj en klasse til elementet og gå videre med livet!

Selv i scenarier, hvor du har brug for at kvalificere vælgere med flere klasser, foretrækker altid enkelhed.

Enkelt er godt, næsten altid!

Ydeevne? Ditch That!

Så jeg får det. Du er bare ligeglad med præstationer. Du er ligeglad med forretningen, helt klart. Hvis du gjorde det, ville du ikke irritere dine brugere med dine forfærdelige ikke-udøvende vælgere.

Men vent…

Jeg forstår, at computere er vokset hurtigere, og browsere bliver fortsat optimeret. Uanset hvad bør enkle vælgere altid foretrækkes, og det er stadig en ting at forstå, hvordan browseren kører gennem DOM for at finde din vælger!

Chancerne er, at du læser gennem dine vælgere fra venstre mod højre.

Browseren matcher imidlertid vælgerne fra højre til venstre, så den kan fjerne elementer, der ikke matcher så hurtigt som muligt.

Hvis du vidste dette, ville du sandsynligvis være mere mild på browserne. De fortjener din kærlighed.

I betragtning af eksemplet grafik ovenfor, vil browseren matche alle elementer (*) og også kontrollere, om de er efterkommere af kroppen.

krop * {
  ...
}

Men hvorfor? Næsten hvert synligt element er ideelt set en efterkommer af elementet. Det er bare en unødvendig ineffektiv kontrol.

Jeg sutter ved at navngive ting, så jeg gider ikke engang.

Der er kun 2 hårde ting inden for datalogi. At navngive ting og ...

Ja, jeg tror, ​​du allerede har hørt det et eller andet sted. At navngive ting kan være svært, men det betyder ikke, at du ikke bør tænke dem eller gå helt kryptisk ud.

Jeg tvivler på, at der er nogen situation, hvor det giver mening at bruge enkeltbogstaver som klassebetegnelser.

.u {
  skriftstørrelse: 60rem;
}

Og hvad med superspecifikke klassnavne?

.former-sort-nu-rød-afsnit {
  farve: rød;
}

De gør heller ikke noget godt.

Selvom navnet muligvis formidler en vis mening, har du sandsynligvis brudt en enorm del af klassens genanvendelighed. Hvilket for øvrig er den primære årsag til at have klasser.

Hvis du nu ønsker at style et almindeligt rødt afsnit, er det forrige navn bare så specifikt, ville det ikke give mening.

Brug meningsfulde navne, men overdriv det ikke.

Jeg hørte klasser var store. Overforbrug dem!

hmmm .... Undgå, når det er muligt, over modulariserede klasser

Undervisningen er stor, og alle elsker dem. Men som med alt andet er for meget af noget generelt en dårlig idé.

Du ser, hvis en gruppe af klasser for det meste vil blive brugt sammen, skal du bare gruppere dem i en klasse.

Når du vælger at gruppere er disse klasser måske subjektive. Hvis du bygger et atombibliotek af en eller anden art, kan du have en tendens til dette.

Hvis du skriver en stor app, er det sandsynligvis bedre at gruppere klasser på en meningsfuld måde i modsætning til at have masser af klasser på et enkelt element.

Undgå, når det er muligt, over modulariserede klasser.

Jeg er en CSS purist. Jeg gør ikke SASS, MINDRE osv.

Du er en CSS-purist, jeg er en CSS-purist, vi er begge purister. Lad os få det ud af vejen.

Nu til stridens knogle.

Der er bestemt brugssager, hvor det bare er at skrive vanilje CSS! For eksempel, hvis jeg ikke bruger en CSS-in-JS-løsning til mine React-projekter, kunne jeg beslutte at gå den rene CSS-rute. Det gør ikke ondt.

Hvis du skriver en stor app med masser af vanilje CSS der flyver rundt, er jeg klar over, at introduktion af en CSS-forarbejdningsvirksomhed vil gøre din udvikling mere interessant og bidrage til en mere vedligeholdelig CSS-kodebase.

Igen siger jeg ikke at bruge forbehandlere hver eneste gang. Jeg siger ikke bare lukke denne mulighed. Det kunne redde dig!

Du har en masse vigtig stil der!

Jeg hader CSS. Det fungerer bare aldrig. Så hvad er problemet?

Har masser af vigtige ting overalt, når jeg skal tilsidesætte erklæringer. Haha!

Selvom dette lyder som en anstændig plan for dit doede selv, vil overanvendelse af den! Vigtige regel kun resultere i et grovt uholdbart CSS-dokument.

Næste gang du skal bruge! Vigtigt, skal du være sikker på, at du ikke gør det, fordi du er for doven til at løse dine kaskadespørgsmål.

CSS er ikke så slemt. Omfavn det.

Vil du skrive Better CSS?

Jeg har oprettet en gratis CSS-guide til straks at få dine CSS-færdigheder til at blusse. Hent den gratis e-bog.

Syv CSS-hemmeligheder, som du ikke vidste om