6 veelvoorkomende SVG-fouten (en hoe ze te verhelpen)

6 veelvoorkomende SVG-fouten (en hoe ze te verhelpen)

Iemand vroeg me onlangs hoe ik het debuggen van inline SVG's aanpak. Omdat het deel uitmaakt van de DOM, kunnen we elke inline SVG in elke browser DevTools inspecteren. En daarom hebben we de mogelijkheid om dingen uit te zoeken en mogelijke problemen of kansen te ontdekken om de SVG te optimaliseren.

Maar soms kunnen we onze SVG's helemaal niet zien. In die gevallen zijn er zes specifieke dingen waar ik naar op zoek ben tijdens het debuggen.

1. De viewBox waarden

De viewBox is een veel voorkomend punt van verwarring bij het werken met SVG. Het is technisch prima om inline SVG te gebruiken zonder dit, maar we zouden een van de belangrijkste voordelen ervan verliezen: schaalbaarheid met de container. Tegelijkertijd kan het tegen ons werken als het niet goed is geconfigureerd, wat resulteert in ongewenste clipping.

De elementen zijn er wanneer ze worden afgekapt — ze bevinden zich gewoon in een deel van het coördinatensysteem dat we niet zien. Als we het bestand zouden openen in een grafisch bewerkingsprogramma, zou het er zo uit kunnen zien:

Cat line art met een deel van de tekening buiten het illustratiegebied in Illustrator.
Screenshot van SVG geopend in Illustrator.

De gemakkelijkste manier om dit op te lossen? Toevoegen overflow="visible" naar de SVG, of het nu in onze stylesheet staat, inline op de style attribuut of rechtstreeks als een SVG-presentatieattribuut. Maar als we ook a background-color naar de SVG of als we er andere elementen omheen hebben, kan het er een beetje afwijkend uitzien. In dit geval is de beste optie om de viewBox om dat deel van het coördinatensysteem weer te geven dat verborgen was:

Demo aanvragen overflow="hidden" en het bewerken van de viewBox.

Er zijn een paar extra dingen over de viewBox die de moeite waard zijn om te behandelen terwijl we het over het onderwerp hebben:

Hoe doet de viewBox werken?

SVG is een oneindig canvas, maar we kunnen bepalen wat we zien en hoe we het zien via de viewport en de viewBox.

De uitkijk postje is een raamkozijn op het oneindige doek. De afmetingen worden bepaald door width en height attributen, of in CSS met de bijbehorende width en height eigenschappen. We kunnen elke lengte-eenheid specificeren die we willen, maar als we getallen zonder eenheid opgeven, zijn deze standaard pixels.

De viewBox wordt bepaald door vier waarden. De eerste twee zijn het startpunt in de linkerbovenhoek (x en y waarden, negatieve getallen toegestaan). Ik bewerk deze om de afbeelding opnieuw in te kaderen. De laatste twee zijn de breedte en hoogte van het coördinatensysteem binnen de viewport — hier kunnen we de schaal van het raster bewerken (waar we op ingaan in het gedeelte over inzoomen).

Hier is een vereenvoudigde opmaak die de SVG laat zien viewBox en width en height attributen beide ingesteld op de <svg>:

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

Herkaderen

Dus dit:

<svg viewBox="0 0 700 700">

… komt hierop overeen:

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

De viewport die we zien begint waar 0 op de x-as en 0 op de y-as elkaar ontmoeten.

Door dit te veranderen:

<svg viewBox="0 0 700 700">

…naar dit:

<svg viewBox="300 200 700 700">

…de breedte en hoogte blijven hetzelfde (700 eenheden elk), maar het begin van het coördinatensysteem is nu bij de 300 punt op de x-as en 200 op de y-as.

