Hvis du først og fremst er designer og nylig har begynt å lære CSS, har du sannsynligvis begynt å inkorporere noen av de nye CSS-funksjonene som er lagt til språket i CSS3 .

Men hvis du ikke har mye erfaring med CSS, prøver du sannsynligvis å finne ut hva som er den beste måten å håndtere noen av utfordringene som oppstår ved å bruke flere leverandørprefikser, som omhandler eldre versjoner av Internet Explorer, og andre CSS3-spesifikke dilemmaer.

I denne artikkelen vil jeg forsøke å dekke noen av de viktige tingene du må huske når du arbeider med disse problemene. Husk at ingenting her er satt i stein, men disse bør bare være retningslinjer for å hjelpe deg med å skrive mer effektive, enklere å vedlikeholde og fremtidssikre kode.

Kjenn støttekortene dine

Du vil sannsynligvis ikke måtte huske hvilke funksjoner som fungerer i hvilke nettlesere. I de fleste tilfeller fungerer ikke CSS3-funksjonene i alle nettlesere som er i bruk. Og i noen tilfeller har ikke de nyeste versjonene av nettlesere full støtte.

Så det første du bør gjøre er å forstå hvor støtten mangler. Den primære ressursen du bør bruke er Når kan jeg bruke ... nettsted, som inneholder diagrammer for CSS3, HTML5 og tonnevis. Du kan til og med gjøre side om side sammenligninger med forskjellige nettlesere, som vist på skjermbildet under det Sammenligner CSS3-støtte i Firefox 3.6 vs. IE9 :

Når kan jeg bruke ... støtte diagrammer

Selv om når kan jeg bruke ... er trolig den eneste støttetabellkilden du trenger, her er noen andre alternativer å vurdere:

Men vet at selv om en CSS-funksjon kan være oppført et sted som "støttet", betyr det ikke at det er uten feil eller inkonsekvenser. Så prøv grundig.

Ikke bruk overfylt polypyfill

På grunn av klientens eller byråets press, eller bare det faktum at du vil at alt skal se ut og fungere det samme overalt, kan du bli fristet til å bruke de mange CSS Polyfills .

Men mange av disse skriptene kan senke sidene dine betydelig - spesielt hvis du bruker mer enn én. Det er mange studier og kilder som viser betydningen av en nettside hastighet, så noen polyfills bør vurderes nøye og med nettstedet eller appens generelle beste interesser i tankene.

For å hjelpe deg med å avgjøre hva som skal brukes til polyfill og hva som bare skal tillate deg å redusere til en mindre opplevelse, bruk HTML5 Vennligst nettstedet. Som vist i skjermbildet nedenfor, vil HTML5 Vennligst anbefale å unngå polyfilter for bestemte funksjoner:

HTML5 Vennligst

Test hvordan funksjoner nedbrytes

Hvis du unngår mange polyfills, må du naturligvis tillate mange CSS3-funksjoner å bryte ned til en mer primitiv opplevelse i eldre nettlesere (vanligvis IE6-8). Men ikke antar at dette skjer automatisk.

I mange tilfeller (for eksempel når du bruker flere bakgrunner), må du erklære en egenskap som blir overskrevet av CSS3-funksjonen, men det vises fortsatt i eldre nettlesere.

For eksempel, for flere bakgrunner, kan du gjøre dette:

.element {background: url(images/fallback.jpg) no-repeat;background: url(images/example.png) center center no-repeat,url(images/example-2.png) top left repeat;}

Legg merke til det eneste bakgrunnsbildet som er deklarert før linjene med flere bakgrunnsbilder. Ikke-støttende nettlesere vil vise enkeltbildet, men ignorerer 2. linjen. Støttende nettlesere vil lese begge linjene, men den første linjen blir overskrevet av den andre.

Noen andre CSS3-funksjoner som kan ha nytte av denne typen fallback er RGBA-farger, HSLA-farger og gradienter.

For å hjelpe deg med å se hvordan CSS3-funksjonen nedbrytes i eldre nettlesere, kan du bruke et bokmerke som heter deCSS3 .

deCSS3

Den fungerer for øyeblikket bare i Chrome og Safari, men bare dra linken til bokmerkelinjen din og klikk deretter koblingen på et hvilket som helst nettsted du vil 'de-CSS3', og det vil vise deg nettstedet med tekstskygger, avrundede hjørner og andre nye ting fjernet. Selvfølgelig er dette ikke en erstatning for den faktiske nettlesertestingen, men kan tjene som en nyttig guide for raskere utvikling før du gjør den endelige testingen mot prosjektets slutt.

Et annet verktøy for å hjelpe til med å håndtere fallbacks er Modernizr JavaScript-biblioteket. Men hvis du er skremt av bibliotek, ikke vær. Modernizr er ikke vanskelig å håndtere fra et CSS-perspektiv. Sjekk ut denne opplæringen for en smertefri introduksjon.

