6 almindelige SVG-fejl (og hvordan man løser dem)

Nogen spurgte mig for nylig, hvordan jeg griber debugging ind i SVG'er an. Fordi det er en del af DOM, kan vi inspicere enhver inline SVG i enhver browser DevTools. Og på grund af det har vi muligheden for at scope tingene ud og afdække eventuelle potentielle problemer eller muligheder for at optimere SVG.

Men nogle gange kan vi slet ikke se vores SVG'er. I disse tilfælde er der seks specifikke ting, jeg kigger efter, når jeg fejlretter.

1. Det viewBox værdier

viewBox er et almindeligt forvirringspunkt, når man arbejder med SVG. Det er teknisk set fint at bruge inline SVG uden det, men vi ville miste en af ​​dens vigtigste fordele: skalering med containeren. Samtidig kan den virke imod os, når den er forkert konfigureret, hvilket resulterer i uønsket klipning.

Elementerne er der, når de klippes - de er bare i en del af koordinatsystemet, som vi ikke kan se. Hvis vi skulle åbne filen i et grafikredigeringsprogram, kunne det se sådan ud:

Den nemmeste måde at løse dette på? Tilføje overflow="visible" til SVG, uanset om det er i vores stylesheet, inline på style attribut eller direkte som en SVG-præsentationsattribut. Men hvis vi også anvender en background-color til SVG, eller hvis vi har andre elementer omkring det, kan tingene se lidt skævt ud. I dette tilfælde vil den bedste mulighed være at redigere viewBox for at vise den del af koordinatsystemet, der var skjult:

Der er et par ekstra ting om viewBox som er værd at dække, mens vi er inde på emnet:

Hvordan gør viewBox arbejde?

SVG er et uendeligt lærred, men vi kan kontrollere, hvad vi ser, og hvordan vi ser det gennem visningsporten og viewBox.

visning er en vinduesramme på det uendelige lærred. Dens dimensioner er defineret af width , height attributter, eller i CSS med de tilsvarende width , height ejendomme. Vi kan angive en hvilken som helst længdeenhed, vi ønsker, men hvis vi giver tal uden enhed, er de som standard pixels.

viewBox er defineret af fire værdier. De to første er udgangspunktet i øverste venstre hjørne (x , y værdier, negative tal tilladt). Jeg redigerer disse for at omramme billedet. De sidste to er bredden og højden af ​​koordinatsystemet inde i viewporten - det er her vi kan redigere skalaen af ​​gitteret (som vi kommer ind på i afsnittet om Zoome).

Her er forenklet opmærkning, der viser SVG viewBox og width , height attributter begge indstillet på <svg>:

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

Omramning

Så dette:

<svg viewBox="0 0 700 700">

…kort til dette:

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

Udsigten vi ser starter hvor 0 på x-aksen og 0 på y-aksen mødes.

Ved at ændre dette:

<svg viewBox="0 0 700 700">

…Til dette:

<svg viewBox="300 200 700 700">

...bredden og højden forbliver den samme (700 enheder hver), men starten af ​​koordinatsystemet er nu ved 300 punkt på x-aksen og 200 på y-aksen.

I den følgende video tilføjer jeg en rød <circle> til SVG med centrum ved 300 punkt på x-aksen og 200 på y-aksen. Bemærk, hvordan du ændrer viewBox koordinater til de samme værdier ændrer også cirklens placering til det øverste venstre hjørne af rammen, mens den gengivne størrelse af SVG forbliver den samme (700×700). Alt, hvad jeg gjorde, var at "reframe" tingene med viewBox.

Zoome

Vi kan ændre de sidste to værdier inde i viewBox for at zoome ind eller ud af billedet. Jo større værdierne er, jo flere SVG-enheder tilføjes for at passe ind i viewporten, hvilket resulterer i et mindre billede. Hvis vi vil beholde et 1:1 forhold, er vores viewBox bredde og højde skal matche vores værdier for visningsportens bredde og højde.

Lad os se, hvad der sker i Illustrator, når vi ændrer disse parametre. Tegnebrættet er viewport som er repræsenteret af en hvid 700px firkant. Alt andet uden for dette område er vores uendelige SVG-lærred og bliver klippet som standard.

Figur 1 nedenfor viser en blå prik ved 900 langs x-aksen og 900 langs y-aksen. Hvis jeg ændrer de to sidste viewBox værdier fra 700 til 900 sådan her:

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

…så er den blå prik næsten helt synlig igen, som det ses i figur 2 nedenfor. Vores billede er nedskaleret, fordi vi øgede viewBox-værdierne, men SVG's faktiske bredde og højdedimensioner forblev de samme, og den blå prik kom tilbage tættere på det uklippede område.

Der er en lyserød firkant som bevis på, hvordan gitteret skaleres til at passe til viewporten: Enheden bliver mindre, og flere gitterlinjer passer ind i det samme viewport-område. Du kan spille med de samme værdier i følgende pen for at se, hvordan det virker:

2. Mangler width , height

En anden almindelig ting, jeg ser på, når jeg fejlretter inline SVG, er, om opmærkningen indeholder width or height egenskaber. Dette er ikke noget problem i mange tilfælde, medmindre SVG'en er inde i en beholder med absolut positionering eller en fleksibel beholder (som Safari beregner SVG'en width værdi med 0px i stedet for auto). Eksklusiv width or height i disse tilfælde forhindrer os i at se det fulde billede, som vi kan se ved åbner denne CodePen-demo og sammenligne det i Chrome, Safari og Firefox (tryk på billeder for større visning).

Løsningen? Tilføj en bredde eller højde, enten som en præsentationsattribut, inline i stilattributten eller i CSS. Undgå at bruge højden alene, især når den er indstillet til 100% or auto. En anden løsning er at sæt det rigtige , venstre værdier.

Du kan lege med følgende Pen og kombinere de forskellige muligheder.

3. Utilsigtet fill , stroke Bruges kolde farver

Det kan også være, at vi anvender farve på <svg> tag, uanset om det er en inline-stil eller kommer fra CSS. Det er fint, men der kan være andre farveværdier i hele markeringen eller stilarter, der er i konflikt med farvesættet på <svg>, hvilket får dele til at være usynlige.

Det er derfor, jeg plejer at lede efter fill , stroke attributter i SVG's markering og udslette dem. Den følgende video viser en SVG, jeg har stylet i CSS med en rød fill. Der er et par tilfælde, hvor dele af SVG er udfyldt med hvidt direkte i markeringen, som jeg fjernede for at afsløre de manglende stykker.

4. Manglende ID'er

Denne kan virke super indlysende, men du vil blive overrasket over, hvor ofte jeg ser den dukke op. Lad os sige, at vi lavede en SVG-fil i Illustrator og var meget flittige til at navngive vores lag, så du får pæne matchende id'er i opmærkningen, når du eksporterer filen. Og lad os sige, at vi planlægger at style den SVG i CSS ved at tilslutte os disse ID'er.

Det er en fin måde at gøre tingene på. Men der er masser af gange, hvor jeg har set den samme SVG-fil eksporteret en anden gang til den samme placering, og ID'erne er forskellige, normalt når du kopierer/indsætter vektorerne direkte. Måske blev der tilføjet et nyt lag, eller et af de eksisterende blev omdøbt eller noget. Uanset hvad, matcher CSS-reglerne ikke længere ID'erne i SVG-opmærkningen, hvilket får SVG til at gengive anderledes, end du ville forvente.

I store SVG-filer kan det være svært at finde disse ID'er. Dette er et godt tidspunkt at åbne DevTools, inspicere den del af grafikken, der ikke fungerer, og se om disse ID'er stadig matcher.

Så jeg vil sige, at det er værd at åbne en eksporteret SVG-fil i en kodeeditor og sammenligne den med originalen, før du skifter ting ud. Apps som Illustrator, Figma og Sketch er smarte, men det betyder ikke, at vi ikke er ansvarlige for at undersøge dem.

5. Tjekliste til klipning og maskering

Hvis en SVG uventet klippes, og den viewBox tjekker ud okay, jeg plejer at se på CSS for clip-path or mask egenskaber, der kan forstyrre billedet. Det er fristende at blive ved med at se på inline-markeringen, men det er godt at huske, at en SVG's styling kan finde sted andre steder.

CSS klipning og maskering tillade os at "skjule" dele af et billede eller element. I SVG, <clipPath> er en vektoroperation, der skærer dele af et billede uden halvvejsresultater. Det <mask> tag er en pixeloperation, der tillader gennemsigtighed, semi-transparenseffekter og slørede kanter.

Dette er en lille tjekliste til fejlretningssager, hvor klipning og maskering er involveret:

• Sørg for, at fritlægningskurven (eller masken) og grafikken overlapper hinanden. De overlappende dele er, hvad der bliver vist.
• Hvis du har en kompleks sti, der ikke krydser din grafik, kan du prøve at anvende transformationer, indtil de matcher.
• Du kan stadig inspicere den indre kode med DevTools, selvom den <clipPath> or <mask> er ikke gengivet, så brug det!
• Kopier opmærkningen indeni <clipPath> , <mask> og indsæt det, før du lukker </svg> tag. Tilføj derefter a fill til disse former og kontroller SVG'ens koordinater og dimensioner. Hvis du stadig ikke kan se billedet, så prøv at tilføje overflow="hidden" til <svg> tag.
• Tjek at a enestående ID bruges til <clipPath> or <mask>, og at det samme ID anvendes på figurerne eller gruppen af ​​figurer, der er klippet eller maskeret. Et forkert id vil ødelægge udseendet.
• Tjek for stavefejl i markeringen mellem <clipPath> or <mask> tags.
• fill, stroke, opacity, eller nogle andre stilarter anvendt på elementerne indeni <clipPath> er ubrugelige — den eneste nyttige del er fyldområdegeometrien af ​​disse elementer. Det er derfor, hvis du bruger en <polyline> det vil opføre sig som en <polygon> og hvis du bruger en <line> du vil ikke se nogen klipningseffekt.
• Hvis du ikke kan se dit billede efter påføring af en <mask>, sørg for, at fill af maskeringsindholdet er ikke helt sort. Maskeringselementets luminans bestemmer opaciteten af ​​den endelige grafik. Du vil være i stand til at se gennem de lysere dele, og de mørkere dele vil skjule dit billedes indhold.

Du kan lege med maskerede og klippede elementer i denne Pen.

6. Navneområder

Vidste du, at SVG er et XML-baseret opmærkningssprog? Nå, det er det! Navneområdet for SVG er indstillet på xmlns attribut:

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

Der er meget at vide om navneafstand i XML, og MDN har en god primer på det. Det er tilstrækkeligt at sige, at navneområdet giver kontekst til browseren og informerer den om, at opmærkningen er specifik for SVG. Ideen er, at navnerum hjælper med at forhindre konflikter, når mere end én type XML er i den samme fil, som SVG og XHTML. Dette er et meget mindre almindeligt problem i moderne browsere, men det kan hjælpe med at forklare SVG-gengivelsesproblemer i ældre browsere eller browsere som Gecko, der er strenge, når de definerer doctypes og navnerum.

SVG 2-specifikationen kræver ikke navnemellemrum når du bruger HTML-syntaks. Men det er afgørende hvis understøttelse af ældre browsere er en prioritet - plus, det skader ikke noget at tilføje det. På den måde, når <html> elementets xmlns attribut er defineret, vil den ikke være i konflikt i de sjældne tilfælde.

<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 gælder også, når du bruger inline SVG i CSS, som at indstille det som et baggrundsbillede. I det følgende eksempel vises et afkrydsningsikon på inputtet efter vellykket validering. Sådan ser CSS'en ud:

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 inde i SVG i baggrundsegenskaben, forsvinder billedet:

Et andet almindeligt navneområdepræfiks er xlink:href. Vi bruger det meget, når vi refererer til andre dele af SVG som: mønstre, filtre, animationer eller gradienter. Anbefalingen er at begynde at udskifte den med href da den anden er ved at blive forældet siden SVG 2, men der kan være kompatibilitetsproblemer med ældre browsere. I så fald kan vi bruge begge dele. Bare husk at inkludere navneområdet xmlns:xlink="http://www.w3.org/1999/xlink" hvis du stadig bruger xlink:href.

Opgrader dine SVG-færdigheder!

Jeg håber, at disse tips hjælper dig med at spare en masse tid, hvis du finder dig selv i fejlfinding af forkert gengivet inline SVG'er. Det er bare de ting, jeg leder efter. Måske har du forskellige røde flag, du holder øje med - hvis ja, fortæl mig det i kommentarerne!

Den nederste linje er, at det kan betale sig at have mindst en grundlæggende forståelse af de forskellige måder SVG kan bruges på. CodePen udfordringer inkorporerer ofte SVG og tilbyder god praksis. Her er et par flere ressourcer til at stige i niveau:

Der er et par personer, jeg foreslår at følge for SVG-relateret godhed:

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://css-tricks.com/6-common-svg-fails-and-how-to-fix-them/