In de volgende video voeg ik een rood toe <circle> naar de SVG met het midden aan de 300 punt op de x-as en 200 op de y-as. Merk op hoe het veranderen van de viewBox coördinaten naar dezelfde waarden verandert ook de plaatsing van de cirkel in de linkerbovenhoek van het frame, terwijl de gerenderde grootte van de SVG hetzelfde blijft (700×700). Alles wat ik deed was dingen "herformuleren" met de viewBox.

inzoomen

We kunnen de laatste twee waarden binnen de wijzigen viewBox om in of uit te zoomen op de afbeelding. Hoe groter de waarden, hoe meer SVG-eenheden worden toegevoegd om in de viewport te passen, wat resulteert in een kleinere afbeelding. Als we een verhouding van 1:1 willen behouden, is onze viewBox breedte en hoogte moeten overeenkomen met de breedte- en hoogtewaarden van onze viewport.

Laten we eens kijken wat er in Illustrator gebeurt als we deze parameters wijzigen. Het tekengebied is de viewport die wordt weergegeven door een wit vierkant van 700px. Al het andere buiten dat gebied is ons oneindige SVG-canvas en wordt standaard afgekapt.

Figuur 1 hieronder toont een blauwe stip bij 900 langs de x-as en 900 langs de y-as. Als ik de laatste twee verander viewBox waarden van 700 naar 900 soortgelijk:

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

…dan is de blauwe stip bijna weer volledig in zicht, zoals te zien is in figuur 2 hieronder. Onze afbeelding is verkleind omdat we de viewBox-waarden hebben verhoogd, maar de werkelijke breedte- en hoogte-afmetingen van de SVG zijn hetzelfde gebleven en de blauwe stip is dichter bij het niet-uitgeknipte gebied teruggekomen.

Figuur 1.
Figuur 1
6 veel voorkomende SVG-fouten (en hoe u deze kunt oplossen) PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.
Figuur 2

Er is een roze vierkant als bewijs van hoe het raster wordt geschaald om in het kijkvenster te passen: de eenheid wordt kleiner en er passen meer rasterlijnen in hetzelfde kijkvenster. Je kunt met dezelfde waarden in de volgende pen spelen om dat werk in actie te zien:

2. Ontbrekend width en height

Een ander veelvoorkomend ding waar ik naar kijk bij het debuggen van inline SVG, is of de opmaak de width or height attributen. Dit is in veel gevallen niet erg, tenzij de SVG zich in een container met absolute positionering of een flexibele container bevindt (aangezien Safari de SVG berekent). width waarde met 0px in plaats van auto). Exclusief width or height verhindert in deze gevallen dat we het volledige beeld zien, zoals we kunnen zien door het openen van deze CodePen-demo en vergelijk het in Chrome, Safari en Firefox (tik op afbeeldingen voor grotere weergave).

6 veel voorkomende SVG-fouten (en hoe u deze kunt oplossen) PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.
Chrome
6 veel voorkomende SVG-fouten (en hoe u deze kunt oplossen) PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.
Safari
6 veel voorkomende SVG-fouten (en hoe u deze kunt oplossen) PlatoBlockchain Data Intelligence. Verticaal zoeken. Ai.
Firefox

De oplossing? Voeg een breedte of hoogte toe, als presentatiekenmerk, inline in het stijlkenmerk of in CSS. Vermijd het gebruik van de hoogte alleen, vooral wanneer deze is ingesteld op 100% or auto. Een andere oplossing is om zet het recht en links waarden.

Je kunt er mee spelen de volgende Pen en combineer de verschillende opties.

3. Onopzettelijk fill en stroke kleuren

Het kan ook zijn dat we kleur aanbrengen op de <svg> tag, of het nu een inline-stijl is of afkomstig is van CSS. Dat is prima, maar er kunnen andere kleurwaarden in de opmaak of stijlen zijn die in strijd zijn met de kleur die is ingesteld op de <svg>, waardoor onderdelen onzichtbaar zijn.

Daarom ben ik geneigd om op zoek te gaan naar de fill en stroke attributen in de opmaak van de SVG en wis ze uit. De volgende video toont een SVG die ik heb opgemaakt in CSS met een rood fill. Er zijn een aantal gevallen waarin delen van het SVG-bestand direct wit zijn ingevuld in de opmaak die ik heb verwijderd om de ontbrekende stukken te onthullen.

4. Ontbrekende ID's

Deze lijkt misschien super voor de hand liggend, maar het zou je verbazen hoe vaak ik hem zie verschijnen. Laten we zeggen dat we een SVG-bestand in Illustrator hebben gemaakt en zeer ijverig zijn geweest in het benoemen van onze lagen, zodat u bij het exporteren van het bestand mooie overeenkomende ID's in de opmaak krijgt. En laten we zeggen dat we van plan zijn om die SVG in CSS te stylen door aan die ID's te haken.

Dat is een leuke manier om dingen te doen. Maar er zijn genoeg momenten waarop ik hetzelfde SVG-bestand een tweede keer naar dezelfde locatie heb zien exporteren en de ID's anders zijn, meestal wanneer ik de vectoren rechtstreeks kopieer/plak. Misschien is er een nieuwe laag toegevoegd, of een van de bestaande is hernoemd of zoiets. Hoe het ook zij, de CSS-regels komen niet meer overeen met de ID's in de SVG-opmaak, waardoor de SVG anders wordt weergegeven dan u zou verwachten.

Onderstrepingstekens met cijfers na de element-ID's
Het geëxporteerde SVG-bestand van Illustrator in SVGOMG plakken.

In grote SVG-bestanden kunnen we het moeilijk vinden om die ID's te vinden. Dit is een goed moment om DevTools te openen, dat deel van de afbeelding dat niet werkt te inspecteren en te kijken of die ID's nog steeds overeenkomen.

Dus ik zou zeggen dat het de moeite waard is om een ​​geëxporteerd SVG-bestand in een code-editor te openen en het te vergelijken met het origineel voordat je dingen uitwisselt. Apps zoals Illustrator, Figma en Sketch zijn slim, maar dat betekent niet dat wij niet verantwoordelijk zijn voor het doorlichten ervan.

5. Checklist voor knippen en maskeren

Als een SVG onverwacht wordt afgekapt en het viewBox checkt goed uit, ik kijk meestal naar de CSS voor clip-path or mask eigenschappen die het beeld kunnen verstoren. Het is verleidelijk om naar de inline markup te blijven kijken, maar het is goed om te onthouden dat de styling van een SVG ergens anders kan plaatsvinden.

CSS knippen en maskeren stellen ons in staat delen van een afbeelding of element te "verbergen". SVG, <clipPath> is een vectorbewerking die delen van een afbeelding wegknipt zonder half resultaat. De <mask> tag is een pixelbewerking die transparantie, semi-transparantie-effecten en vervaagde randen mogelijk maakt.

Dit is een kleine checklist voor het debuggen van gevallen waarin knippen en maskeren een rol spelen:

  • Zorg ervoor dat het uitknippad (of masker) en de afbeelding elkaar overlappen. De overlappende delen worden weergegeven.
  • Als u een complex pad hebt dat uw afbeelding niet doorsnijdt, probeer dan transformaties toe te passen totdat ze overeenkomen.
  • U kunt de interne code nog steeds inspecteren met de DevTools, ook al is de <clipPath> or <mask> worden niet weergegeven, dus gebruik het!
  • Kopieer de opmaak naar binnen <clipPath> en <mask> en plak het voordat u het sluit </svg> label. Voeg dan een toe fill naar die vormen en controleer de coördinaten en afmetingen van de SVG. Als je de afbeelding nog steeds niet ziet, probeer dan toe te voegen overflow="hidden" aan de <svg> label.
  • Controleer dat een unieke ID wordt gebruikt voor de <clipPath> or <mask>en dat dezelfde ID wordt toegepast op de vormen of groep vormen die zijn geknipt of gemaskeerd. Een niet-overeenkomende ID zal het uiterlijk breken.
  • Controleer op typefouten in de opmaak tussen de <clipPath> or <mask> labels.
  • fill, stroke, opacity, of een andere stijl toegepast op de elementen binnenin <clipPath> zijn nutteloos - het enige bruikbare deel is de geometrie van het vulgebied van die elementen. Dat is waarom als je een <polyline> het zal zich gedragen als een <polygon> en als je een <line> je zult geen clipping-effect zien.
  • Als u uw afbeelding niet ziet na het aanbrengen van een <mask>, zorg ervoor dat het fill van de maskerende inhoud niet helemaal zwart is. De luminantie van het maskeerelement bepaalt de dekking van de uiteindelijke afbeelding. U kunt door de heldere delen heen kijken en de donkere delen verbergen de inhoud van uw afbeelding.

Je kunt spelen met gemaskeerde en geknipte elementen deze pen.

6. Naamruimten

Wist u dat SVG een op XML gebaseerde opmaaktaal is? Wel het is! De naamruimte voor SVG is ingesteld op de xmlns attribuut:

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

Er valt veel te weten over namespatie in XML en MDN heeft er een geweldige inleiding over. Het volstaat te zeggen dat de naamruimte context biedt aan de browser en hem informeert dat de opmaak specifiek is voor SVG. Het idee is dat naamruimten conflicten helpen voorkomen wanneer meer dan één type XML zich in hetzelfde bestand bevindt, zoals SVG en XHTML. Dit is een veel minder vaak voorkomend probleem in moderne browsers, maar zou kunnen helpen bij het verklaren van SVG-renderingsproblemen in oudere browsers of browsers zoals Gecko die strikt zijn bij het definiëren van doctypes en naamruimten.

De SVG 2-specificatie vereist geen naamruimte bij gebruik van HTML-syntaxis. Maar het is cruciaal als ondersteuning voor oudere browsers een prioriteit is - plus, het kan geen kwaad om het toe te voegen. Op die manier, wanneer de <html> element xmlns attribuut is gedefinieerd, zal het in die zeldzame gevallen niet conflicteren.

<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>

Dit geldt ook voor het gebruik van inline SVG in CSS, zoals het instellen als achtergrondafbeelding. In het volgende voorbeeld verschijnt er een vinkje op de invoer na succesvolle validatie. Zo ziet de CSS eruit:

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;
}

Wanneer we de naamruimte binnen de SVG in de achtergrondeigenschap verwijderen, verdwijnt de afbeelding:

Een ander veelvoorkomend naamruimtevoorvoegsel is xlink:href. We gebruiken het vaak bij het verwijzen naar andere delen van de SVG, zoals: patronen, filters, animaties of verlopen. De aanbeveling is om te beginnen met het vervangen ervan href aangezien de andere wordt afgeschaft sinds SVG 2, maar er kunnen compatibiliteitsproblemen zijn met oudere browsers. In dat geval kunnen we beide gebruiken. Vergeet niet om de naamruimte op te nemen xmlns:xlink="http://www.w3.org/1999/xlink" als je nog steeds gebruikt xlink:href.

Verbeter je SVG-vaardigheden!

Ik hoop dat deze tips u een hoop tijd helpen besparen als u merkt dat u problemen oplost met onjuist weergegeven inline SVG's. Dit zijn precies de dingen waar ik naar op zoek ben. Misschien heb je verschillende rode vlaggen waar je naar uitkijkt - zo ja, vertel het me dan in de reacties!

Het komt erop neer dat het loont om er op zijn minst een basiskennis van te hebben de verschillende manieren waarop SVG kan worden gebruikt. CodePen-uitdagingen bevatten vaak SVG en bieden goede praktijken. Hier zijn nog een paar bronnen om een ​​hoger niveau te bereiken:

Er zijn een paar mensen die ik voorstel om te volgen voor SVG-gerelateerde goedheid:

Tijdstempel:

Meer van CSS-trucs