Håndterer leverandør prefiks

En av de rotete delene av CSS3 har å gjøre med alle de forskjellige leverandørprefiksetene. Vedlikehold av kode som bruker alle prefiksene er kjedelig, og i noen tilfeller trenger du ikke alle dem. Hvem kan muligens huske når du skal inkludere "-o-" eller "-ms-" og når ikke?

Vel, som nevnt, vil hjelpeskjemaene hjelpe. Men her er noen andre forslag som hjelper til med å håndtere leverandørprefikser.

Bruk en CSS preprosessor

Preprosessorer er alle raseri akkurat nå. Men CSS nybegynnere og designere som ikke er hardcore utviklere eller programmerere, kan ha det vanskelig å håndtere disse nye verktøyene.

Så selv om preprosessorer er absolutt ikke for alle, er de definitivt verdt å vurdere, fordi de kan forbedre produksjon og vedlikeholdstid seriøst.

En omfattende diskusjon av preprosessorer er sikkert utenfor denne artikkelen, men her er noen koblinger for å komme i gang:

Og hvis du finner det for tungt, har Chris Coyier av CSS-Tricks noen tanker om preprosessorer som kan hjelpe deg med å få en samlet oversikt. Og her er et innlegg på Nettuts + som dekker noen av funksjonene og fordelene ved å bruke noen av de mest populære CSS preprosessorer.

Vær konsekvent i koden din

Hvis du velger å ikke forprosessere CSS ved hjelp av en av de nevnte teknologiene, må du håndtere alle leverandør prefikser. Så sørg for at du velger en stil og bestilling for leverandørens prefikser og holder deg til den. På denne måten blir koden din lettere å lese og vedlikeholde.

For eksempel setter noen CSS-utviklere sine leverandør prefiks linjer i alfabetisk rekkefølge, og bruker innrykk slik at verdiene alle linje opp slik:

.element {-moz-transition:    background-color linear .8s;-ms-transition:     background-color linear .8s;-o-transition:      background-color linear .8s;-webkit-transition:     background-color linear .8s;transition:     background-color linear .8s;}

Det er bare en måte å gjøre det på. Men uansett hvilken metode du velger, bare være konsekvent gjennom hele koden din. Dette ville være spesielt viktig hvis du jobber på et lag der andre må lese og / eller opprettholde koden din.

Selvfølgelig er ikke alle CSS3-funksjonene enkle å organisere (for eksempel er koden for keyframe-animasjoner mye mer komplisert), men for de fleste funksjoner bør du kunne ha en konsistent stil som gjør utviklingen og vedlikeholdet jevnere.

Hva med standardegenskapen?

Du vil legge merke til i eksemplet i forrige del, den siste eiendommen deklarert etter at leverandørlinjene er standardversjonen av eiendommen. Hvis du skal inkludere standardegenskapen, er dette definitivt hvordan du skal gjøre det. Så ta alltid med det sist når du legger til det.

Dette er for å sikre at leverandørens implementering av funksjonen blir overskrevet av standardimplementeringen. Men det er en advarsel her.

For noen komplekse animasjoner og interaksjoner er det tenkelig at implementeringen kan forandre seg så mye at når nettleseren begynner å støtte standardegenskapen, kan det få uønskede effekter. Så i noen tilfeller kan du være bedre å gå ut av standardegenskapen helt.

Jeg skrev om dette emnet mer grundig på bloggen min , så sjekk det ut hvis du vil ha en mer omfattende diskusjon om dette problemet.

Bruk Prefixr

En av de enkleste måtene å håndtere alle kryssbrowser-leverandørens rare er å bruke et praktisk lite verktøy som heter Prefixr . Med Prefixr utvikler du bare koden som alltid, og du kan bare bruke et enkelt leverandør prefiks (for eksempel bare "-moz-") for alle dine CSS3. Da, når du er ferdig med å teste i den ene nettleseren og ha alt som fungerer slik du vil, kan du bare kaste koden din til Prefixr og det vil generere all ekstra leverandørkoden for deg.

Prefiks kan også integreres automatisk med teksteditoren din , og inkluderer støtte for langvarig keyframe animasjonskode. Som et alternativ kan du også prøve et verktøy jeg opprettet kalt Animasjonsfyllingskode som legger til den ekstra leverandørkoden for keyframe-animasjoner.

Test grundig

Det siste forslaget jeg gir her er å teste grundig i alle nettleserne du støtter. Du kan bruke dusinvis av verktøy og biblioteker for å hjelpe deg med CSS3-utviklingen, men ingenting kan erstatte grundige tester i ekte nettlesermiljøer.

Og dette rådet vil være spesielt viktig hvis du arbeider med en rekke responsive designrelaterte CSS3 (f.eks. Medieforespørsler) og tung bruk av typografiske funksjoner. Du vil at innholdet ditt skal kunne brukes og leses i alle nettlesere, selv om CSS3-funksjonene ikke er tilgjengelige.