In the following video I’m adding a red to the SVG with its center at the 300 point on the x-axis and 200 on the y-axis. …the width and height remain the same ( 700 units each), but the start of the coordinate system is now at the 300 point on the x-axis and 200 on the y-axis. ![]() ![]() The viewport we see starts where 0 on the x-axis and 0 on the y-axis meet. Here’s simplified markup showing the SVG viewBox and the width and height attributes both set on the : The last two are the width and height of the coordinate system inside the viewport - this is where we can edit the scale of the grid (which we’ll get into in the section on Zooming). The first two are the starting point at the upper-left corner ( x and y values, negative numbers allowed). We can specify any length unit we want, but if we provide unitless numbers, they default to pixels. Its dimensions are defined by width and height attributes, or in CSS with the corresponding width and height properties. The viewport is a window frame on the infinite canvas. SVG is an infinite canvas, but we can control what we see and how we see it through the viewport and the viewBox. There are a few additional things about the viewBox that are worth covering while we’re on the topic: How does the viewBox work? In this case, the best option will be to edit the viewBox to show that part of the coordinate system that was hidden:ĭemo applying overflow="hidden" and editing the viewBox. But if we also apply a background-color to the SVG or if we have other elements around it, things might look a little bit off. The easiest way to fix this? Add overflow="visible" to the SVG, whether it’s in our stylesheet, inline on the style attribute or directly as an SVG presentation attribute. If we were to open the file in some graphics editing program, it might look like this: Screenshot of SVG opened in Illustrator. The elements are there when they’re clipped - they’re just in a part of the coordinate system that we don’t see. At the same time, it can work against us when improperly configured, resulting in unwanted clipping. It’s technically fine to use inline SVG without it, but we would lose one of its most significant benefits: scaling with the container. The viewBox is a common point of confusion when working with SVG. ![]() In those cases, there are six specific things that I look for when I’m debugging. And because of that, we have the ability to scope things out and uncover any potential issues or opportunities to optimize the SVG.īut sometimes, we can’t even see our SVGs at all. Because it is part of the DOM, we can inspect any inline SVG in any browser DevTools. Someone recently asked me how I approach debugging inline SVGs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |