6 vanlige SVG-feil (og hvordan du fikser dem)

Noen spurte meg nylig hvordan jeg nærmer meg feilsøking av innebygde SVG-er. Fordi det er en del av DOM, kan vi inspisere alle innebygde SVG i alle nettleser DevTools. Og på grunn av det har vi muligheten til å kartlegge ting og avdekke potensielle problemer eller muligheter for å optimalisere SVG.

Men noen ganger kan vi ikke engang se SVG-ene våre i det hele tatt. I disse tilfellene er det seks spesifikke ting jeg ser etter når jeg feilsøker.

1. Den viewBox verdier

De viewBox er et vanlig forvirringspunkt når du arbeider med SVG. Det er teknisk sett greit å bruke inline SVG uten, men vi ville mistet en av de viktigste fordelene: skalering med beholderen. Samtidig kan den virke mot oss når den er feil konfigurert, noe som resulterer i uønsket klipping.

Elementene er der når de er klippet - de er bare i en del av koordinatsystemet som vi ikke ser. Hvis vi skulle åpne filen i et grafikkredigeringsprogram, kan det se slik ut:

Den enkleste måten å fikse dette på? Legge til overflow="visible" til SVG, enten det er i stilarket vårt, inline på style attributt eller direkte som et SVG-presentasjonsattributt. Men hvis vi også bruker en background-color til SVG eller hvis vi har andre elementer rundt det, kan ting se litt feil ut. I dette tilfellet vil det beste alternativet være å redigere viewBox for å vise den delen av koordinatsystemet som var skjult:

Det er noen flere ting om viewBox som er verdt å dekke mens vi er inne på emnet:

Hvordan gjør viewBox arbeide?

SVG er et uendelig lerret, men vi kan kontrollere hva vi ser og hvordan vi ser det gjennom visningsporten og viewBox.

De visningsport er en vindusramme på det uendelige lerretet. Dens dimensjoner er definert av width og height attributter, eller i CSS med tilsvarende width og height egenskaper. Vi kan spesifisere hvilken som helst lengdeenhet vi ønsker, men hvis vi gir tall uten enhet, er de som standard piksler.

De viewBox er definert av fire verdier. De to første er startpunktet i øvre venstre hjørne (x og y verdier, negative tall tillatt). Jeg redigerer disse for å reframe bildet. De to siste er bredden og høyden til koordinatsystemet inne i visningsporten - det er her vi kan redigere skalaen til rutenettet (som vi kommer inn på i avsnittet om zooming).

Her er forenklet markering som viser SVG viewBox og width og height attributter begge satt på <svg>:

<svg viewBox="0 0 700 700" width="700" height="700"> <!-- etc. -->
</svg>

Omramning

Så dette:

<svg viewBox="0 0 700 700">

…kart til dette:

<svg viewBox="start-x-axis start-y-axis width height">

Viewporten vi ser starter hvor 0 på x-aksen og 0 på y-aksen møtes.

Ved å endre dette:

<svg viewBox="0 0 700 700">

…til dette:

<svg viewBox="300 200 700 700">

...bredden og høyden forblir den samme (700 enheter hver), men starten av koordinatsystemet er nå ved 300 punkt på x-aksen og 200 på y-aksen.

I den følgende videoen legger jeg til en rød <circle> til SVG med sentrum ved 300 punkt på x-aksen og 200 på y-aksen. Legg merke til hvordan du endrer viewBox koordinater til de samme verdiene endrer også sirkelens plassering til øvre venstre hjørne av rammen mens den gjengitte størrelsen på SVG forblir den samme (700×700). Alt jeg gjorde var å "reframe" ting med viewBox.

zooming

Vi kan endre de to siste verdiene inne i viewBox for å zoome inn eller ut av bildet. Jo større verdiene er, desto flere SVG-enheter legges til for å passe inn i visningsporten, noe som resulterer i et mindre bilde. Hvis vi ønsker å beholde et forhold på 1:1, er vår viewBox bredde og høyde må samsvare med verdiene for visningsportens bredde og høyde.

La oss se hva som skjer i Illustrator når vi endrer disse parameterne. Tegnebrettet er viewport som er representert av en hvit firkant på 700px. Alt annet utenfor dette området er vårt uendelige SVG-lerret og blir klippet som standard.

Figur 1 nedenfor viser en blå prikk kl 900 langs x-aksen og 900 langs y-aksen. Hvis jeg endrer de to siste viewBox verdier fra 700 til 900 som dette:

<svg viewBox="300 200 900 900" width="700" height="700">

…så er den blå prikken nesten helt synlig igjen, som vist i figur 2 nedenfor. Bildet vårt er nedskalert fordi vi økte viewBox-verdiene, men SVGs faktiske bredde- og høydedimensjoner forble de samme, og den blå prikken kom tilbake nærmere det uklippede området.

Det er en rosa firkant som bevis på hvordan rutenettet skaleres for å passe til visningsporten: enheten blir mindre, og flere rutenettlinjer passer inn i det samme visningsportområdet. Du kan spille med de samme verdiene i følgende penn for å se at det fungerer i aksjon:

2. Savnet width og height

En annen vanlig ting jeg ser på når jeg feilsøker inline SVG er om markeringen inneholder width or height attributter. Dette er ingen stor sak i mange tilfeller med mindre SVG er inne i en beholder med absolutt posisjonering eller en fleksibel beholder (som Safari beregner SVG width verdi med 0px istedenfor auto). Ekskludert width or height i disse tilfellene hindrer oss i å se hele bildet, som vi kan se ved åpne denne CodePen-demoen og sammenligne det i Chrome, Safari og Firefox (trykk på bilder for større visning).

Løsningen? Legg til en bredde eller høyde, enten som presentasjonsattributt, innebygd i stilattributtet eller i CSS. Unngå å bruke høyden alene, spesielt når den er satt til 100% or auto. En annen løsning er å sette rett og venstre verdier.

Du kan leke med følgende penn og kombinere de ulike alternativene.

3. Utilsiktet fill og stroke farger

Det kan også være at vi bruker farge på <svg> tag, enten det er en innebygd stil eller kommer fra CSS. Det er greit, men det kan være andre fargeverdier gjennom markeringen eller stiler som er i konflikt med fargesettet på <svg>, noe som gjør at deler blir usynlige.

Det er derfor jeg pleier å se etter fill og stroke attributter i SVGs markering og slett dem. Følgende video viser en SVG jeg stylet i CSS med en rød fill. Det er et par tilfeller der deler av SVG er fylt med hvitt direkte i markeringen som jeg fjernet for å avsløre de manglende delene.

4. Manglende IDer

Denne kan virke veldig åpenbar, men du vil bli overrasket over hvor ofte jeg ser den dukke opp. La oss si at vi laget en SVG-fil i Illustrator og var veldig flittige med å navngi lagene våre slik at du får fine matchende IDer i markeringen når du eksporterer filen. Og la oss si at vi planlegger å style den SVG-en i CSS ved å koble til disse ID-ene.

Det er en fin måte å gjøre ting på. Men det er mange ganger hvor jeg har sett den samme SVG-filen eksportert en gang til til samme sted, og ID-ene er forskjellige, vanligvis når du kopierer/limer inn vektorene direkte. Kanskje et nytt lag ble lagt til, eller et av de eksisterende ble omdøpt eller noe. Uansett, CSS-reglene samsvarer ikke lenger med ID-ene i SVG-oppmerkingen, noe som fører til at SVG-en gjengis annerledes enn du forventer.

I store SVG-filer kan vi finne det vanskelig å finne disse IDene. Dette er et godt tidspunkt å åpne DevTools, inspisere den delen av grafikken som ikke fungerer, og se om disse IDene fortsatt samsvarer.

Så jeg vil si at det er verdt å åpne en eksportert SVG-fil i en koderedigerer og sammenligne den med originalen før du bytter ut ting. Apper som Illustrator, Figma og Sketch er smarte, men det betyr ikke at vi ikke er ansvarlige for å vurdere dem.

5. Sjekkliste for klipping og maskering

Hvis en SVG uventet klippes og viewBox sjekker ut greit, jeg pleier å se på CSS for clip-path or mask egenskaper som kan forstyrre bildet. Det er fristende å fortsette å se på den innebygde markeringen, men det er greit å huske at en SVGs styling kan skje andre steder.

CSS klipping og maskering tillate oss å "skjule" deler av et bilde eller element. I SVG, <clipPath> er en vektoroperasjon som kutter deler av et bilde uten halvveis resultater. De <mask> tag er en pikseloperasjon som tillater gjennomsiktighet, semi-transparenseffekter og uskarpe kanter.

Dette er en liten sjekkliste for feilsøkingssaker der klipping og maskering er involvert:

• Sørg for at klippebanen (eller masken) og grafikken overlapper hverandre. De overlappende delene er det som vises.
• Hvis du har en kompleks bane som ikke krysser grafikken din, prøv å bruke transformasjoner til de samsvarer.
• Du kan fortsatt inspisere den indre koden med DevTools selv om <clipPath> or <mask> er ikke gjengitt, så bruk det!
• Kopier markeringen inni <clipPath> og <mask> og lim den inn før du lukker </svg> stikkord. Legg deretter til en fill til disse formene og kontroller SVGs koordinater og dimensjoner. Hvis du fortsatt ikke ser bildet, prøv å legge til overflow="hidden" til <svg> tag.
• Sjekk at a unik ID brukes til <clipPath> or <mask>, og at samme ID brukes på figurene eller gruppen av figurer som er klippet eller maskert. En mismatch ID vil ødelegge utseendet.
• Se etter skrivefeil i markeringen mellom <clipPath> or <mask> tags.
• fill, stroke, opacity, eller noen andre stiler brukt på elementene inni <clipPath> er ubrukelige - den eneste nyttige delen er fyllområdegeometrien til disse elementene. Det er derfor hvis du bruker en <polyline> den vil oppføre seg som en <polygon> og hvis du bruker en <line> du vil ikke se noen klippeeffekt.
• Hvis du ikke ser bildet ditt etter å ha brukt en <mask>, sørg for at fill av maskeringsinnholdet er ikke helt svart. Luminansen til maskeringselementet bestemmer opasiteten til den endelige grafikken. Du vil kunne se gjennom de lysere delene, og de mørkere delene vil skjule bildets innhold.

Du kan leke med maskerte og klippede elementer i denne pennen.

6. Navneområder

Visste du at SVG er et XML-basert merkespråk? Vel, det er det! Navneområdet for SVG er satt på xmlns Egenskap:

<svg xmlns="http://www.w3.org/2000/svg"> <!-- etc. -->
</svg>

Det er mye å vite om navneavstand i XML, og MDN har en flott primer på den. Det er nok å si at navneområdet gir kontekst til nettleseren, og informerer den om at markeringen er spesifikk for SVG. Tanken er at navnerom bidrar til å forhindre konflikter når mer enn én type XML er i samme fil, som SVG og XHTML. Dette er et mye mindre vanlig problem i moderne nettlesere, men kan bidra til å forklare SVG-gjengivelsesproblemer i eldre nettlesere eller nettlesere som Gecko som er strenge når de definerer dokumenttyper og navneområder.

SVG 2-spesifikasjonen krever ikke navneavstand når du bruker HTML-syntaks. Men det er avgjørende hvis støtte for eldre nettlesere er en prioritet – pluss at det ikke skader noe å legge det til. På den måten, når <html> elementets xmlns attributtet er definert, vil det ikke være i konflikt i de sjeldne tilfellene.

<html lang="en" xmlns="http://www.w3.org/1999/xhtml"> <body> <svg xmlns="http://www.w3.org/2000/svg" width="700px" height="700px"> <!-- etc. --> </svg> </body>
</html>

Dette gjelder også når du bruker inline SVG i CSS, som å sette det som et bakgrunnsbilde. I det følgende eksempelet vises et hakeikon på inngangen etter vellykket validering. Slik ser CSS ut:

textarea:valid { background: white url('data:image/svg+xml, <svg xmlns="http://www.w3.org/2000/svg" width="26" height="26"> <circle cx="13" cy="13" r="13" fill="%23abedd8"/> <path fill="none" stroke="white" stroke-width="2" d="M5 15.2l5 5 10-12"/> </svg>') no-repeat 98% 5px;
}

Når vi fjerner navneområdet inne i SVG i bakgrunnsegenskapen, forsvinner bildet:

Et annet vanlig navneområdeprefiks er xlink:href. Vi bruker det mye når vi refererer til andre deler av SVG som: mønstre, filtre, animasjoner eller gradienter. Anbefalingen er å begynne å erstatte den med href som den andre har blitt avviklet siden SVG 2, men det kan være kompatibilitetsproblemer med eldre nettlesere. I så fall kan vi bruke begge deler. Bare husk å inkludere navneområdet xmlns:xlink="http://www.w3.org/1999/xlink" hvis du fortsatt bruker xlink:href.

Oppgrader SVG-ferdighetene dine!

Jeg håper disse tipsene hjelper deg å spare massevis av tid hvis du finner deg selv i å feilsøke feilaktig gjengitte innebygde SVG-er. Dette er bare de tingene jeg ser etter. Kanskje du har forskjellige røde flagg du ser etter - hvis ja, fortell meg i kommentarfeltet!

Poenget er at det lønner seg å ha minst en grunnleggende forståelse av de ulike måtene SVG kan brukes på. CodePen-utfordringer ofte innlemme SVG og tilby god praksis. Her er noen flere ressurser for å gå opp i nivå:

Det er noen få personer jeg foreslår å følge for SVG-relatert godhet:

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://css-tricks.com/6-common-svg-fails-and-how-to-fix-them/