Quick Introduction

It’s been 10 years since scroll-driven animations were introduced in a spec proposal, and after five years in development, we’re finally beginning to see pop up in websites. There are scrolly-telling and maze games as well as cover flow animations and 3D rotation with scroll… but what exactly is new here? It’s not like we haven’t seen scroll animations before, but what we have now requires no JavsScript, no dependencies, no libraries —just pure CSS. And if that’s not exciting enough, these animations run off the main thread, delivering smooth, high-performance, GPU-accelerated experiences.

Introduction

You can safely use scroll-driven animations in Chrome as of December 2024. Firefox supports them too, though you’ll need to enable a flag. Safari? Not yet, but don’t worry —you can still offer a seamless experience across all browsers with a polyfill. Just keep in mind that adding a polyfill involves a JavaScript library, so you won’t get the same performance boost.

There are plenty of valuable resources to dive into scroll-driven animations, which I’ll be linking throughout the article. My starting point was Bramus' video tutorial, which pairs nicely with Geoff Graham's in-depth notes that build on the tutorial.

In this article, we’ll walk through the latest published version by the W3C and explore the two types of scroll-driven timelines — scroll progress timelines and view progress timelines. By the end, I hope that you are familiar with both timelines, not only being able to tell them apart but also feeling confident enough to use them in your work.

Please note that all demos in this article only work in Chrome 116 or later at the time of writing.

Scroll Progress Timelines

The scroll progress timeline links an animation’s timeline to the scroll position of a scroll container along a specific axis. So, the animation is tied directly to scrolling. As you scroll forward so, too, does the animation. You’ll see me refer to them as scroll-timeline animations in addition to calling them scroll progress timelines.

Just as we have two types of scroll-driven animations, we have two types of scroll-timeline animations: anonymous timelines and named timelines.

Anonymous scroll-timeline

Let’s start with a classic example: creating a scroll progress bar at the top of a blog post to track your reading progress.

https://codepen.io/marianab/pen/Vwozevx

In this example, there’s a <div> with the ID "progress." At the end of the CSS file, you’ll see it has a background color, a defined width and height, and it’s fixed at the top of the page. There’s also an animation that scales it from 0 to 1 along the x-axis — pretty standard if you’re familiar with CSS animations!

Here’s the relevant part of the styles:

    #progress {
      /* ... */
      animation: progressBar 1s linear;
    }


    @keyframes progressBar {
      from { transform: scaleX(0); }
    }

The progressBar animation runs once and lasts one second with a linear timing function. Linking this animation scrolling is just a single line in CSS:

    animation-timeline: scroll();

No need to specify seconds for the duration — the scrolling behavior itself will dictate the timing. And that’s it! You’ve just created your first scroll-driven animation! Notice how the animation’s direction is directly tied to the scrolling direction — scroll down and the progress indicator grows wider; scroll up and it becomes narrower.

https://codepen.io/marianab/pen/OJKjMVq

scroll-timeline Property Parameters

In a scroll-timeline animation, the scroll() function is used inside the animation-timeline property. It only takes two parameters: <scroller> and <axis>.

• scroller> refers to the scroll container, which can be set as nearest (the default), root, or self.
• <axis> refers to the scroll axis, which can be block (the default), inline, x, or y.

In the reading progress example above, we didn’t declare any of these because we used the defaults. But we could achieve the same result with:

    animation-timeline: scroll(nearest block);

Here, the nearest scroll container is the root scroll of the HTML element. So, we could also write it this way instead:

    animation-timeline: scroll(root block);

The block axis confirms that the scroll moves top to bottom in a left-to-right writing mode. If the page has a wide horizontal scroll, and we want to animate along that axis, we could use the inline or x values (depending on whether we want the scrolling direction to always be left-to-right or adapt based on the writing mode).

We’ll dive into self and inline in more examples later, but the best way to learn is to play around with all the combinations and this tool by Bramus lets you do exactly that. Spend a few minutes in before we jump into the next property associated with scroll timelines.

The animation-range Property

The animation-range for scroll-timeline defines which part of the scrollable content controls the start and end of an animation's progress, based on the scroll position. It allows you to decide when the animation starts or ends while scrolling through the container.

By default, the animation-range is set to normal which is shorthand for:

    animation-range-start: normal;
    animation-range-end: normal;

This translates to 0% (start) and 100% (end) in a scroll-timeline animation:

    animation-range: normal normal;

…which is the same as:

    animation-range: 0% 100%;

You can declare any CSS length units or even calculations. For example, let’s say I have a footer that’s 500px tall. It’s filled with banners, ads, and related posts. I don’t want the scroll progress bar to include any of that as part of the reading progress. What I want is for the animation to start at the top and end 500px before the bottom. Here we go:

    animation-range: 0% calc(100% - 500px);

Just like that, we’ve covered the key properties of scroll-timeline animations. Ready to take it a step further?

Named scroll-timeline

Let’s say I want to use the scroll position of a different scroll container for the same animation. The scroll-timeline-name property allows you to specify which scroll container the scroll animation should be linked to. You give it a name (a dashed-ident, e.g. --my-scroll-timeline) that maps to the scroll container you want to use. This container will then control the animation’s progress as the user scrolls through it.

Next, we need to define the scroll axis for this new container by using scroll-timeline-axis which tells the animation which axis will trigger the motion. Here’s how it looks in the code:

    .my-class { 
      /* This is my new scroll-container */
      scroll-timeline-name: --my-custom-name;
      scroll-timeline-axis: inline;
    }

If you omit the axis, then the default block value will be used. However, you can also use the shorthand scroll-timeline property to combine both the name and axis in a single declaration:

    .my-class { 
      /* Shorthand for scroll-container with axis */
      scroll-timeline: --my-custom-name inline;
    }

I think it’s easier to understand all this with a practical example. Here’s the same progress indicator we’ve been working with, but with inline scrolling (i.e. along the x-axis):

We have two animations running:

1. A progress bar grows wider when scrolling in an inline direction.
2. The container’s background color changes the further you scroll.

The HTML structure looks like this:

    <div class="gallery">
      <div class="gallery-scroll-container">
        <div class="gallery-progress" role="progressbar" aria-label="progress"></div>
        <img src="image1.svg" alt="Alt text" draggable="false" width="500">
        <img src="image2.svg" alt="Alt text" draggable="false" width="500">
        <img src="image3.svg" alt="Alt text" draggable="false" width="500">
      </div>
    </div>

In this case, the gallery-scroll-container has horizontal scrolling and changes its background color as you scroll. Normally, we could just use animation-timeline: scroll(self inline) to achieve this. But we also want the gallery-progress element to use the same scroll for its animation.

The gallery-progress element is the first inside gallery-scroll-container and we will lose it when scrolling unless it’s absolutely positioned. But when we do this the element no longer occupies space in the normal document flow, and that affects how the element behaves with its parent and siblings. We need to specify which scroll container we want it to listen to.

That’s where naming the scroll container comes in handy. By giving gallery-scroll-container a scroll-timeline-name and scroll-timeline-axis, we can ensure both animations sync to the same scroll:

    .gallery-scroll-container {
      /* ... */
      animation: bg steps(1);
      scroll-timeline: --scroller inline;
    }

And is using that scrolling to define its own animation-timeline:

    .gallery-scroll-container {
      /* ... */
      animation: bg steps(1);
      scroll-timeline: --scroller inline;
      animation-timeline: --scroller;
    }

Now we can scale this name to the progress bar that is using a different animation but listening to the same scroll:

    .gallery-progress {
      /* ... */
      animation: progressBar linear;
      animation-timeline: --scroller;
    }

This allows both animations (the growing progress bar and changing background color) to follow the same scroll behavior, even though they are separate elements and animations.

The timeline-scope Property

What happens if we want to animate something based on the scroll position of a sibling or even a higher ancestor? This is where the timeline-scope property comes into play. It allows us to extend the scope of a scroll-timeline beyond the current element's subtree. The value of timeline-scope must be a custom identifier, which again is a dashed-ident.

Let’s illustrate this with a new example. This time, scrolling in one container runs an animation inside another container:

We can play the animation on the image when scrolling the text container because they are siblings in the HTML structure:

    <div class="main-container">
      <div class="sardinas-container">
        <img ...>
      </div>
    
      <div class="scroll-container">
        <p>Long text...</p>
      </div>
    </div>

Here, only the .scroll-container has scrollable content, so let’s start by naming this:

    .scroll-container {
      /* ... */
      overflow-y: scroll;
      scroll-timeline: --containerText;
    }

Notice that I haven’t specified the scroll axis, as it defaults to block (vertical scrolling) and that’s the value I want.

Let's move on to the image inside the sardinas-container. We want this image to animate as we scroll through the scroll-container. I’ve added a scroll-timeline-name to its animation-timeline property:

    .sardinas-container img {
      /* ... */
      animation: moveUp steps(6) both;
      animation-timeline: --containerText;
    }

At this point, however, the animation still won’t work because the scroll-container is not directly related to the images. To make this work, we need to extend the scroll-timeline-name so it becomes reachable. This is done by adding the timeline-scope to the parent element (or a higher ancestor) shared by both elements:

    .main-container {
      /* ... */
      timeline-scope: --containerText;
    }

With this setup, the scroll of the scroll-container will now control the animation of the image inside the sardinas-container!

Now that we’ve covered how to use timeline-scope, we’re ready to move on to the next type of scroll-driven animations, where the same properties will apply but with slight differences in how they behave.

View Progress Timelines

We just looked at scroll progress animations. That’s the first type of scroll-driven animation of the two. Next, we’re turning our attention to view progress animations. There’s a lot of similarities between the two! But they’re different enough to warrant their own section for us to explore how they work. You’ll see me refer to these as view-timeline animations in addition to calling them view progress animations, as they revolve around a view() function.

The view progress timeline is the second type of type of scroll-driven animation that we’re looking at. It tracks an element as it enters or exits the scrollport (the visible area of the scrollable content). This behavior is quite similar to how an IntersectionObserver works in JavaScript but can be done entirely in CSS.

We have anonymous and named view progress timelines just as we have anonymous and named scroll progress animations. Let’s unpack those.

Anonymous View Timeline

Here’s a simple example to help us see the basic idea of anonymous view timelines. Notice how the image fades into view when you scroll down to a certain point on the page:

Let’s say we want to animate an image that fades in as it appears in the scrollport. The image’s opacity will go from 0 to 1. This is how you might write that same animation in classic CSS using @keyframes:

    img {
      /* ... */
      animation: fadeIn 1s;
    }
    
    @keyframes fadeIn {
      from { opacity: 0; }
      to { opacity: 1; }
    }

That’s great and all but we want the image to fadeIn when it’s in view. Otherwise, the animation is sort of like a tree that falls in a forest with no one there to witness it… did the animation ever happen? We’ll never know!

We have a view() function that makes this a view progress animation with a single line of CSS:

    img {
      /* ... */
      animation: fadeIn;
      animation-timeline: view();
    }

And notice how we no longer need to declare an animation-duration like we did in classic CSS. The animation is no longer tied by time but by space. The animation is triggered as the image becomes visible in the scrollport.

View Timeline Parameters

Just like the scroll-timeline property, the view-timeline property accepts parameters that allow for more customization:

    animation-timeline: view(<inset> <axis>);

• <inset>: Controls when the animation starts and ends relative to the element’s visibility within the scrollport. It defines the margin between the edges of the scrollport and the element being tracked. The default value is auto, but it can also take length percentages as well as start and end values.
• <axis>: This is similar to the scroll-timeline’s axis parameter. It defines which axis (horizontal or vertical) the animation is tied to. The default is block, which means it tracks the vertical movement. You can also use inline to track horizontal movement, or simple x or y.

Here’s an example that uses both inset and axis to customize when and how the animation starts:

    img {
      animation-timeline: view(20% block);
    }

In this case:

• The animation starts when the image is 20% visible in the scrollport.
• The animation is triggered by vertical scrolling (block axis).

Parallax Effect

With the view() function, it's also easy to create parallax effects by simply adjusting the animation properties. For example, you can have an element move or scale as it enters the scrollport without any JavaScript:

    img {
      animation: parallaxMove 1s;
      animation-timeline: view();
    }
    
    @keyframes parallaxMove {
      to { transform: translateY(-50px); }
    }

This makes it incredibly simple to create dynamic and engaging scroll animations with just a few lines of CSS.

The animation-range Property

Using the CSS **animation-range** property with view timelines defines how much of an element's visibility within the scrollport controls the start and end points of the animation's progress. This can be used to fine-tune when the animation begins and ends based on the element's visibility in the viewport.

While the default value is normal, in view timelines it translates to tracking the full visibility of the element, from the moment it starts entering the scrollport until it fully leaves. This is represented as:

    animation-range: normal normal;
    /* Equivalent to */
    animation-range: cover 0% cover 100%;

Or, more simply:

    animation-range: cover;

There are six possible values or timeline-range-names:

• cover: Tracks the full visibility of the element, from when it starts entering the scrollport to when it completely leaves it.
• contain: Tracks when the element is fully visible inside the scrollport, from the moment it’s fully contained until it no longer is.
• entry: Tracks the element from the point it starts entering the scrollport until it’s fully inside.
• exit: Tracks the element from the point it starts leaving the scrollport until it’s fully outside.
• entry-crossing: Tracks the element as it crosses the starting edge of the scrollport, from start to full crossing.
• exit-crossing: Tracks the element as it crosses the end edge of the scrollport, from start to full crossing.

You can mix different timeline-range-names to control the start and end points of the animation range. For example, you could make the animation start when the element enters the scrollport and end when it exits:

    animation-range: entry exit;

You can also combine these values with percentages to define more custom behavior, such as starting the animation halfway through the element’s entry and ending it halfway through its exit:

    animation-range: entry 50% exit 50%;

Exploring all these values and combinations is best done interactively. Tools like Bramus’ view-timeline range visualizer make it easier to understand.

Target range inside @keyframes

One of the powerful features of timeline-range-names is their ability to be used inside @keyframes:

Two different animations are happening in that demo:

1. slideIn: When the element enters the scrollport, it scales up and becomes visible.
2. slideOut: When the element leaves, it scales down and fades out.

    @keyframes slideIn {
      from {
        transform: scale(.8) translateY(100px); 
        opacity: 0;
      }
      to { 
        transform: scale(1) translateY(0); 
        opacity: 1;
      }
    }
    
    @keyframes slideOut {
      from {
        transform: scale(1) translateY(0); 
        opacity: 1;    
      }
      to { 
        transform: scale(.8) translateY(-100px); 
        opacity: 0 
      }
    }

The new thing is that now we can merge these two animations using the entry and exit timeline-range-names, simplifying it into one animation that handles both cases:

    @keyframes slideInOut {
      /* Animation for when the element enters the scrollport */
      entry 0% {
        transform: scale(.8) translateY(100px); 
        opacity: 0;
      }
      entry 100% { 
        transform: scale(1) translateY(0); 
        opacity: 1;
      }
      /* Animation for when the element exits the scrollport */
      exit 0% {
        transform: scale(1) translateY(0); 
        opacity: 1;    
      }
      exit 100% { 
        transform: scale(.8) translateY(-100px); 
        opacity: 0;
      }
    }

• entry 0%: Defines the state of the element at the beginning of its entry into the scrollport (scaled down and transparent).
• entry 100%: Defines the state when the element has fully entered the scrollport (fully visible and scaled up).
• exit 0%: Starts tracking the element as it begins to leave the scrollport (visible and scaled up).
• exit 100%: Defines the state when the element has fully left the scrollport (scaled down and transparent).

This approach allows us to animate the element’s behavior smoothly as it both enters and leaves the scrollport, all within a single @keyframes block.

Named view-timeline and timeline-scope

The concept of using view-timeline with named timelines and linking them across different elements can truly expand the possibilities for scroll-driven animations. In this case, we are linking the scroll-driven animation of images with the animations of unrelated paragraphs in the DOM structure by using a named view-timeline and timeline-scope.

The view-timeline property works similarly to the scroll-timeline property. It’s the shorthand for declaring the view-timeline-name and view-timeline-axis properties in one line. But the difference from scroll-timeline is that we can link the animation of an element when the linked elements enter the scrollport. I took the previous demo and added an animation to the paragraphs, you can see how the opacity of the text is animated when scrolling the images on the left:

This one looks a bit verbose, but I found it hard to come up with a better example to show the power of it. Each image in the vertical scroll container is assigned a named view-timeline with a unique identifier:

    .vertical-scroll-container img:nth-of-type(1) { view-timeline: --one; }
    .vertical-scroll-container img:nth-of-type(2) { view-timeline: --two; }
    .vertical-scroll-container img:nth-of-type(3) { view-timeline: --three; }
    .vertical-scroll-container img:nth-of-type(4) { view-timeline: --four; }

This makes the scroll timeline of each image have its own custom name, such as --one for the first image, --two for the second, and so on.

Next, we connect the animations of the paragraphs to the named timelines of the images. The corresponding paragraph should animate when the images enter the scrollport:

    .vertical-text p:nth-of-type(1) { animation-timeline: --one; }
    .vertical-text p:nth-of-type(2) { animation-timeline: --two; }
    .vertical-text p:nth-of-type(3) { animation-timeline: --three; }
    .vertical-text p:nth-of-type(4) { animation-timeline: --four; }

However, since the images and paragraphs are not directly related in the DOM, we need to declare a timeline-scope on their common ancestor. This ensures that the named timelines (--one, --two, etc.) can be referenced and shared between the elements:

    .porto {
      /* ... */
      timeline-scope: --one, --two, --three, --four;
    }

By declaring the timeline-scope with all the named timelines (--one, —two, --three, --four), both the images and the paragraphs can participate in the same scroll-timeline logic, despite being in separate parts of the DOM tree.

Final Notes

We’ve covered the vast majority of what’s currently defined in the CSS Scroll-Driven Animations Module Leve 1 specification today in Decemeber 2024. But I want to highlight a few key takeaways that helped me better understand these new rules that you may not get directly from the spec:

• Scroll container essentials: It may seem obvious, but a scroll container is necessary for scroll-driven animations to work. Issues often arise when elements like text or containers are resized, or when animations are tested on larger screens, causing the scrollable area to disappear.
• Impact of position: absolute: Using absolute positioning can sometimes interfere with the intended behavior of scroll-driven animations. The relationship between elements and their parent elements gets tricky when position: absolute is applied.
• Tracking an element’s initial state: The browser evaluates the element’s state before any transformations (like translate) are applied. This affects when animations, particularly view timelines, begin. Your animation might trigger earlier or later than expected due to the initial state.
• Avoid hiding overflow: Using overflow: hidden can disrupt the scroll-seeking mechanism in scroll-driven animations. The recommended solution is to switch to overflow: clip. Bramus has a great article about this and a video from Kevin Powell also suggests that we may no longer need overflow: hidden.
• Performance: For the best results, stick to animating GPU-friendly properties like transforms, opacity, and some filters. These skip the heavy lifting of recalculating layout and repainting. On the other hand, animating things like width, height, or box-shadow can slow things down since they require re-rendering. Bramus mentioned that soon, more properties — like background-color, clip-path, width, and height — will be animatable on the compositor, making the performance even better.
• Use will-change wisely: Leverage this property to promote elements to the GPU, but use it sparingly. Overusing will-change can lead to excessive memory usage since the browser reserves resources even if the animations don’t frequently change.
• The order matters: If you are using the animation shorthand, always place the animation-timeline after it.
• Progressive enhancement and accessibility: Combine media queries for reduced motion preferences with the @supports rule to ensure animations only apply when the user has no motion restrictions and the browser supports them. For example:

    @media screen and (prefers-reduce-motion: no-preference) {
      @supports ((animation-timeline: scroll()) and (animation-range: 0% 100%)) { 
        .my-class {
          animation: moveCard linear both;    
          animation-timeline: view(); 
        }
      } 
    }

My main struggle while trying to build the demos was more about CSS itself than the scroll animations. Sometimes building the layout and generating the scroll was more difficult than applying the scroll animation. Also, some things that confused me at the beginning as the spec keeps evolving and some of these are not there anymore (remember it has been under development for more than five years now!):

• x and y axes: These used to be called the “horizontal” and “vertical” axes, and while Firefox may still support the old terminology, it has been updated.
• Old @scroll-timeline syntax: In the past, @scroll-timeline was used to declare scroll timelines, but this has changed in the most recent version of the spec.
• Scroll-driven vs. scroll-linked animations: Scroll-driven animations were originally called scroll-linked animations. If you come across this older term in articles, double-check whether the content has been updated to reflect the latest spec, particularly with features like timeline-scope.

More information

• All demos from this article can be found in this collection and I might include more as I experiment further.
• A collection of demos from CodePen that I find interesting (send me yours and I’ll include it!)
• This GitHub repo is where you can report issues or join discussions about scroll-driven animations.
• Demos, tools, videos, and (even) more information from Bramus
• Google Chrome video tutorial

Someone recently asked me how I approach debugging inline SVGs. Because it is part of the DOM, we can inspect any inline SVG in any browser DevTools. And because of that, we have the ability to scope things out and uncover any potential issues or opportunities to optimize the SVG.

But sometimes, we can't even see our SVGs at all. In those cases, there are six specific things that I look for when I'm debugging.

1. The viewBox values

The viewBox is a common point of confusion when working with SVG. It’s technically fine to use inline SVG without it, but we would lose one of its most significant benefits: scaling with the container. At the same time, it can work against us when improperly configured, resulting in unwanted clipping.

The elements are there when they’re clipped — they’re just in a part of the coordinate system that we don’t see. If we were to open the file in some graphics editing program, it might look like this:

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. 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. In this case, the best option will be to edit the viewBox to show that part of the coordinate system that was hidden:

There are a few additional things about the viewBox that are worth covering while we're on the topic:

How does the viewBox work?

SVG is an infinite canvas, but we can control what we see and how we see it through the viewport and the viewBox.

The viewport is a window frame on the infinite canvas. Its dimensions are defined by width and height attributes, or in CSS with the corresponding width and height properties. We can specify any length unit we want, but if we provide unitless numbers, they default to pixels.

The viewBox is defined by four values. The first two are the starting point at the upper-left corner (x and y values, negative numbers allowed). I’m editing these to reframe the image. 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).

Here’s simplified markup showing the SVG viewBox and the width and height attributes both set on the <svg>:

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

Reframing

So, this:

<svg viewBox="0 0 700 700">

...maps to this:

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

The viewport we see starts where 0 on the x-axis and 0 on the y-axis meet.

By changing this:

<svg viewBox="0 0 700 700">

...to this:

<svg viewBox="300 200 700 700">

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

In the following video I’m adding a red <circle> to the SVG with its center at the 300 point on the x-axis and 200 on the y-axis. Notice how changing the viewBox coordinates to the same values also changes the circle’s placement to the upper-left corner of the frame while the rendered size of the SVG remains the same (700×700). All I did was “reframe” things with the viewBox.

Zooming

We can change the last two values inside the viewBox to zoom in or out of the image. The larger the values, the more SVG units are added to fit in the viewport, resulting in a smaller image. If we want to keep a 1:1 ratio, our viewBox width and height must match our viewport width and height values.

Let’s see what happens in Illustrator when we change these parameters. The artboard is the viewport which is represented by a white 700px square. Everything else outside that area is our infinite SVG canvas and gets clipped by default.

Figure 1 below shows a blue dot at 900 along the x-axis and 900 along the y-axis. If I change the last two viewBox values from 700 to 900 like this:

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

...then the blue dot is almost fully back in view, as seen in Figure 2 below. Our image is scaled down because we increased the viewBox values, but the SVG's actual width and height dimensions remained the same, and the blue dot made its way back closer to the unclipped area.

There is a pink square as evidence of how the grid scales to fit the viewport: the unit gets smaller, and more grid lines fit into the same viewport area. You can play with the same values in the following Pen to see that work in action:

2. Missing width and height

Another common thing I look at when debugging inline SVG is whether the markup contains the width or height attributes. This is no big deal in many cases unless the SVG is inside a container with absolute positioning or a flexible container (as Safari computes the SVG width value with 0px instead of auto). Excluding width or height in these cases prevents us from seeing the full image, as we can see by opening this CodePen demo and comparing it in Chrome, Safari, and Firefox (tap images for larger view).

The solution? Add a width or height, whether as a presentation attribute, inline in the style attribute, or in CSS. Avoid using height by itself, particularly when it is set to 100% or auto. Another workaround is to set the right and left values.

You can play around with the following Pen and combine the different options.

3. Inadvertent fill and stroke colors

It may also be that we are applying color to the <svg> tag, whether it's an inline style or coming from CSS. That's fine, but there could be other color values throughout the markup or styles that conflict with the color set on the <svg>, causing parts to be invisible.

That's why I tend to look for the fill and stroke attributes in the SVG's markup and wipe them out. The following video shows an SVG I styled in CSS with a red fill. There are a couple of instances where parts of the SVG are filled in white directly in the markup that I removed to reveal the missing pieces.

4. Missing IDs

This one might seem super obvious, but you’d be surprised how often I see it come up. Let’s say we made an SVG file in Illustrator and were very diligent about naming our layers so that you get nice matching IDs in the markup when exporting the file. And let’s say we plan to style that SVG in CSS by hooking into those IDs.

That’s a nice way to do things. But there are plenty of times where I’ve seen the same SVG file exported a second time to the same location and the IDs are different, usually when copy/pasting the vectors directly. Maybe a new layer was added, or one of the existing ones was renamed or something. Whatever the case, the CSS rules no longer match the IDs in the SVG markup, causing the SVG to render differently than you’d expect.

In large SVG files we might find it difficult to find those IDs. This is a good time to open the DevTools, inspect that part of the graphic that’s not working, and see if those IDs are still matching.

So, I'd say it's worth opening an exported SVG file in a code editor and comparing it to the original before swapping things out. Apps like Illustrator, Figma, and Sketch are smart, but that doesn’t mean we aren’t responsible for vetting them.

5. Checklist for clipping and masking

If an SVG is unexpectedly clipped and the viewBox checks out alright, I usually look at the CSS for clip-path or mask properties that might interfere with the image. It’s tempting to keep looking at the inline markup, but it’s good to remember that an SVG’s styling might be happening elsewhere.

CSS clipping and masking allow us to "hide" parts of an image or element. In SVG, <clipPath> is a vector operation that cuts parts of an image with no halfway results. The <mask> tag is a pixel operation that allows transparency, semi-transparency effects, and blurred edges.

This is a small checklist for debugging cases where clipping and masking are involved:

• Make sure the clipping path (or mask) and the graphic overlap one another. The overlapping parts are what gets displayed.

• If you have a complex path that is not intersecting your graphic, try applying transforms until they match.

• You can still inspect the inner code with the DevTools even though the <clipPath> or <mask> are not rendered, so use it!

• Copy the markup inside <clipPath> and <mask> and paste it before closing the </svg> tag. Then add a fill to those shapes and check the SVG's coordinates and dimensions. If you still do not see the image, try adding overflow="hidden" to the <svg> tag.

• Check that a unique ID is used for the <clipPath> or <mask>, and that the same ID is applied to the shapes or group of shapes that are clipped or masked. A mismatched ID will break the appearance.

• Check for typos in the markup between the <clipPath> or <mask> tags.

• fill, stroke, opacity, or some other styles applied to the elements inside <clipPath> are useless — the only useful part is the fill-region geometry of those elements. That's why if you use a <polyline> it will behave as a <polygon> and if you use a <line> you won't see any clipping effect.

• If you don't see your image after applying a <mask>, make sure that the fill of the masking content is not entirely black. The luminance of the masking element determines the opacity of the final graphic. You'll be able to see through the brighter parts, and the darker parts will hide your image's content.

You can play with masked and clipped elements in this Pen.

6. Namespaces

Did you know that SVG is an XML-based markup language? Well, it is! The namespace for SVG is set on the xmlns attribute:

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

There’s a lot to know about namespacing in XML and MDN has a great primer on it. Suffice to say, the namespace provides context to the browser, informing it that the markup is specific to SVG. The idea is that namespaces help prevent conflicts when more than one type of XML is in the same file, like SVG and XHTML. This is a much less common issue in modern browsers but could help explain SVG rendering issues in older browsers or browsers like Gecko that are strict when defining doctypes and namespaces.

The SVG 2 specification does not require namespacing when using HTML syntax. But it’s crucial if support for legacy browsers is a priority — plus, it doesn’t hurt anything to add it. That way, when the <html> element’s xmlns attribute is defined, it will not conflict in those rare cases.

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

This is also true when using inline SVG in CSS, like setting it as a background-image. In the following example, a checkmark icon appears on the input after successful validation. This is what the CSS looks like:

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

When we remove the namespace inside the SVG in the background property, the image disappears:

Another common namespace prefix is xlink:href. We use it a lot when referencing other parts of the SVG like: patterns, filters, animations or gradients. The recommendation is to start replacing it with href as the other one is being deprecated since SVG 2, but there might be compatibility issues with older browsers. In that case, we can use both. Just remember to include the namespace xmlns:xlink="http://www.w3.org/1999/xlink" if you are still using xlink:href.

Level up your SVG skills!

I hope these tips help save you a ton of time if you find yourself troubleshooting improperly rendered inline SVGs. These are just the things I look for. Maybe you have different red flags you watch for — if so, tell me in the comments!

The bottom line is that it pays to have at least a basic understanding of the various ways SVG can be used. CodePen Challenges often incorporate SVG and offer good practice. Here are a few more resources to level up:

• Using SVG with CSS3 and HTML5 (Amelia Bellamy-Royds, Kurt Cagle, Dudley Storey) — I consider it the SVG Bible.

• Lea Verou has a wealth of SVG knowledge and has spoken on the topic quite a bit (like this video from Frontend United 2019).

• SVG Animations (Sarah Drasner)

• SVG Essentials (Amelia Bellamy-Royds, J. David Eisenberg)

• Practical SVG (Chris Coyier)

There are a few people I suggest following for SVG-related goodness:

• Sara Soueidan

• Carl Schoof

• Cassie Evans

• Val Head

• Ana Tudor

This article was first published on CSS-Tricks thanks to the edits from Geoff Graham ♥

Many online tools help us optimize SVG files before getting the code into our projects. But what if I tell you that the way we draw every element has an impact on the exported code? Understanding the code generated from graphic software will help us gain more control over it. Here are some tricks that can save us time when manipulating SVG code on our projects.

Although the examples are on Illustrator, I will also cover ways to improve the code from SVGOMG, and I hope most of them apply to any software you are using to create graphics that will become part of a web or app later on. Some of these tips may sound too picky, but if you are in a project where every bit counts, they might serve you well.

1. Start small

A tiny thing we can do is to design small. As the name implies, SVG scales infinitely without losing quality, which is one of its main advantages. Sometimes we forget about the canvas size while creating, and sometimes we design on big screens with things that need to be at scale. Before exporting, I found it helpful to scale the design and minimize it to a reasonable size. This way, we will reduce many numbers on coordinates that use more than 1 or 2 digits. Of course, the bigger the file, the bigger the impact.

2. Avoid "magic" numbers

Following the previous point, after moving our design around, scaling and collapsing, we might end with many decimal numbers when exporting the results (especially on the stroke attribute). In case it applies, there is a checkbox option that can be used to prevent our stroke and effects to scale with the shape.

• In Illustrator, it is possible to choose how many decimals from 0 to 5 the vectors will have after choosing the 'Export As' option:

• In SVGOMG, there is an option that I like: 'Round/rewrite numbers'. Take a look at the stroke-width in the example below. In the end, I am editing the Precision to reduce one more decimal to the stroke; let's review this option further in the next one.

3. Simplify paths

Every point counts. When reducing the nodes of our illustration, we are reducing the file size by generating less SVG code. These are two different ways of doing this:

• In Illustrator, we select the path we want to edit, then in the menu, click 'Object > Path > Simplify'

• In SVGOMG, after pasting the code, a sidebar will appear on the right with a slider under the name "Precision" to play with how many nodes we want to keep while observing the changes on the graphic

Sometimes we won't even notice the difference. Other times this is not an option: unfortunately, I didn't find a way to reduce nodes in a way that keeps a perfect fit like, for example, in a political map where we need the limits to match perfectly.

4. Extra letter-spacing in SVG text

When using text in SVG, the code exported includes tons of <tspan> with letter-spacing between the letters. Which is very annoying when we want to edit those texts in the code. I used to remove those by hand. That is until I found that the default setting for kerning between characters is 'Auto' (which is the Illustrator solution to adjust visually some pair of letters), and to revert it back to its original spacing, we need to select '0'. This will avoid those extra tspans with letter spacing and simplify our code a lot.

• With kerning Auto:

<text font-family="Arial"><tspan letter-spacing="-.01em">L</tspan><tspan x="5.5" y="0">o</tspan><tspan x="12.08" y="0" letter-spacing="-.01em">r</tspan><tspan x="15.89" y="0">em ipsum</tspan></text>

• With Kerning 0:

<text font-family="Arial">Lorem ipsum</text>

5. Merge/expand shapes

Let's say we have many shapes on top of each other, creating a complex figure: as we export this drawing, every shape will have its code, and all the shapes will remain there. A good amount of code will be reduced if we merge the shapes that share the same attributes to make them a single shape. To do that in Illustrator with the figures selected, we go to the Pathfinder panel and click the first option 'Unite'.

If some of those shapes are paths and they are on top of each other, we have the option 'Merge paths' on SVGOMG that will collapse those paths into one. For basic shapes, we'll need to check the option 'Shapes to (smaller) path'. But this is not something that works as I expected, as I can't seem to make all shapes merge, and I wonder if it has to be with the position of the elements:

6. Radius on rects

When we add corners to a <rect>, Illustrator turns the <rect> into a <path>. Even if the radius is big enough to turn the square into a circle, it will always return a path in the code. But there are many cases where we want to keep the basic shapes as they are. In the case of the circle, the only solution will be to draw it with the ellipse tool, but in any other case, we can use the rectangle tool, and instead of rounding the corners in Illustrator we can add the attributes rx and/or ry to the code later. That will also save us some bytes.

• In Illustrator, with rounded corners:

<path d="M60 100H40C17.9 100 0 82.1 0 60V40C0 17.9 17.9 0 40 0h20c22.1 0 40 17.9 40 40v20c0 22.1-17.9 40-40 40z"/>

• In the code, rounded corners with rx:

<rect width="100" height="100" rx="40"/>

7. Rotation of rects

How we draw on Illustrator determines many things. If I'm drawing a rect 10 units width and 50 units tall, and then I decide to rotate it 90 degrees, the shape will be exported with a transform rotation inside and with the attributes swapped:

<rect width="10" height="50" transform="rotate(90 25 5)"/>

The first number in the transform represents the angle (90 because I rotated it clockwise) but should be -90 if I'd made it anticlockwise. The other two numbers set the coordinates of the transform-origin to the middle of the rectangle.

The only way I found to reset this is by changing the transforms and width/height in Illustrator, which is better than doing it directly in the code, where the x and y positions might have changed too.

This doesn't happen with one or few rects only, but on the rects that belong to a composition that is rotated later in the process.

8. Direction of shapes

Let's say that I kept the transform rotation transform="rotate(90 25 5)" from the example above. Every time I change the width of the bar, it will grow from right to left; as I was building a bar chart, I needed them to grow the opposite way. Here are some options to change this:

• In Illustrator, rotate the shape in a different direction (anticlockwise)
• In the code, change the rotation from 90 to -90
• In Illustrator, reverse the path direction Object > Path > Reverse path direction

Bonus track

• The <use> element is something to keep in mind for cases where a part of the graphic is repeated; here is an article with an example of how this element can save us many lines of code.
• The attribute stroke-miterlimit="10" by default appears many times in exported paths from Illustrator where the stroke-linejoin is round and is not doing anything. Here is a complete article about this attribute.
• Many other articles go further on SVG code optimization, like this one by Bence Szabó that dives deeply into manual optimization of a pattern while learning many things about SVG syntax.

I feel there are so many tips and tricks to explore. Do you have any to share?

Alguien me preguntó recientemente cómo debuggeo SVGs inline. Debido a que son parte del DOM, podemos inspeccionar cualquier SVG inline en cualquier navegador con las DevTools. Gracias a eso, tenemos la capacidad de analizar los elementos y descubrir cualquier problema u oportunidad potencial para optimizar el SVG.

Pero hay veces que ni siquiera podemos ver nuestros SVG. En esos casos, hay seis cosas específicas que busco cuando estoy depurando.

1. Los valores de viewBox

El viewBox es un punto común de confusión cuando se trabaja con SVG. Está técnicamente bien usar SVG inline sin él, pero perderíamos uno de sus beneficios más significativos: escalar con el contenedor. Al mismo tiempo, puede ser contraproducente cuando se configura de forma incorrecta, generando un recorte no deseado.

Los elementos están ahí cuando están clipeados, solo que están en una parte del sistema de coordenadas que no vemos. Si abriéramos el archivo en algún programa de edición de gráficos, se vería algo así:

¿La forma más fácil de arreglar esto? Agregar overflow="visible" al SVG, ya sea en nuestra hoja de estilo, inline en el atributo de estilo o directamente como un atributo de presentación SVG. Pero si también aplicamos un color de fondo al SVG o si tenemos otros elementos a su alrededor, las cosas pueden verse un poco mal. En este caso, la mejor opción será editar viewBox para mostrar esa parte del sistema de coordenadas que estaba oculta:

Hay algunos puntos adicionales sobre el viewBox que vale la pena mencionar mientras estamos en el tema:

¿Cómo funciona el viewBox?

SVG es un lienzo infinito, pero podemos controlar lo que vemos y cómo lo vemos a través del viewport y el viewBox.

El viewport es un marco de ventana en un canvas infinito. Sus dimensiones se definen por atributos width y heigh, o en CSS con las propiedades de width y heigh correspondientes. Podemos especificar cualquier unidad de longitud que queramos, pero si proporcionamos números sin unidades, por defecto serán equivalentes a píxeles.

El viewBox está definido por cuatro valores. Los dos primeros son el punto de partida en la esquina superior izquierda (valores x e y, se permiten números negativos). Edito estos valores para reencuadrar la imagen. Los dos últimos son el ancho y la altura del sistema de coordenadas dentro de la ventana gráfica — aquí es donde podemos editar la escala de la cuadrícula (que abordaremos en la sección sobre Zoom).

Acá hay un ejemplo simplificado que muestra el viewBox SVG y los atributos de width y height establecidos en <svg> :

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

Reencuandre

Así que esto:

<svg viewBox="0 0 700 700">

…equivale a esto:

<svg viewBox="comienzo-eje-x comienzo-eje-y ancho alto">

El viewport (o ventana) que vemos comienza donde se encuentran 0 en el eje x y 0 en el eje y.

Cambiando esto:

<svg viewBox="0 0 700 700">

…a esto:

<svg viewBox="300 200 700 700">

…el ancho y la altura siguen siendo los mismos (700 unidades cada uno), pero el inicio del sistema de coordenadas ahora está en el punto 300 en el eje x y 200 en el eje y.

En el siguiente video, agrego un <circle> rojo al SVG con su centro en el punto 300 en el eje x y 200 en el eje y. Se puede observar cómo al cambiar las coordenadas de viewBox a los mismos valores, también cambia la ubicación del círculo en la esquina superior izquierda del marco, mientras que el tamaño representado del SVG sigue siendo el mismo (700 × 700). Todo lo que hice fue “reencuadrar” los elementos con viewBox.

Zoom

Podemos cambiar los dos últimos valores dentro de viewBox para acercar o alejar la imagen. Cuanto mayores sean los valores, más unidades SVG se agregan para que quepan en el viewport, lo que da como resultado una imagen más pequeña. Si queremos mantener una proporción de 1: 1, el ancho y la altura de nuestro viewBox deben coincidir con los valores de ancho y alto de nuestro viewport.

Veamos qué sucede en Illustrator cuando cambiamos estos parámetros. El artwork es igual al viewport que está representada por un cuadrado blanco de 700px. Todo lo demás fuera de esa área es nuestro canvas SVG infinito y queda recortada por default.

La Figura 1 a continuación muestra un punto azul en 900 en eleje x y 900 en el eje y. Si cambio los dos últimos valores de viewBox de 700 a 900 así:

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

… entonces el punto azul vuelve a estar casi completamente a la vista, como se ve en la Figura 2 a continuación. Nuestra imagen se redujo porque aumentamos los valores de viewBox, pero las dimensiones reales de ancho y alto del SVG se mantuvieron iguales, y el punto azul volvió a acercarse al área sin recortar.

Hay un cuadrado rosa como evidencia de cómo la cuadrícula se escala para ajustarse a la ventana gráfica: la unidad se vuelve más pequeña y más líneas de cuadrícula encajan en la misma área del viewport. Dejo un Pen acá abajo para jugar con los mismos valores y ver ese trabajo en acción:

2. Width y height ausentes

Otra cosa común que miro al depurar SVG en línea es si el archivo contiene los atributos de ancho o alto. Esto no es gran cosa en muchos casos, a menos que el SVG esté dentro de un contenedor con position absolute o un contenedor flex (ya que Safari calcula el valor de ancho de SVG con 0px en lugar de auto). Excluir el width o el height en estos casos nos impide ver la imagen completa, como podemos ver al abrir esta demostración de CodePen y compararla en Chrome, Safari y Firefox.

¿La solución? Agregar un width o height, ya sea como un atributo de presentación, inline en el atributo de estilo o en CSS. Evitar usar height sólo, especialmente cuando está configurado al 100% o en auto. Otra solución es declarar los valores right y left. Se puede jugar con el siguiente Pen y combinar las diferentes opciones.

3. Colores de fill and stroke involuntarios

También puede ser que estemos aplicando color a la etiqueta <svg>, ya sea un estilo inline o proveniente de CSS. Eso está bien, pero podría haber otros valores de color a lo largo del código interno o estilos que entren en conflicto con el conjunto de colores en el <svg>, causando que las partes sean invisibles.

Es por eso que tiendo a buscar los atributos de fill y stroke en el código del SVG y los elimino. El siguiente video muestra un SVG que tiene estilos en CSS con un fill rojo. Hay un par de instancias en la que partes del SVG se pintan de blanco directamente en el código; las eliminé para revelar las piezas que faltan.

4. IDs faltantes

Este puede parecer súper obvio, pero es sorprendente la frecuencia con la que lo veo surgir. Digamos que creamos un archivo SVG en Illustrator y fuimos muy diligentes en nombrar nuestras capas para que obtengan IDs en el código al exportar el archivo. Y digamos que planeamos estilear ese SVG en CSS conectando con estos IDs.

Esa es una buena manera de hacer las cosas. Pero hay muchas ocasiones en las que he visto el mismo archivo SVG exportado por segunda vez a la misma ubicación y los IDs son diferentes, generalmente al copiar/pegar los vectores directamente. Tal vez se agregó una nueva capa, o se cambió el nombre de una de las existentes o algo así. Cualquiera que sea el caso, las reglas de CSS ya no coinciden con los IDs del código SVG, lo que hace que el SVG se presente de manera diferente a lo esperado.

En archivos SVG de gran tamaño, puede que nos resulte difícil encontrar esos IDs. Este es un buen momento para abrir DevTools, inspeccionar la parte del gráfico que no funciona y ver si esos IDs aún coinciden o cambiaron su nombre con alguna versión _1_ por ejemplo.

5. Checklist para clipping y masking

Si encuentro un SVG recortado inesperadamente pero el viewBox funciona bien, normalmente busco en el CSS las propiedades de clip-path o mask que podrían interferir con la imagen. Es tentador seguir mirando el código inline, pero es bueno recordar que el estilo de un SVG podría estar ocurriendo en otro lugar.

El recorte y el enmascaramiento de CSS nos permiten “ocultar” partes de una imagen o elemento. En SVG, <clipPath> es una operación vectorial que corta partes de una imagen sin resultados intermedios. La etiqueta <mask> es una operación de píxeles que permite transparencia, efectos de semitransparencia y bordes borrosos.

Esta es una pequeña checklist para depurar casos en los que están involucrados el clip-path y/o mask:

• Asegurarse de que el clipping path (o mask) y el gráfico se superpongan entre sí. Las partes superpuestas son las que se muestran.
• Si hay un path complejo que no se cruza con nuestro gráfico, internar aplicar transformaciones hasta que coincidan.
• Todavía se puede inspeccionar el código interno con DevTools aunque <clipPath> o <mask> no se renderizen, podemos ver su caja.
• Copiar el código dentro del <clipPath> o <mask> y pegarlo antes de cerrar la etiqueta </svg>. Luego agregar un fill a esas formas y verificar las coordenadas y dimensiones del SVG. Si aún no se ve la imagen, intentar agregar overflow="visible" a la etiqueta <svg>.
• Verificar que se use un ID único para <clipPath> o <mask>, y que el mismo ID se aplique a las formas o grupo de formas que están recortadas o enmascaradas. Un ID que no coincida romperá la apariencia.
• Comprobar si hay errores tipográficos en el código entre las etiquetas <clipPath> o <mask>.
• fill, stroke, opacity o algunos otros estilos aplicados a elementos dentro de <clipPath> son inútiles — la única parte útil es la geometría de la región de relleno de esos elementos. Es por eso que si usamos un <polyline> se comportará como un <polygon> y si usamos una <line> no se verá ningún efecto de recorte.
• Si no se ve la imagen después de aplicar una <mask>, hay que asegurarse de que el relleno del contenido de la máscara no sea completamente negro. La luminancia del elemento de la máscara determina la opacidad del gráfico final. Podremos ver a través de las partes más brillantes y las partes más oscuras ocultarán el contenido de la imagen.

En este Pen se puede jugar con elementos enmascarados y recortados.

6. Namespaces

¿Sabías que SVG es un lenguaje de markup basado en XML? ¡Bueno, lo es! El namespace para SVG se establece en el atributo xmlns:

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

Hay mucho que saber sobre los namespaces en XML y MDN tiene una gran introducción al respecto. Basta con decir que el namespace proporciona contexto al navegador, informándole que el marcado es específico de SVG. La idea es que los namespaces ayuden a evitar conflictos cuando hay más de un tipo de XML en el mismo archivo, como SVG y XHTML. Este es un problema mucho menos común en los navegadores modernos, pero podría ayudar a explicar los problemas de renderizado de un SVG en navegadores más antiguos o navegadores como Gecko que son estrictos al definir tipos de documentos y namespaces.

La especificación SVG 2 no requiere namespaces cuando se utiliza la sintaxis HTML. Pero es crucial si la compatibilidad con los navegadores anteriores es una prioridad, en esos casos no está de más agregarlo. De esa forma, cuando se define el atributo xmlns del elemento <html>, no entrará en conflicto en esos casos excepcionales.

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

Esto también es cierto cuando se usa SVG inline en CSS, como cuando lo usamos de background-image. En el siguiente ejemplo, aparece un icono de checkmark en el input después de una validación exitosa. Así es como se ve el CSS:

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

Cuando eliminamos el namespace dentro del SVG en la propiedad de background, la imagen desaparece:

Otro prefijo de namespace común es xlink:href. Lo usamos mucho cuando hacemos referencia a otras partes del SVG como: patterns, filtros, animaciones o gradientes. La recomendación es comenzar a reemplazarlo con href ya que el otro está en desuso desde SVG 2, pero puede haber problemas de compatibilidad con navegadores más antiguos. En ese caso, podemos usar ambos. Solo hay que recordar incluir el namespace xmlns:xlink=”http://www.w3.org/1999/xlink" si todavía vamos a usar xlink:href.

¡Seguir aprendiendo SVG!

Espero que estos consejos te ayuden a ahorrar mucho tiempo si te encuentras con problemas de renderizado de SVG inline. Estas son algunas de las cosas que busco. Tal vez tengas otras diferentes — si es así, ¡dímelo en los comentarios!

La conclusión es que vale la pena tener al menos una comprensión básica de las diversas formas en que se puede usar SVG. CodePen Challenges a menudo incorpora SVG y ofrece buenas prácticas. Aquí hay algunos recursos más para subir de nivel:

• Using SVG with CSS3 and HTML5 (Amelia Bellamy-Royds, Kurt Cagle, Dudley Storey) —Este es para mí la Biblia SVG.

• Lea Verou tiene un gran conocimiento de SVG y ha hablado bastante sobre el tema (como este video de Frontend United 2019).

• SVG Animations (Sarah Drasner)

• SVG Essentials (Amelia Bellamy-Royds, J. David Eisenberg)

• Practical SVG (Chris Coyier)

Hay otras personas más que sugiero seguir por la cantidad de conocimiento e información que comparten relacionada con SVG:

• Sara Soueidan

• Carl Schoof

• Cassie Evans

• Val Head

• Ana Tudor

Este artículo se publicó por primera vez en CSS-Tricks. Gracias a las ediciones de Geoff Graham ♥

Muchas herramientas online nos ayudan a optimizar archivos SVG antes de incluir el código en nuestros proyectos. Pero, ¿qué pasa si te digo que la forma en que dibujamos cada elemento tiene un impacto en el código exportado? Comprender el código generado por el programa que usemos para dibujar, nos ayudará a tener más control sobre él. Aquí hay algunos trucos que pueden ahorrarnos tiempo a la hora de manipular código SVG en nuestros proyectos.

Los ejemplos están en Illustrator, pero también cubriré formas de mejorar el código de SVGOMG, y espero que la mayoría de estos ejemplos apliquen a cualquier software que estés usando para crear gráficos que luego serán parte de una web o app. Algunos de estos consejos pueden sonar demasiado extremos, pero si estás en un proyecto en el que cada bit cuenta, pueden serte útiles.

1. Comenzar en pequeño

Alg simple que podemos hacer es diseñar pequeño. Como su nombre lo indica, SVG escala infinitamente sin perder calidad, y esta es una de sus principales ventajas. A veces nos olvidamos del tamaño del lienzo mientras creamos, o diseñamos en pantallas grandes con cosas que deben estar a escala. Antes de exportar, puede ser útil escalar el diseño y minimizarlo a un tamaño razonable. De esta manera, reduciremos muchos números en coordenadas que usan más de 1 o 2 dígitos. Por supuesto, cuanto más grande es el archivo, mayor es el impacto.

2. Evitar números "mágicos"

Siguiendo con el punto anterior, después de mover nuestro diseño, escalarlo y contraerlo, podríamos terminar con muchos números decimales al exportar los resultados (especialmente en el atributo de trazo o stroke). Si queremos evitarlo, existe un checkbox que se puede deseleccionar para evitar que nuestro trazo y efectos se escalen al manipularlos.

• En Illustrator, es posible elegir cuántos decimales del 0 al 5 tendrán los vectores después de elegir la opción 'Exportar como':

• En SVGOMG, hay una opción que es muy útil: 'Redondear/reescribir números'. Mirá el stroke-width en el siguiente ejemplo. Al final, estoy editando la Precisión para reducir un decimal más al trazo; amplío esto en la próxima sección.

3. Simplificar paths

Cada punto cuenta. Al reducir los nodos de nuestra ilustración, estamos reduciendo el tamaño del archivo al generar menos código SVG. Estas son dos maneras diferentes de hacer esto:

• En Illustrator, seleccionamos el path que queremos editar, luego en el menú, hacemos clic en 'Objeto> Path> Simplificar'

• En SVGOMG, después de pegar el código, aparecerá una barra lateral a la derecha con un slider bajo el nombre "Precisión" que podemos mover para ver cuántos nodos queremos mantener mientras observamos los cambios en el gráfico.

A veces ni siquiera notamos la diferencia. Otras veces, esto no es una opción: desafortunadamente, no encontré forma de reducir los nodos de una manera que se ajuste perfectamente como, por ejemplo, en un mapa político donde necesitamos que los límites coincidan perfectamente.

4. Extra interletrado en texto SVG

Cuando se usa texto en SVG, el código exportado incluye toneladas de <tspan> con letter-spacing entre las letras. Lo cual es muy molesto cuando queremos editar esos textos en el código. Solía quitarlos a mano. Eso fue hasta que descubrí que la configuración predeterminada para el interletraje entre caracteres es 'Auto' (que es la solución de Illustrator para ajustar visualmente algunos pares de letras), y para revertirlo a su espaciado original, debemos seleccionar '* 0*'. Esto evitará esos 'tspans' adicionales con espaciado de letras y simplificará mucho nuestro código.

• Con interletrado automático:

<text font-family="Arial"><tspan letter-spacing="-.01em">L</tspan><tspan x="5.5" y="0">o</tspan><tspan x="12.08" y="0" letter-spacing="-.01em">r</tspan><tspan x="15.89" y="0">em ipsum</tspan></text>

• Con interletrado 0:

<text font-family="Arial">Lorem ipsum</text>

5. Fusionar/expandir formas

Digamos que tenemos muchas formas una encima de la otra, creando una figura compleja: cuando exportemos este dibujo, cada forma tendrá su código y todas las formas permanecerán independientes. Pero reduciríamos una buena cantidad de código si fusionamos las formas que comparten los mismos atributos para convertirlas en una sola. Para hacer eso en Illustrator con las figuras seleccionadas, vamos al panel de Pathfinder y hacemos clic en la primera opción 'Unir'.

Si algunas de esas formas son paths y están uno encima del otro, tenemos la opción 'Merge paths' en SVGOMG que los combinará en uno solo. Para formas básicas, necesitaremos marcar la opción 'Shapes to (smaller) path'. Esto no funciona exactamente como esperaba, fusiona algunas formas y otras no, y me pregunto si esto tiene que ser con la posición de los elementos:

6. Radius en rects

Cuando añadimos esquinas a un <rect>, Illustrator convierte el <rect> en un <path>. Incluso si el radio es lo suficientemente grande como para convertir el cuadrado en un círculo, siempre devolverá un path en el código. Pero hay muchos casos en los que queremos mantener las formas básicas como están. En el caso del círculo, la única solución será dibujarlo con la herramienta ellipse, pero en cualquier otro caso podemos usar la herramienta rectángulo, y en lugar de redondear las esquinas en Illustrator podemos agregar los atributos rx y /o ry al código más tarde. Eso también nos ahorrará algunos bytes.

• En Illustrator, con esquinas redondeadas:

<path d="M60 100H40C17.9 100 0 82.1 0 60V40C0 17.9 17.9 0 40 0h20c22.1 0 40 17.9 40 40v20c0 22.1-17.9 40-40 40z"/>

• En el código, esquinas redondeadas con rx:

<rect width="100" height="100" rx="40"/>

7. Rotación de rects

Cómo dibujamos en Illustrator determina muchas cosas. Si estoy dibujando un rect de 10 unidades de ancho y 50 unidades de alto, y luego decido rotarlo 90 grados, la forma se exportará con una transformación de rotación adentro y con los atributos intercambiados:

<rect width="10" height="50" transform="rotate(90 25 5)"/>

El primer número en la transformación representa el ángulo (90 porque lo giré en el sentido de las agujas del reloj) pero debería ser -90 si lo hubiera hecho en el sentido contrario a las agujas del reloj. Los otros dos números establecen las coordenadas del transform-origin en el centro del rectángulo.

La única forma que encontré para restablecer esto es cambiando las transformaciones y el ancho/alto en Illustrator, que es mejor que hacerlo directamente en el código, donde las posiciones x e y también podrían haber cambiado.

Esto no ocurre solo con uno o pocos rects, sino con los rects que pertenecen a una composición que se rota más adelante en el proceso.

8. Dirección de las formas

Digamos que mantuve la rotación de transformación transform="rotate(90 25 5)" del ejemplo anterior. Cada vez que cambio el ancho de la barra, crecerá de derecha a izquierda; como estaba construyendo un gráfico de barras, necesitaba que crecieran de manera opuesta. Aquí hay algunas opciones para cambiar esto:

• En Illustrator, rota la forma en una dirección diferente (en sentido contrario a las agujas del reloj)
• En el código, cambia la rotación de 90 a -90
• En Illustrator, invertir la dirección de la ruta Objeto > Path > Invertir dirección del path

Bonus track

• El elemento <use> es algo a tener en cuenta para los casos en los que se repite una parte del gráfico; aquí hay un artículo con un ejemplo de cómo este elemento puede ahorrarnos muchas líneas de código .
• El atributo stroke-miterlimit="10" por defecto aparece muchas veces en las rutas exportadas de Illustrator donde no está haciendo nada ya que el stroke-linejoin es redondo. Aquí hay un artículo completo sobre este atributo.
• Muchos otros artículos van más allá sobre la optimización del código SVG, como este de Bence Szabó que profundiza en la optimización manual de un patrón mientras aprende muchas cosas sobre la sintaxis SVG.

Siento que hay tantos consejos y trucos para explorar. ¿Tenes alguno para compartir?

Let’s say someone asks you to add a double border to some random geometric SVG shapes. For some reason, you can’t use any graphic editor — they need to be generated at runtime — so you have to solve it with CSS or within the SVG syntax.

Your first question might be: Is there anything like stroke-style: double in SVG? Well, the answer is not yet and it’s not that easy. But I’ll attempt it anyway to see what methods I can uncover. I’ll explore the possibilities of three different basic shapes: circle, rectangle, and polygon. Pointing the ones that can keep a transparent color in the middle of the two lines.

Spoiler alert: all the results have their downsides, at least with CSS and SVG, but let me walk you through my intents.

The simple solutions

These don’t work with all shapes, but they are the easiest of the solutions.

outline and box-shadow

The CSS properties outline and box-shadow only apply to the bounding box of the shape or SVG, and so both are great solutions only for squares and rectangles. They also allow flexible colors using custom properties.

It only takes two lines of CSS with outline, plus it keeps the background color visible through the shape.

• 🙁 Solution only for one shape.
• ✅ Simple code
• ✅ Borders are smooth
• ✅ Transparent background

box-shadow only needs one line of CSS, but we have to make sure that each shape has its own SVG as we can’t apply box-shadow directly to the shapes. Another thing to consider is that we have to apply the color of the background in the declaration.

• 🙁 Solution only for one shape
• ✅ Simple code
• ✅ Borders are smooth
• 🙁 No transparent background

SVG gradients

SVG radial gradients only work on circles ☺️. We can directly apply the gradient on the stroke, but it’s better to use variables as we have to declare the colors many times in the code.

• 🙁 Solution only for one shape
• ✅ Simple code
• 🙁 Borders are smooth
• 🙁 No transparent background

Solutions for all shapes

These will work with all shapes, but the code could become bloated or complex.

filter: drop-shadow()

Finally, one solution for all shapes! We must have each shape in its own <svg> since the filter won’t apply directly to the shapes. We are using one declaration in CSS and have flexible colors using variables. The downside? The borders don’t look very smooth.

• ✅ One solution for all shapes
• ✅ Simple code
• 🙁 Borders look pixelated
• 🙁 No transparent background

SVG filters

This is a very flexible solution. We can create a filter and add it to the shapes through SVG’s filter attribute. The complicated part here is the filter itself. We’ll need three paintings, one for the outside border, one for the background flood, and the last one to paint the shape on the front. The result looks better than using drop-shadow, but the borders are still pixelated.

• ✅ One solution for all shapes
• 🙁 Complex code
• 🙁 Borders look pixelated
• 🙁 No transparent background

Reusing shapes

There are a couple of possible options here.

Option 1: Transforms

This solution requires transforms. We place one figure over the other, where the main figure has a fill color and a stroke color, and the other figure has no fill, a red stroke, and is scaled and repositioned to the center. We defined our shapes on the <defs>. The trick is to translate half of the viewBox to the negative space so that, when we scale them, we can do it from the center of the figure.

• ✅ One solution for all shapes
• 🙁 Duplicated code
• ✅ Borders are smooth
• ✅ Transparent background

Option 2: <use>

I found a clever solution in the www-svg mailing list by Doug Schepers that uses SVG <use>. Again, it requires defining the shapes once and referring to them twice using <use>. This time the main shape has a bigger stroke. The second shape has half the stroke of the main shape, no fill, and a stroke matching the background color.

• ✅ One solution for all shapes
• 🙁 Duplicated code
• ✅ Borders are smooth
• 🙁 No transparent background

Here are the full results!

Just so you have them all in one place. Let me know if you can think of other possible solutions!

This article was first published on CSS-Tricks with edits from Chris Coyier and Geoff Graham ♥

Read the Chinese version here. Translated by Rotten orange 腐烂的橘子

There are different ways to work with icons, but the best solution always includes SVG, either inline or linked up as a file. Sometimes the icons we download (or the ones we create with a drawing software) have a lot of unnecessary code that if we use it inline makes our document longer to scroll, uncomfortable to work with, and just a little bit heavier.

We can work around this reusing chunks of code with the <use> element or apply native variables to manage our SVG styles from one place.

Here I want to focus on a different perspective: how to make the same figures with less amount of code using basic shapes. And get the benefits of smaller, controllable, and semantic icons in our projects without sacrificing quality or visual changes. I'll go through different examples that explore the code of commonly used icons and how we can redraw them using some of the easiest SVG shapes we can make.

These are the icons we'll be working on:

Let's look at the basic shapes we can use to make these that keep the code small and simple.

Psssst! Here is a longer list of simple icons I created on holasvg.com! After this article, you'll know how to modify them and make them your own.

Building a close icon with the <line> element

This is the code for the close or cross icon that was downloaded from flaticon.com and built by pixel-perfect:

In this example, everything is happening inside the <path> with lots of commands and parameters in the data attribute d. What this SVG is doing is tracing the shape from its borders.

If you are familiar with Illustrator, this is the equivalent of drawing two separate lines, converting them to shape, then combining both with the pathfinder to create one compound shape.

The <path> element allows us to draw complex shapes, but in this case, we can create the same figure with two lines, while keeping the same appearance:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50" width="50" height="50" overflow="visible" stroke="black" stroke-width="10" stroke-linecap="round">
   <line x1="0" y1="0" x2="50" y2="50" />
   <line x1="50" y1="0" x2="0" y2="50" />
</svg>

We started by defining a viewBox that goes from 0,0 to 50,50. You can choose whatever dimensions you prefer; the SVG will always scale nicely to any width and height you define. To make things easier, in this case, I also defined an inline width and height of 50 units, which avoids extra calculations in the drawing.

To use the <line> element, we declare the coordinates of the lines first point and the coordinates of its last point. In this specific case, we started from x=0 y=0 and ended at x=50 y=50.

Here's how that looks in code:

<line x1="0" y1="0" x2="50" y2="50" />

The second line will start from x=50 y=0 and end at x=0 y=50:

<line x1="50" y1="0" x2="0" y2="50" />

An SVG stroke doesn't have a color by default that's why we added the black value on the stroke attribute. We also gave the stroke-width attribute a width of 10 units and the stroke-linecap a round value to replicate those rounded corners of the original design. These attributes were added directly to the <svg> tag so both lines will inherit them.

<svg ... stroke="black" stroke-width="10" stroke-linecap="round" ...>

Now that the stroke is 10 units bigger than its default size of 1 unit, the line might get cropped by the viewBox. We can either move the points 10 units inside the viewBox or add overflow=visible to the styles.

The values that are equal to 0 can be removed, as 0 is the default. That means the two lines end up with two very small lines of code:

<line x2="50" y2="50" />
<line x1="50" y2="50" />

Just by changing a <path> to a <line>, not only did we make a smaller SVG file, but a more semantic and controllable chunk of code that makes any future maintenance much easier. And the visual result is exactly the same as the original.

Same cross, different code.

Building a clock icon with the <circle> and <path> elements

I took this example of a clock icon created by barracuda from The Noun Project:

This shape was also drawn with a <path>, but we also have a lot of namespaces and XML instructions related to the software used and the license of the file that we can delete without affecting the SVG. Can you tell what illustration editor was used to create the icon?

Let's recreate this one from scratch using a circle and a path with simpler commands. Again, we need to start with a viewBox, this time from 0,0 to 100,100, and with a width and height matching those units.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100" fill="none" stroke="black" stroke-width="10" stroke-linecap="round" stroke-linejoin="round">
  <circle cx="50" cy="50" r="40"/>
  <path d="M50 25V50 H75" /> 
</svg>

We keep the same styles as the previous icon inside the <svg> tag. fill is black by default, so we need to explicitly give it a none value to remove it. Otherwise, the circle will have have a solid black fill, obscuring the other shapes.

To draw the <circle> we need to indicate a center point from where the radius will sit. We can achieve that with cx (center x) and cy (center y). Then r (radius) will declare how big our circle will be. In this example, the radius is slightly smaller than the viewBox, so it doesn't get cropped when the stroke is 10 units wide.

What's up with all those letters? Check out Chris Coyier's illustrated guide for a primer on the SVG syntax.

We can use a <path> for the clock hands because it has some very useful and simple commands to draw. Inside the d (data) we must start with the M (move to) command followed by the coordinates from where we'll start drawing which, in this example, is 50,25 (near the top-center of the circle).

After the V (vertical) command, we only need one value as we can only move up or down with a negative or positive number. A positive number will go down. The same for H (horizontal) followed by a positive number, 75, that will draw toward the right. All commands are uppercase, so the numbers we choose will be points in the grid. If we decided to use lowercase (relative commands) the numbers will be the amount of units that we move in one direction and not an absolute point in the coordinate system.

Same clock, different code.

Building an envelope icon with the <rect> and <polyline> elements

I drew the envelope icon in Illustrator without expanding the original shapes. Here's the code that came from the export:

Hey! Illustrator offers some SVG options to export the graphic. I chose Style Elements in the CSS Properties dropdown so I can have a <style> tag that contains classes that I might want to move to a CSS file. But there are different ways to apply the styles in SVG, of course.

We already have basic shapes in this code! I unselected the Shape to paths option in Illustrator which helped a lot there. We can optimize this further with SVGOMG to remove the comments, XML instructions, and unnecessary data, like empty elements. From there, we can manually remove other extras, if we need to.

We already have something a little more concise:

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" x="0" y="0" viewBox="0 0 310 190" xml:space="preserve">
  <style>.st0{fill:none;stroke:#000;stroke-width:10;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10}
  </style><rect x="5" y="5" class="st0" width="300" height="180"/>
  <polyline class="st0" points="5 5 155 110 305 5"/>
</svg>

We can remove even more stuff without affecting the visual appearance of the envelope, including:

• version="1.1" (this has been deprecated since SVG 2)
• id="Layer_1" (this has no meaning or use)
• x="0" (this is a default value)
• y="0" (this is a default value)
• xml:space="preserve" (this has been deprecated since SVG 2)

<svg xmlns="http://www.w3.org/2000/svg" x="0" y="0" viewBox="0 0 310 190">
  <style>.st0{fill:none;stroke:#000;stroke-width:10;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10}
  </style>
  <rect x="5" y="5" class="st0" width="300" height="180"/>
  <polyline class="st0" points="5 5 155 110 305 5"/>
</svg>

We can move the CSS styles to a separate stylesheet if we really want to get really aggressive.

<rect> needs a starting point from where we'll extend a width and a height, so let's use x="5" and y="5" which is our top-left point. From there, we will create a rectangle that is 300 units wide with a height of 180 units. Just like the clock icon, we'll use 5,5 as the starting point because we have a 10-unit stroke that will get cropped if the coordinates were located at 0,0.

<polyline> is similar to <line>, but with an infinite amount of points that we define, like pairs of coordinates, one after the other, inside the points attribute, where the first number in the pair will represent x and the second will be y. It's easier to read the sequence with commas, but those can be replaced with whitespace without having an impact on the result.

Same envelope, different code.

Bonus shapes!

I didn't include examples of icons that can be simplified with <polygon> and <ellipse> shapes, but here is a quick way to use them.

<polygon> is the same as <polyline>, only this element will always define a closed shape. Here's an example that comes straight from MDN:

Remember the circle we drew earlier for the clock icon? Replace the r (radius) with rx and ry. Now you have two different values for radius. Here's another example from MDN:

Wrapping up

We covered a lot here in a short amount of time! While we used examples to demonstrates the process of optimizing SVGs, here's what I hope you walk away with from this post:

• Remember that compression starts with how the SVG is drawn in illustration software.
• Use available tools, like SVOMG, to compress SVG.
• Remove unnecessary metadata by hand, if necessary.
• Replace complex paths with basic shapes.
• <use> is a great way to inline SVG as well as for establishing your own library of reusable icons.

How many icons can be created by combining these basic shapes?

I'm working on my list on holasvg.com/icons, I'll be constantly uploading more icons and features here, and now you know how to easily modified them just by changing a few numbers. Go ahead and make them yours!

This article was first published on CSS-Tricks with edits from Chris Coyier and Geoff Graham

Not every brand guidelines include definitions for the usage of photography, illustrations, or image styles. Far from being a problem, this could mean a great opportunity for a redesign project. While filling the requirements for a software development project, we discovered the chance to create and explore a visual universe to enlarge our client's identity.

On every website, we find common spaces to communicate to the users what is happening. Places where the message is simple but we can tell a story. Some of them include logins, error pages, and loadings, they communicate the same on every site, and that is what let us space to release some creativity.

The starting point

Our client's business is about offering services to other companies, along with a platform to manage them all internally. Our job was to redesign and rethink that custom service platform. At the moment we started, they had this website that was built some years ago, it had an old design and some performance and accessibility problems. They needed a fresh start from the visual and technical perspectives; something simple, fast and easy to use.

It was not the typical product site with a homepage that explains what they do and tries to sell it. The end-user of this platform is a customer that already bought our client's services and uses this platform to manage them in their own company. When they reach this site it's because they have credentials and they already know what the site is about and what it is for.

On the good side, the users are somehow prepared for what they are going to find in the link. They will come to this platform (maybe more than once a day) with a task to complete. So it's important that we don't distract the user from what they're trying to achieve.

We wanted to make the design visually attractive without cluttering the site, so we had to pick the right moments and the right ways to do that. Our goal was to find those places where we could make the site friendlier and integrated into the brand, keeping in mind that the main purpose of this platform was to manage services in a simple way without disturbing them.

The client's brand was defined with a color palette, typography, and style for icons, but there wasn't a strict guideline for images and illustrations, and that's where we saw an opportunity.

Choosing the right format

We discarded the usage of photography; photographs are more suitable for products, more literal and grounded in reality. This site was neither about selling a product nor describing it, but to improve the experience of the current users and help them achieve their tasks easily. Illustrations work better to express concepts and we could easily include our client's color palette to make them part of the brand. Besides vectors can perform much better than raster images (we'll talk more about this later).

Our proposal was to build a graphic universe with illustrations to show all these services in a friendlier way and also to communicate when something was happening on the site. By building this graphic universe we are adding a new ingredient to their guidelines, a different solution to approach any possible visual communication problem. We are not offering a set of images, but a set of rules for a language that they can continue to develop and make part of their brand.

References First

We started by showing the client some references for illustrations with a small description so they could decide which style represented them the most. Some of these images included different perspectives, dimensions, depths, characters, stroke styles, gradients, and solid combinations, rounded and sharp edges, between others. From the beginning, we discarded any complex texture, effects, or super realistic illustrations. We knew that performance will pay if we keep it simple from the beginning.

Test the idea with the style

The client picked two options, so we delivered some small sketches to start testing the styles and at the same time, talking about the ideas to represent. The Login is the first page the user will see, and also the one with more space available for creation. Here, we wanted to show a city where all our client's services coexist, so we sent some drafts of the city with both styles:

As we mentioned before: when the users reach the login, they are aware of what the site is about. We didn't need to explain the services in detail but to think about how the illustration could reinforce their benefits.

After they picked one final style and the idea of the city was approved, we started discussing which elements to show and how to represent them.

This phase was about getting the best way to show all the scenes of the city until the login design was finished. That is when we started focusing on the code and choosing the best way to implement those illustrations on the site.

Using SVG

As soon as the illustration was approved, we exported the file from Illustrator to SVG as it's the best format to use vector images on the web. We decided to use the SVG code inline in our document because this approach allows us to make use of animations. Let's review some of the benefits of inline SVG:

• Very low file size with the best resolution
• Flexible options for responsive design
• Great performance
• Renders immediately
• Accessible through the DOM so we can interact with any group of vectors
• Allows control of some attributes through a stylesheet
• Allows CSS animation

There are a few ways to export the SVG, the easiest one is to copy the vectors from Illustrator and paste them in a text editor. As simple as that:

The software adds a lot of code that is not necessary and hurts legibility and performance. That's why a tool like SVGOMG helps us optimize the file in a fast and easy way. Going deeper in that direction, manual optimization is usually part of our process. Another important thing to keep in mind is that SVG is a great ally for accessibility.

Now we have our code clean and we can start adding classes to the elements we want to animate. In this case, CSS animations were enough to build these simple animations.

This was the result for the Login page, the SVG illustration weights only 42k after optimization:

Note: The gif is displaying in a loop but some animations were playing just once.

After the main animation was ready, smaller instances were easier to build. Once users get into the site, different scenarios of the city appear as they navigate it. Other instances included a loading animation, an error message, and a 404 error page:

Using the same illustration language we started building a graphic universe, communicating different messages with the same visual identity. We are able to enrich any instance in the site in a non-verbal way, without losing identity but widening our possibilities of expression.

Two valuable conclusions

Vector graphics gave us the possibility to work with SVG and CSS animations. This way we could deliver low file sizes with the best quality resolution and performance that adapt to every viewport.

Agile methodologies were not only used in the development instance of this project, but also in the UI/UX definition phase. We made the illustration process part of our sprints, which helped us to get the client involved at every point of the process. Their input was key, they gave us the freedom to propose a new language, they guide us through the way to make it work with their current brand and committed with every detail of each illustration.

Supongamos que alguien te pide que agregues un borde doble a algunas formas geométricas en SVG aleatorias. Por algun motivo, no podes usar ningún editor gráfico, deben generarse en tiempo de ejecución, por lo que tenes que resolverlo con CSS o dentro de la sintaxis SVG.

Tu primera pregunta podría ser: ¿Hay algo como stroke-style: double en SVG? La respuesta es aún no y tampoco es tan fácil. Pero voy a hacer el intento de todos modos para ver qué métodos puedo descubrir. Voy a explorar las posibilidades de tres formas básicas diferentes: círculo, rectángulo y polígono. Señalando las que pueden mantener un color transparente en medio de las dos líneas.

Alerta de spoiler: todos los resultados tienen sus desventajas, al menos con CSS y SVG, pero les muestro mis intentos.

Las soluciones simples

Estos no funcionan con todas las formas, pero son las soluciones más fáciles.

outline y box-shadow

Las propiedades CSS outline y box-shadow solo se aplican al bounding box de la forma o SVG, por lo que ambas son excelentes soluciones solo para cuadrados y rectángulos. También permiten colores flexibles usando custom properties.

Solo se necesitan dos líneas de CSS con "outline", además de que mantiene el color de fondo visible a través de la forma.

• 🙁 Solución solo para una forma.
• ✅ Código sencillo
• ✅ Los bordes son suaves
• ✅ Fondo transparente

box-shadow solo necesita una línea de CSS, pero tenemos que asegurarnos de que cada forma tenga su propio SVG ya que no podemos aplicar box-shadow directamente a las formas. Otra cosa a tener en cuenta es que tenemos que aplicar el color del fondo en la declaración.

• 🙁 Solución solo para una forma
• ✅ Código sencillo
• ✅ Los bordes son suaves
• 🙁 Sin fondo transparente

Gradientes SVG

Los degradados radiales SVG solo funcionan en círculos ☺️. Podemos aplicar directamente el degradado en el stroke o trazo, pero es mejor usar variables ya que tenemos que declarar los colores muchas veces en el código.

• 🙁 Solución solo para una forma
• ✅ Código sencillo
• 🙁 Los bordes son suaves
• 🙁 Sin fondo transparente

Soluciones para todas las formas

Estos funcionarán con todas las formas, pero el código podría volverse engorroso o complejo.

filter: drop-shadow()

¡Finalmente, una solución para todas las formas! Debemos tener cada forma en su propio <svg> ya que el filtro no se aplicará directamente a las formas. Estamos usando una declaración en CSS y tenemos colores flexibles usando variables. ¿Lo malo? Los bordes no se ven muy suaves.

• ✅ Una solución para todas las formas
• ✅ Código sencillo
• 🙁 Los bordes se ven pixelados
• 🙁 Sin fondo transparente

SVG filters

Esta es una solución muy flexible. Podemos crear un filtro y agregarlo a las formas a través del atributo filter de SVG. La parte complicada acá es el filtro en sí. Necesitaremos tres paints, una para el borde exterior, otra para rellenar el fondo y la última para pintar la forma en el frente. El resultado se ve mejor que usar drop-shadow, pero los bordes aún se ven pixelados.

• ✅ Una solución para todas las formas
• 🙁 Código complejo
• 🙁 Los bordes se ven pixelados
• 🙁 Sin fondo transparente

Reusando formas

Hay un par de opciones posibles aquí.

Opción 1: Transformaciones

Esta solución requiere transformaciones. Colocamos una figura sobre la otra, donde la figura principal tiene un color de relleno y un color de trazo, y la otra figura no tiene relleno, un trazo rojo, y se escala y reposiciona en el centro. Definimos nuestras formas en <defs>. El truco es traducir la mitad del viewBox al espacio negativo para que, cuando los escalemos, podamos hacerlo desde el centro de la figura.

• ✅ Una solución para todas las formas
• 🙁 Código duplicado
• ✅ Los bordes son suaves
• ✅ Fondo transparente

Opción 2: <usar>

Encontré una solución inteligente en la [lista de correo de www-svg](https://lists.w3.org/Archives/Public/www- svg/2013Jan/0005.html) de Doug Schepers que usa SVG <use>. Nuevamente, requiere definir las formas una vez y referirse a ellas dos veces usando <use>. Esta vez la forma principal tiene un trazo más grande. La segunda forma tiene la mitad del trazo de la forma principal, sin relleno y un trazo que coincide con el color de fondo.

• ✅ Una solución para todas las formas
• 🙁 Código duplicado
• ✅ Los bordes son suaves
• 🙁 Sin fondo transparente

¡Acá están los resultados completos!

Solo para que los tengas todos en un solo lugar. ¡Avísame si se te ocurren otras posibles soluciones!

Este artículo se publicó por primera vez en CSS-Tricks con ediciones de Chris Coyier y Geoff Graham ♥

No todas las pautas de marca incluyen definiciones para el uso de fotografías, ilustraciones o estilos de imagen. Lejos de ser un problema, esto podría significar una gran oportunidad para un proyecto de rediseño. Al cumplir con los requisitos para un proyecto de desarrollo de software, descubrimos la oportunidad de crear y explorar un universo visual para ampliar la identidad de nuestro cliente.

En cada sitio web encontramos espacios comunes para comunicar a los usuarios lo que está sucediendo. Lugares donde el mensaje es simple pero podemos contar una historia. Algunos de ellos incluyen inicios de sesión, páginas de error y cargas, comunican lo mismo en todos los sitios, y eso es lo que nos deja espacio para liberar algo de creatividad.

El punto de partida

El negocio de nuestro cliente consiste en ofrecer servicios a otras empresas, junto con una plataforma para administrarlos todos internamente. Nuestro trabajo fue rediseñar y repensar esa plataforma de servicio personalizado. En el momento en que comenzamos, tenían este sitio web que se construyó hace algunos años, tenía un diseño antiguo y algunos problemas de rendimiento y accesibilidad. Necesitaban un nuevo comienzo desde las perspectivas visual y técnica; algo simple, rápido y fácil de usar.

No era el típico sitio de productos con una página de inicio que explica lo que hacen y trata de venderlo. El usuario final de esta plataforma es un cliente que ya compró los servicios de nuestro cliente y utiliza esta plataforma para administrarlos en su propia empresa. Cuando llegan a este sitio es porque tienen credenciales y ya saben de qué se trata el sitio y para qué sirve.

En el lado bueno, los usuarios están de alguna manera preparados para lo que van a encontrar en el enlace. Vendrán a esta plataforma (quizás más de una vez al día) con una tarea que completar. Por lo tanto, es importante que no distraigamos al usuario de lo que está tratando de lograr.

Queríamos que el diseño fuera visualmente atractivo sin abarrotar el sitio, por lo que teníamos que elegir los momentos adecuados y las formas correctas de hacerlo. Nuestro objetivo era encontrar aquellos lugares donde pudiéramos hacer el sitio más amigable e integrado a la marca, teniendo en cuenta que el propósito principal de esta plataforma era administrar los servicios de una manera simple sin molestarlos.

La marca del cliente se definió con una paleta de colores, tipografía y estilo para los íconos, pero no había un lineamiento estricto para las imágenes e ilustraciones, y ahí vimos una oportunidad.

Elegir el formato adecuado

Descartamos el uso de la fotografía; las fotografías son más adecuadas para los productos, más literales y basadas en la realidad. Este sitio no se trataba de vender un producto ni de describirlo, sino de mejorar la experiencia de los usuarios actuales y ayudarlos a realizar sus tareas fácilmente. Las ilustraciones funcionan mejor para expresar conceptos y fácilmente podríamos incluir la paleta de colores de nuestro cliente para que sean parte de la marca. Además, los vectores pueden funcionar mucho mejor que las imágenes rasterizadas (hablaremos más sobre esto más adelante).

Nuestra propuesta fue construir un universo gráfico con ilustraciones para mostrar todos estos servicios de una manera más amigable y también para comunicar cuando algo estaba pasando en el sitio. Con la construcción de este universo gráfico estamos añadiendo un nuevo ingrediente a sus pautas, una solución diferente para abordar cualquier posible problema de comunicación visual. No estamos ofreciendo un conjunto de imágenes, sino un conjunto de reglas para un lenguaje que pueden seguir desarrollando y hacer parte de su marca.

Referencias primero

Comenzamos mostrando al cliente algunas referencias de ilustraciones con una pequeña descripción para que pudiera decidir qué estilo le representaba más. Algunas de estas imágenes incluían diferentes perspectivas, dimensiones, profundidades, caracteres, estilos de trazo, degradados y combinaciones de sólidos, bordes redondeados y afilados, entre otros. Desde el principio, descartamos cualquier textura compleja, efectos o ilustraciones súper realistas. Sabíamos que el rendimiento valdrá la pena si mantenemos las cosas simples desde el principio.

Prueba la idea con el estilo

El cliente escogió dos opciones, así que le entregamos unos pequeños bocetos para ir probando los estilos y al mismo tiempo hablar de las ideas a representar. El Login es la primera página que verá el usuario, y también la que tiene más espacio disponible para la creación. Aquí queríamos mostrar una ciudad donde conviven todos los servicios de nuestro cliente, por eso enviamos unos bocetos de la ciudad con ambos estilos:

Como mencionamos antes: cuando los usuarios llegan al inicio de sesión, saben de qué se trata el sitio. No necesitábamos explicar los servicios en detalle sino pensar en cómo la ilustración podría reforzar sus beneficios.

Después de que eligieron un estilo final y se aprobó la idea de la ciudad, comenzamos a discutir qué elementos mostrar y cómo representarlos.

Esta fase se trataba de obtener la mejor manera de mostrar todas las escenas de la ciudad hasta que se terminó el diseño de inicio de sesión. Fue entonces cuando comenzamos a centrarnos en el código y en elegir la mejor manera de implementar esas ilustraciones en el sitio.

Uso de SVG

Tan pronto como se aprobó la ilustración, exportamos el archivo de Illustrator a SVG, ya que es el mejor formato para usar imágenes vectoriales en la web. Decidimos usar el código SVG en línea en nuestro documento porque este enfoque nos permite hacer uso de animaciones. Repasemos algunos de los beneficios de SVG en línea:

• Tamaño de archivo muy bajo con la mejor resolución
• Opciones flexibles para un diseño receptivo
• Gran actuación
• Renderiza inmediatamente
• Accesible a través del DOM para que podamos interactuar con cualquier grupo de vectores
• Permite el control de algunos atributos a través de una hoja de estilo
• Permite animación CSS

Hay algunas formas de exportar el SVG, la más fácil es copiar los vectores de Illustrator y pegarlos en un editor de texto. Tan simple como eso:

El software agrega mucho código que no es necesario y perjudica la legibilidad y el rendimiento. Por eso, una herramienta como SVGOMG nos ayuda a optimizar el archivo de forma rápida y sencilla. Profundizando en esa dirección, la optimización manual suele ser parte de nuestro proceso. Otra cosa importante a tener en cuenta es que SVG es un gran aliado para la accesibilidad.

Ahora tenemos nuestro código limpio y podemos comenzar a agregar clases a los elementos que queremos animar. En este caso, las animaciones CSS fueron suficientes para construir estas animaciones simples.

Este fue el resultado de la página de inicio de sesión, la ilustración SVG pesa solo 42k después de la optimización:

Nota: el gif se muestra en un bucle, pero algunas animaciones se reproducían solo una vez.

Una vez que la animación principal estuvo lista, las instancias más pequeñas fueron más fáciles de construir. Una vez que los usuarios ingresan al sitio, aparecen diferentes escenarios de la ciudad a medida que navegan. Otras instancias incluyeron una animación de carga, un mensaje de error y una página de error 404:

Con el mismo lenguaje de ilustración empezamos a construir un universo gráfico, comunicando diferentes mensajes con una misma identidad visual. Somos capaces de enriquecer cualquier instancia del sitio de forma no verbal, sin perder identidad pero ampliando nuestras posibilidades de expresión.

Dos valiosas conclusiones

Los gráficos vectoriales nos dieron la posibilidad de trabajar con animaciones SVG y CSS. De esta manera, podríamos entregar tamaños de archivo bajos con la mejor resolución de calidad y rendimiento que se adapte a cada ventana gráfica.

No solo se utilizaron metodologías ágiles en la instancia de desarrollo de este proyecto, sino también en la fase de definición de UI/UX. Hicimos el proceso de ilustración parte de nuestros sprints, lo que nos ayudó a involucrar al cliente en cada punto del proceso. Su aporte fue clave, nos dieron la libertad de proponer un nuevo lenguaje, nos guiaron en la forma de hacerlo funcionar con su marca actual y se comprometieron con cada detalle de cada ilustración.

Nerdearla is an annual conference with talks and workshops about technology and science here in Buenos Aires.

As sponsors of the event with Leniolabs, we used to have a stand where people could come by and say hi, play games with us, talk about technologies we love, and get some of our alien merch. It was the perfect excuse to get to know each other in this community.

Then the pandemic changed everything. And the event as we knew it was not possible anymore. They resolved to make this last edition online, so we decided to build a site to still be able to interact with people and play the games we’ve been developing. We didn’t know what to expect. Trying to keep closer in the distance was a challenge for us. But at the same time, there was a bigger audience to connect to, as many speakers and attendees could be present from any part of the world.

We first attempted to create an interactive city to chat in bars or share articles in the library, talk in the theatres, or play games in the park. But all those places seemed far away from our reality at that moment.

Then the popular #stayathome hashtag hit us: why not illustrate our own house at Leniolabs?

Each room would refer to one area of the company; we had our videos of workshops and talks in the garage, our blog posts in the home library, the live chat in the living room, the games in the garden, the trivia challenges in the loft, our lab in the basement, the Bootcamp we were cooking at the kitchen, and the job section in the office room. And everyone was invited; we wanted to share what happens inside Leniolabs, our internal workshops, and articles we write to share our knowledge.

Coding the design and making it responsive

There was a challenge to make this website mobile-friendly as the whole site was a big illustration. After playing around with different approaches, we decided to use Layoutit to build a CSS Grid. We exported every room as a single SVG and made every SVG a component. Then we created a grid where every grid item was one of these components. We changed the layout and the position of the grid areas depending on the screen size, going from 4 column layout on large screens to a single column on mobile.

The technology used

We chose Nuxt as we needed a site that would last 5 days but with one month to build it from scratch. No time was lost in router configuration, auto imported components, and a nice folder structure in a pre-rendered site. And we chose Netlify as we needed to iterate and share the results often. A free, serverless platform to push and deploy.

CSS animations

We used some small animations on hover to make the house a little bit more alive—all with preferred reduce-motion for accessibility.

Night mode and easter eggs

After a certain hour, the house switches off, some of the lights are out, and others are on. The sleeping cat is now catching a spider; Leni (our alien mascot) falls asleep outside the house. We love the idea that the more you visit the site, the more details you’ll find hidden. Every SVG is a reusable component that appears on each internal page and changes as the dark mode turns on.

Between 4 pm and 7 am, this function adds a class to the container of the site to activate the dark mode:

<template>
 <div :class="{ night: isDark }">
 ...
</template>
<script>
 export default {
  data() {
   return { isDark: false };
  },
 methods: {
  updateTime() {
   if (process.client) { 
    const hours = new Date().getHours();
    this.isDark = hours < 7 || hours > 16;
   }
  },
 },
...
</script>

This ended up being our official event site for Nerdearla, as they will continue doing it online and we are part of the 2021 edition from 20 to 23rd of October. We will be hosting games and sending gifts to everyone who will join us this year! But even if you don’t join the conference you can still visit our virtual stand at https://nerdearla.leniolabs.com

More details about the making of the site are in this talk (Spanish version):

Diseño de UI/UX para prototipo de aplicación móvil

“La mayoría de las personas viven en un círculo restringido de potencial”. -Guillermo James

¿Para quién es la aplicación?

Nuestros dispositivos móviles se han convertido en una parte indispensable de nuestras vidas: los llevamos a todas partes, así que ¿por qué no usarlos para un poco de entrenamiento de vida? Comfort Shatter es para personas que quieren mejorar su crecimiento y desarrollo personal; los desafíos diarios crean un circuito de retroalimentación positiva que puede ayudar con la felicidad y la realización.

Propuesta

Comfort Shatter es una aplicación que presenta a los usuarios desafíos para salir de su zona de confort. Ofrece diferentes paquetes y se atreve a enfrentar los miedos sociales, mejorar la autoestima y desafiar los límites. Permite a los usuarios realizar un seguimiento de su propio progreso, invitar a amigos y compartir sus ganancias diarias en las redes sociales.

Estructuras alámbricas

Comenzando con algunos bocetos. sacar las ideas de la cabeza y ponerlas en papel.

Inspiración de diseño

Buscando algunos colores vibrantes para una paleta moderna, monstruos amigables para representar los desafíos, formas redondeadas y fuentes de pincel.

Diseñando la aplicación

Es hora de trabajar en algunas maquetas de alta fidelidad. Buscando contraste de color, ajustando el diseño de personajes y marcando las reglas para futuras capturas de pantalla.

Guía de estilos

Montserrat como fuente principal para legibilidad en todo el sitio y Supermarket VTS Sale para títulos destacados. Usando formas redondas y círculos para una apariencia amigable.

Flujo de usuario

Esbozar el flujo de usuario antes de construir el prototipo final.

Prototipo final

La maqueta final con interacciones antes de entrar en desarrollo. Construido con InVision Studio y la aplicación InVision. Monstruos construidos con Adobe Illustrator.

Comfort Shatter from Mariana Beldi on Vimeo.

UI/UX design for mobile app prototype

“Most people live in a restricted circle of potential.”
-William James

Who is the app for?

Our mobile devices have become an indispensable part of our lives: we carry them everywhere we go, so why not use them for a bit of life coaching? Comfort Shatter is for people who want to improve their personal growth and development; the daily challenges create a positive feedback loop that can help with happiness and fulfillment.

Proposal

Comfort Shatter is an app that brings users challenges to break out of their comfort zone. It offers different packages and dares to face social fears, improve self-esteem, and challenge the limits. It allows users to track their own progress, invite friends, and share their daily wins on social networks.

Wireframes

Starting with some sketches. get the ideas out of the head and down on paper.

Design inspiration

Looking for some vibrant colors for a modern palette, friendly monsters to represent the challenges, rounded shapes, and brush fonts.

Designing the app

Time to work on some high fidelity mockups. Looking for color contrast, adjusting character design and setting the rules for future screenshots.

Guidelines

Montserrat as the main font for legibility across the site and VTS Supermarket sale for outstanding titles. Using round shapes and circles for a friendly look and feel.

User flow

Sketching the user flow before building the final prototype.

Final prototype

The final mockup with interactions before getting into development.
Built with InVision Studio and InVision App. Monsters built with Adobe Illustrator.

Comfort Shatter from Mariana Beldi on Vimeo.

Mientras aprendía Vue.js, comencé a crear herramientas web gratuitas que involucraban la exploración de SVG, ¡con el objetivo de aprender algo sobre ambos! Echemos un vistazo a una de esas herramientas: un generador que crea cargadores SVG y te permite elegir entre animación SMIL o Sass, diferentes estilos, colores, formas y efectos. Incluso permite pegar un path, SVG o texto personalizado y luego descargar el SVG final, copiar el código o abrir una demostración en CodePen.

Cómo empezó

Tres coincidencias me llevaron a construir un generador para cargadores SVG.

Coincidencia 1: el libro de Sarah Drasner

La primera vez que leí sobre los bucles de Sass fue en *SVG Animations* de Sarah Drasner. Ella muestra cómo escalonar animaciones con una función Sass (como lo hace en el Capítulo 6, "Animación de visualizaciones de datos").

Me inspiré en ese capítulo y en las posibilidades de los loops de Sass.

Coincidencia 2: Un GIF

En ese mismo momento de la vida, me pidieron que replicara un elemento "cargador", similar al viejo clásico de Apple.

Hice referencia al ejemplo de Sarah para que esto sucediera. Este es el código de bucle Sass que logré:

    @for $i from 1 to 12 {
      .loader:nth-of-type(#{$i}) {
        animation: 1s $i * 0.08s opacityLoader infinite;
      }
    }

    @keyframes opacityLoader {
     to { opacity: 0; }
    }

Esto define una variable para un número (i) del 1 al 12 que aumenta el delay de la animación con cada elemento :nth-child. Fue el caso de uso perfecto para animar tantos elementos como quisiera con solo dos líneas de Sass, ahorrándome declaraciones CSS para cada uno de los delays que necesitaba. Esta es la misma animación, pero escrita en Vanilla CSS para mostrar la diferencia:

    .loader:nth-of-type(1) {
      animation: 1s 0.08s opacityLoader infinite;
    }
    .loader:nth-of-type(2) {
      animation: 1s 0.16s opacityLoader infinite;
    }

    ...

    .loader:nth-of-type(12) {
      animation: 1s 0.96s opacityLoader infinite;
    }
    @keyframes opacityLoader {
      to { opacity: 0; }
    }

Coincidencia 3: Una idea

Con estas cosas en mi cabeza, tuve la idea de crear una galería de loaders, donde cada loader esté hecho con el mismo bucle Sass. Siempre me cuesta encontrar este tipo de assets online, así que pensé que podría ser útil para otros también.

Ya había construido un generador de íconos antes como proyecto personal, así que [terminé construyendo un generador de loaders] (http://holasvg.com/loaders). ¡Avisame si encontras errores!

Un cargador, dos salidas

Estaba bloqueada por mis propias habilidades de desarrolladora mientras creaba un generador que produzca el código Sass correcto. Así que decidí probar otro enfoque de animación con SMIL animations, y eso fue lo que decidí usar.

Pero recibí un poco de ayuda (¡gracias, ekrof!) y terminé agregando ambas opciones al generador. Descubrí que era un desafío hacer que ambos idiomas arrojaran el mismo resultado. De hecho, a veces producen resultados diferentes.

SMIL vs CSS/Sass

Aprendí bastante sobre animaciones SMIL y CSS/Sass en el camino. Estos son algunos de los puntos clave que me ayudaron para hacer el generador:

• SMIL no depende de ningún recurso externo. Anima SVG a través de atributos de presentación directamente en el SVG. Eso es algo que ni CSS ni Sass pueden hacer.

• Las animaciones SMIL se conservan cuando se usa un SVG como imagen o como imagen de fondo. Es posible agregar un bloque CSS

• Las animaciones SMIL se ven un poco más fluidas. No pude encontrar la razón de esto (si alguien tiene más información acá, ¡bienvenida!). Pensé que estaba relacionado con la aceleración de GPU, pero parece que ambos usan el mismo motor de animación.

Se puede notar una diferencia en el encadenamiento de las animaciones entre ambos idiomas:

• Usé additive="sum" en SMIL para agregar animaciones una tras otra. Esto asegura que cada nuevo efecto de animación evite anular la animación anterior.

• Dicho esto, en CSS/Sass, la W3C señala que [cuando] varias animaciones intentan modificar la misma propiedad, gana la animación más cercana al final de la lista de nombres.

Es por eso que el orden en que se aplican las animaciones puede cambiar el resultado en Sass.

Trabajar con transformaciones

Trabajar con transformaciones en los estilos del loader fue un gran problema. Apliqué transform: rotate inline a cada forma porque es una forma sencilla de colocarlas una al lado de la otra en un círculo y con una cara apuntando hacia el centro.

  <svg>
    ...
    <use class="loader" xlink:href="#loader" transform="rotate(0 50 50)" /> 
    <use class="loader" xlink:href="#loader" transform="rotate(30 50 50)" />
    <use class="loader" xlink:href="#loader" transform="rotate(60 50 50)" />
    ...
  </svg>

Podría declarar un tipo en SMIL con (por ejemplo, escalar o trasladar) para agregar esa transformación específica a la transformación original de cada forma:

  <animateTransform attributeName="transform" 
    type="translate"
    additive="sum" 
    dur="1s"
    :begin="`${i * 0.08}s`"
    repeatCount="indefinite"
    from="0 0"
    to="10"
  />

Pero en cambio, la transformación en CSS anulaba cualquier transformación anterior aplicada al SVG inline. En otras palabras, la posición original se restableció a 0 y mostró un resultado muy diferente al producido por SMIL. Eso significaba que las animaciones terminaron luciendo idénticas sin importar qué.

La solución (no muy bonita) para hacer que Sass sea similar a SMIL fue colocar cada forma dentro de un elemento de grupo () y aplicar la rotación inline a los grupos y la animación a las formas. De esta manera, la transformación inline no se ve afectada por la animación.

  <svg>
    ... 
    <g class="loader" transform="rotate(0 50 50)">
     <use xlink:href="#loader" />
    </g>
    <g class="loader" transform="rotate(30 50 50)">
     <use xlink:href="#loader" />
    </g>
    ...
  </svg>

Ahora ambos lenguajes tienen un resultado muy similar.

La tecnología que utilicé

Usé Vue.js y Nuxt.js. Ambos tienen una excelente documentación, pero hay razones más específicas por las que los elijo.

Me gusta Vue por muchas razones:

• Vue encapsula HTML, CSS y JavaScript como un "[componente de archivo único] (https://github.com/marianabeldi/holasvg-loaders/blob/main/components/Codes.vue)" donde vive todo el código en un solo archivo con el que es más fácil trabajar.

• La forma en que Vue vincula y actualiza dinámicamente los atributos HTML o SVG es muy intuitiva.

• HTML y SVG no requieren transformaciones adicionales (como hacer que el código sea compatible con JSX).

En cuanto a Nuxt:

• Tiene un modelo rápido que lo ayuda a concentrarse en el desarrollo en lugar de la configuración.

• Hay rytas automáticas y admite componentes de importación automática.

• Es una buena estructura de proyecto con páginas, componentes y diseños.

• Es más fácil optimizar para SEO, gracias a las metatags.

Veamos algunos loaders de ejemplo

Lo que me gusta del resultado final es no hay una sola forma de usarlo. Debido a que genera tanto SMIL como CSS/Sass, hay varias formas de integrar un loader en tu propio proyecto.

Descarga el SMIL SVG y utilízalo como imagen de fondo en CSS

Como mencioné anteriormente, las características de SMIL se conservan cuando se usa un SVG como archivo de imagen de fondo. Entonces, simplemente hay que descargar el SVG del generador, subirlo al servidor y hacer referencia a él en CSS como imagen de fondo.

De manera similar, podríamos usar el SVG como imagen de fondo de un pseudo-elemento:

Coloque el SVG directamente en HTML

El SVG no tiene que ser una imagen de fondo. Es solo código, después de todo. Eso significa que simplemente podemos colocar el código del generador en nuestro propio código y dejar que SMIL haga lo suyo.

Usar un loop Sass en el SVG inline

Esto es lo que originalmente me inspiró, pero me encontré con algunos obstáculos. En lugar de escribir declaraciones CSS para cada animación, podemos usar el loop Sass producido por el generador. El loop apunta a una clase .loader que ya se aplicó al SVG generado. Entonces, una vez que Sass se compila en CSS, obtenemos una buena animación giratoria.

Todavía estoy trabajando en esto

Mi parte favorita del generador es la opción personalizada donde puedes agregar texto, emojis o cualquier elemento SVG a la mezcla:

Lo que me gustaría hacer es agregar una tercera opción para que los estilos tengan solo un elemento en el que pueda trabajar y permitir resultados más simples.

El desafío de este proyecto es agregar opción de valores personalizados para muchas cosas, como duración, dirección, distancia y grados. Otro desafío para mí personalmente es familiarizarme más con Vue porque necesitaría limpiar el código desordenado. Dicho esto, el proyecto es de código abierto, ¡y las solicitudes para hacer cambios son bienvenidas! Sean librs de enviar sugerencias, comentarios o incluso recomendaciones de cursos de Vue, especialmente aquellos relacionados con SVG o la creación de generadores.

Todo esto comenzó con un loop de Sass que leí en un libro. No es el código más limpio del mundo, pero estoy impresionada por el poder de las animaciones SMIL. Recomiendo encarecidamente la guía de Sarah Soueidan para profundizar en lo que SMIL es capaz de hacer.

Si tienen curiosidad acerca de la seguridad de SMIL, es por una buena razón. Hubo un momento en que Chrome iba a deprecar por completo SMIL (ver la nota de apertura en MDN). Pero lo suspendiaron y no se volviío a hablar de esto (aparentemente).

¿Puedo usar SMIL?

Este artículo se publicó por primera vez en CSS-Tricks . Gracias a las ediciones de Chris Coyier y Geoff Graham ♥

Lea la versión en chino aquí. Traducido por Rotten orange 腐烂的橘子

Hay diferentes formas de trabajar con íconos, pero la mejor solución siempre incluye SVG, ya sea inline o vinculado como un archivo. A veces, los íconos que descargamos (o los que creamos con un software de dibujo) tienen mucho código innecesario que, si lo usamos en línea, hace que nuestro documento sea más largo para desplazarse, incómodo para trabajar y un poco más pesado. .

Podemos solucionar esto reutilizando fragmentos de código con el elemento <use> o [aplicar variables nativas a administre nuestros estilos SVG] (http://localhost:56203/posts/use-and-reuse-everything-in-svg-even-animations) desde un solo lugar.

Acá quiero enfocarme en una perspectiva diferente: cómo hacer las mismas figuras con menos código usando formas básicas. Y obtener los beneficios de íconos más pequeños, controlables y semánticos en nuestros proyectos sin sacrificar la calidad o los cambios visuales. Revisaré diferentes ejemplos que exploran el código de los íconos de uso común y cómo podemos volver a dibujarlos usando algunas de las formas SVG más fáciles que podemos hacer.

Estos son los iconos en los que trabajaremos:

Veamos las formas básicas que podemos usar para hacer que el código sea pequeño y simple.

Psssst! ¡Aquí hay una lista más larga de íconos simples que creé en holasvg.com! Después de este artículo, podran cómo modificarlos y hacerlos suyos.

Construyendo un icono de cerrar con el elemento <line>

Este es el código para el icono de cerrar o cruz que se descargó de flaticon.com y lo creó [pixel-perfect](https://www.flaticon.com/authors/ pixel perfect):

En este ejemplo, todo sucede dentro de <path> con muchos comandos y parámetros en el atributo de datos d. Lo que hace este SVG es trazar la forma desde sus bordes.

Si están familiarizados con Illustrator, esto es el equivalente a dibujar dos líneas separadas, convertirlas en forma y luego combinarlas con el pathfinder para crear una forma compuesta.

El elemento <path> nos permite dibujar formas complejas, pero en este caso, podemos crear la misma figura con dos líneas, manteniendo la misma apariencia:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 50 50" width="50" height="50" overflow="visible" stroke="black" stroke-width="10" stroke-linecap="round">
   <line x1="0" y1="0" x2="50" y2="50" />
   <line x1="50" y1="0" x2="0" y2="50" />
</svg>

Empezamos definiendo un viewBox que va de 0,0 a 50,50. Pueden elegir las dimensiones que prefieran; el SVG siempre se escalará bien a cualquier ancho y alto que se defina. Para facilitar las cosas, en este caso, también definí un ancho y alto en línea de 50 unidades, lo que evita cálculos adicionales en el dibujo.

Para usar el elemento <línea>, declaramos las coordenadas del primer punto de la línea y las coordenadas de su último punto. En este caso específico, empezamos desde x=0 y=0 y terminamos en x=50 y=50.

Así es como se ve en el código:

<line x1="0" y1="0" x2="50" y2="50" />

La segunda línea comenzará desde x=50 y=0 y terminará en x=0 y=50:

<line x1="50" y1="0" x2="0" y2="50" />

Un trazo SVG no tiene un color por defecto, por eso agregamos el valor negro en el atributo stroke. También le dimos al atributo 'stroke-width' un ancho de 10 unidades y a 'stroke-linecap' un valor 'round' para replicar esas esquinas redondeadas del diseño original. Estos atributos se agregaron directamente a la etiqueta <svg> para que ambas líneas los hereden.

<svg ... stroke="black" stroke-width="10" stroke-linecap="round" ...>

Ahora que el trazo es 10 unidades más grande que su tamaño predeterminado de 1 unidad, la línea podría quedar recortada por viewBox. Podemos mover los puntos 10 unidades dentro de viewBox o agregar overflow=visible a los estilos.

Los valores que son iguales a 0 se pueden eliminar, ya que 0 es el valor predeterminado. Eso significa que las dos líneas terminan con dos líneas de código muy pequeñas:

<line x2="50" y2="50" />
<line x1="50" y2="50" />

Con solo cambiar <path> a <line>, no solo creamos un archivo SVG más pequeño, sino también un fragmento de código más semántico y controlable que hace que cualquier mantenimiento futuro sea mucho más fácil. Y el resultado visual es exactamente igual que el original.

Misma cruz, diferente código.

Construyendo un icono de reloj con los elementos <circle> y <path>

Tomé este ejemplo de un icono de reloj creado por barracuda de The Noun Project:

Esta forma también se dibujó con <path>, pero también tenemos muchos espacios de nombres e instrucciones XML relacionadas con el software utilizado y la licencia del archivo que podemos eliminar sin afectar el SVG. ¿Pueden adivinar qué editor de ilustraciones se usó para crear el icono?

Recreemos este desde cero usando un círculo y un path con comandos más simples. Nuevamente, debemos comenzar con un viewBox, esta vez de 0,0 a 100,100, y con un ancho y alto que coincidan con esas unidades.

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100" fill="none" stroke="black" stroke-width="10" stroke-linecap="round" stroke-linejoin="round">
  <circle cx="50" cy="50" r="40"/>
  <path d="M50 25V50 H75" /> 
</svg>

Mantenemos los mismos estilos que el ícono anterior dentro de la etiqueta <svg>. fill es black de forma predeterminada, por lo que debemos darle explícitamente un valor none para eliminarlo. De lo contrario, el círculo tendrá un relleno negro sólido, oscureciendo las otras formas.

Para dibujar el <circle> necesitamos indicar un punto central desde donde se asentará el radio. Podemos lograr eso con cx (centro x) y cy (centro y). Entonces r (radio) declarará qué tan grande será nuestro círculo. En este ejemplo, el radio es ligeramente más pequeño que el viewBox, por lo que no se recorta cuando el trazo tiene 10 unidades de ancho.

¿Qué pasa con todas esas letras? Consulten la guía ilustrada de Chris Coyier para obtener una introducción a la sintaxis SVG.

Podemos usar un <path> para las manecillas del reloj porque tiene algunos comandos muy útiles y simples para dibujar. Dentro de la d (data) debemos comenzar con el comando M (mover a) seguido de las coordenadas desde donde comenzaremos a dibujar que, en este ejemplo, es 50,25 (cerca del centro superior de la círculo).

Después del comando V (vertical), solo necesitamos un valor ya que solo podemos movernos hacia arriba o hacia abajo con un número negativo o positivo. Un número positivo bajará. Lo mismo para 'H' (horizontal) seguido de un número positivo, 75, que dibujará hacia la derecha. Todos los comandos están en mayúsculas, por lo que los números que elijamos serán puntos en la cuadrícula. Si decidimos usar minúsculas (comandos relativos) los números serán la cantidad de unidades que nos movemos en una dirección y no un punto absoluto en el sistema de coordenadas.

Mismo reloj, diferente código.

Construyendo un icono de sobre con los elementos <rect> y <polyline>

Dibujé el ícono del sobre en Illustrator sin expandir las formas originales. Aquí está el código que vino de la exportación:

Hey! Illustrator ofrece algunas opciones de SVG para exportar el gráfico. Elegí Style Elements en el menú desplegable Propiedades de CSS para poder tener una etiqueta <styles> que contenga clases que podría querer mover a un archivo CSS. Pero hay diferentes formas de aplicar los estilos en SVG, por supuesto.

¡Ya tenemos formas básicas en este código! Deseleccioné la opción Shape to Path en Illustrator, lo que ayudó mucho. Podemos optimizar esto aún más con SVGOMG para eliminar los comentarios, las instrucciones XML y los datos innecesarios, como elementos vacíos. A partir de ahí, podemos eliminar manualmente otros extras, si es necesario.

Ya tenemos algo un poco más conciso:

<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" x="0" y="0" viewBox="0 0 310 190" xml:space="preserve">
  <style>.st0{fill:none;stroke:#000;stroke-width:10;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10}
  </style><rect x="5" y="5" class="st0" width="300" height="180"/>
  <polyline class="st0" points="5 5 155 110 305 5"/>
</svg>

Podemos eliminar aún más cosas sin afectar la apariencia visual del sobre, incluyendo:

• version="1.1" (esto ha sido obsoleto desde SVG 2)
• id="Layer_1" (esto no tiene significado ni uso)
• x="0" (este es un valor predeterminado)
• y="0" (este es un valor predeterminado)
• xml:space="preserve" (esto ha sido obsoleto desde SVG 2)

<svg xmlns="http://www.w3.org/2000/svg" x="0" y="0" viewBox="0 0 310 190">
  <style>.st0{fill:none;stroke:#000;stroke-width:10;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:10}
  </style>
  <rect x="5" y="5" class="st0" width="300" height="180"/>
  <polyline class="st0" points="5 5 155 110 305 5"/>
</svg>

Podemos mover los estilos CSS a una hoja de estilo separada si queremos ser realmente agresivos.

<rect> necesita un punto de partida desde donde extenderemos un ancho y una altura, así que usemos x="5" y y="5", que es nuestro punto superior izquierdo. A partir de ahí, crearemos un rectángulo de 300 unidades de ancho con una altura de 180 unidades. Al igual que el icono del reloj, usaremos 5,5 como punto de partida porque tenemos un trazo de 10 unidades que se recortará si las coordenadas se encuentran en 0,0.

<polyline> es similar a <line>, pero con una cantidad infinita de puntos que definimos, como pares de coordenadas, uno tras otro, dentro del atributo de puntos, donde el primer número del par representará x y el segundo será y. Es más fácil leer la secuencia con comas, pero se pueden reemplazar con espacios en blanco sin afectar el resultado.

Mismo sobre, distinto código.

¡Bonus de formas!

No incluí ejemplos de íconos que se pueden simplificar con las formas <polygon> y <ellipse>, pero acá hay una forma rápida de usarlos.

<polygon> es lo mismo que <polyline>, solo que este elemento siempre definirá una forma cerrada. Aquí hay un ejemplo que viene [directamente de MDN] (https://developer.mozilla.org/en-US/docs/Web/SVG/Element/polygon):

¿Recuerdan el círculo que dibujamos antes para el icono del reloj? Reemplacen r (radio) con rx y ry. Ahora tienen dos valores diferentes para el radio. Aquí hay otro [ejemplo de MDN] (https://developer.mozilla.org/en-US/docs/Web/SVG/Element/ellipse):

Terminando

¡Cubrimos mucho acá en un corto período de tiempo! Si bien usamos ejemplos para demostrar el proceso de optimización de SVG, esto es lo que espero que se lleven de esta publicación:

• Recuerden que la compresión comienza con la forma en que se dibuja el SVG en el software de ilustración.
• Usen las herramientas disponibles, como SVOMG, para comprimir SVG.
• Eliminen los metatags innecesarios a mano, de ser necesario.
• Reemplacen paths complejos con formas básicas.
• <use> es una excelente manera de incluir SVG en línea, así como para establecer su propia biblioteca de iconos reutilizables.

¿Cuántos iconos se pueden crear combinando estas formas básicas?

Estoy trabajando en mi lista en holasvg.com/icons, estaré subiendo constantemente más íconos y optimizaciones acá, y ahora ya saben cómo modificarlos fácilmente con solo cambiar algunos números. ¡Haganlos tuyos!

Este artículo se publicó por primera vez en CSS-Tricks con ediciones de [Chris Coyier](https: //chriscoyier.net/) y Geoff Graham

Animations are the best way to bring life to our websites: they help us tell stories and communicate what is happening at that moment. They naturally catch our attention so it’s important to learn how and when to apply them. If we use animations in the right way, we can improve our website’s usability, if we abuse them we can ruin the user experience.

In this article we’ll show an example of interactive animations, the ones that appear right after the users take an action and can help them notice the results.

A good case for using SVG interactions are form validations. We can let the user know what is happening at the time they interact with the inputs.

In this example we need both inputs to be filled. As soon as the user types any letter the green check icon will confirm that the input is valid. This is a small interaction that we can achieve by adding the required HTML5 attribute to our text input or textarea like this:

<input type=”text” name=”name” id=”name” aria-required=”true” autocorrect=”off” required>

In CSS we use the selector + pseudo-class: input:valid or textarea:valid with a SVG in the background that will show only when the element is valid:

input#name:valid, 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;
  border: 3px solid $lightgreen;
  transition: background ease 0.2s;
}

When adding an inline SVG in CSS is important to use the namespace xmlns=”http://www.w3.org/2000/svg" or the image won’t be displayed.

The transition of the background will make the SVG move from its initial position to 98% to the right, as defined in the background shorthand in CSS.

In JavaScript we can check those validations and add a class to the form (and the SVGs) when both fields are completed, and another class if at least one input is empty. Each class will bind to a CSS animation: one will make the form shake and the envelop fall out of the Send button; the other one will make the envelop fly directly to the mailbox and the red flag will be up.

document.getElementById(‘sendBtn’).addEventListener(‘click’, function (e) { 
 if (submitName[‘0’].validity.valid && submitText[‘0’].validity.valid) {
 e.preventDefault();
  message.classList.remove(‘not-active’);
  message.classList.add(‘active’);
  mailbox.classList.add(‘active’);
 }
 else {
  message.classList.add(‘not-active’);
  formshake.classList.add(‘active’);
 }
});

Here is the complete code:

SVG tiene este atributo de presentación stroke-miterlimit. Probablemente lo hayan visto al exportar un SVG desde un programa de edición de gráficos, o tal vez descubran que pueden eliminarlo sin notar ningún cambio en la apariencia visual.

Después de una buena cantidad de investigación, una de las primeras cosas que descubrí es que el atributo funciona junto con stroke-linejoin, y les mostraré cómo, además de muchas otras cosas, aprendí sobre este interesante (y posiblemente olvidado) atributo SVG.

##TLDR;

stroke-miterlimit depende de stroke-linejoin: si usamos round o bevel para las uniones, entonces no hay necesidad de declarar stroke-miterlimit. Pero si usamos miter en su lugar, aún podemos eliminarlo y tal vez el valor predeterminado sea suficiente. Tengan en cuenta que muchos editores de software gráfico agregarán este atributo incluso cuando no sea necesario.

¿Qué es stroke-linejoin?

Sé que en realidad estamos aquí para hablar sobre stroke-miterlimit, pero quiero comenzar con stroke-linejoin debido a funcionan muy juntos. Esta es la definición de stroke-linejoin extraída directamente del SVG Working Group (SVGWG):

stroke-linejoin especifica la forma que se utilizará en las esquinas de los paths o formas básicas cuando se trazan.

Esto significa que podemos definir cómo se ve la esquina cuando dos líneas se encuentran en un punto. Y este atributo acepta cinco valores posibles, aunque dos de ellos no tienen implementación de navegador [](https://github.com/w3c/svgwg/ issues/592) y están identificados por la especificación como en riesgo de ser deprecados. Por lo tanto, presentaré brevemente los tres valores admitidos que acepta el atributo.

miter es el valor predeterminado y resulta que es el más importante de los tres que estamos viendo. Si no declaramos explícitamente stroke-linejoin en el código SVG, entonces se usa miter para dar forma a la esquina de un path. Sabemos que una unión se establece en "inglete" cuando ambos bordes se encuentran en un ángulo agudo.

Pero también podemos elegir "redondo", que suaviza los bordes con, claro, esquinas redondeadas.

Mientras tanto, el valor bevel produce un borde plano que parece una esquina recortada.

¿Qué es stroke-miterlimit?

Bien, ahora que sabemos qué es stroke-linejoin, volvamos al tema que nos ocupa y seleccionemos la definición de stroke-miterlimit del libro [Using SVG with CSS3 and HTML5](https://www .oreilly.com/library/view/using-svg-with/9781491921968/):

[…] en esquinas realmente cerradas, tienes que extender el trazo por una distancia considerable, antes de que los dos bordes se encuentren. Por esa razón, existe una propiedad secundaria: stroke-miterlimit. Define hasta dónde puede extender el punto al crear una esquina de inglete.

En otras palabras, stroke-miterlimit establece qué tan lejos va el trazo de los bordes antes de que puedan encontrarse en un punto. Y solo cuando stroke-linejoin es miter.

Por lo tanto, el valor de stroke-miterlimit puede ser cualquier número entero positivo, donde 4 es el valor predeterminado. Cuanto más alto sea el valor, más lejos podrá ir la forma de la esquina.

Cómo trabajan juntos

Probablemente ahora tenga una buena comprensión conceptual de cómo stroke-linejoin y stroke-miterlimit funcionan juntos. Pero dependiendo del valor de stroke-miterlimit, es posible que obtengas algunos resultados aparentemente extravagantes.

Caso en cuestión: si 'stroke-linejoin' se establece en 'miter', en realidad puede terminar pareciéndose al valor de 'bevel' cuando el límite de inglete es demasiado bajo. Acá está la especificación nuevamente para ayudarnos a entender por qué:

Si la longitud del inglete dividida por el ancho del trazo supera el stroke-miterlimit, [el valor de inglete] se convierte en un bisel (bevel).

Entonces, matemáticamente podríamos decir que esto:

[longitud de inglete] / [ancho de trazo (o stroke)] > [límite de inglete (o stroke-miterlimit)] = inglete (miter)
[longitud de inglete] / [ancho de traza (o stroke)] < [límite de inglete (o stroke-miterlimit)l (bevel)

Eso tiene sentido, no? Si el inglete no puede exceder el ancho del trazo, entonces debe ser un borde plano. De lo contrario, el miter puede crecer y formar una punta.

A veces hay que ver para creer, así que acá está Ana Tudor con una maravillosa demostración que muestra cómo el valor stroke-miterlimit afecta el stroke-linejoin de un SVG:

Establecer miter limits en aplicaciones de diseño

¿Sabían que las uniones en inglete y los límites están disponibles en muchas de las aplicaciones de diseño que usamos en nuestro trabajo diario? Acá es donde encontrarlos en Illustrator, Figma e Inkscape.

Establecer stroke-miterlimit en Adobe Illustrator

Illustrator tiene una forma de modificar el valor de inglete al configurar el trazo de una ruta. Puede encontrarlo en la configuración de "stroke" en un path. Observen cómo, fiel a la especificación, solo podemos establecer un valor para el "Límite" cuando la "Esquina" del path se establece en "miter join".

Un detalle es que Illustrator tiene un límite de inglete predeterminado de "10" en lugar del predeterminado "4". He notado esto cada vez que exporto el archivo SVG o copio y pego el código SVG. Eso podría ser confuso cuando abrimos el código porque ** incluso si no cambia el valor del límite de inglete, Illustrator agrega stroke-miterlimit="10" donde podría esperar 4 o quizás no stroke-miterlimit en absoluto.**

Y eso es cierto incluso si elegimos un valor diferente de stroke-linejoin que no sea "Miter Join". Acá está el código que obtuve al exportar un SVG con stroke-linejoin="round".

<svg viewBox="0 0 16 10"><path stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M0 1h15.8S4.8 5.5 2 9.5" fill="none" stroke="#000"/></svg>

El stroke-miterlimit no debería estar allí, ya que solo funciona con stroke-linejoin="miter". acá hay un par de soluciones para eso:

• Establezcan el valor "Límite" en 4, ya que es el valor predeterminado en SVG y es el único valor que no aparece en el código.
• Usen las opciones "Exportar como" o "Exportar para pantalla" en lugar de "Guardar como" o copiar y pegar los vectores directamente.

Si desean que se solucione, únanse a mí y [voten a favor de la solicitud para que suceda](https://illustrator.uservoice.com/forums/333657-illustrator-desktop-feature-requests/suggestions/33947290-allow -usuarios-para-cambiar-la-configuración-predeterminada-de-inglete-li).

Establecer stroke-miterlimit en Figma

Las uniones en inglete y los límites son ligeramente diferentes en Figma. Cuando hacemos clic en el nodo de un ángulo en una forma, debajo de los tres puntos de la sección stroke, podemos encontrar un lugar para establecer la unión de una esquina. La opción "Miter angle" aparece por defecto, pero solo cuando la unión está configurada en miter:

Esta parte funciona de manera similar a Illustrator, excepto que Figma nos permite establecer el ángulo de inglete en unidades de grado en lugar de valores decimales. Hay algunos otros matices específicos para señalar:

• El ángulo es de 7,17° por defecto y no hay forma de establecer un valor más bajo. Al exportar el SVG, ese valor se convierte en stroke-miterlimit='16' en el código, que es diferente tanto de la especificación SVG como del valor predeterminado de Illustrator.
• El valor máximo es 180°, y al dibujar con esta opción, la unión cambia automáticamente a bevel.
• Al exportar con bebel join, stroke-miterlimit está en el código, pero mantiene el valor que se estableció cuando el miter angle estuvo activo por última vez (Illustrator hace lo mismo).
• Al exportar el SVG con unión redonda, el path se expande y ya no tenemos un trazo, sino un path con un color de relleno.

No pude encontrar una manera de evitar el código adicional que termina en el SVG exportado cuando stroke-miterlimit no es necesario.

Establecer stroke-miterlimit en Inkscape

Inkscape funciona exactamente de la manera en que esperaría que una aplicación de diseño administrara las uniones y los límites de inglete. Al seleccionar una unión a inglete, el valor predeterminado es 4, exactamente lo que está en la especificación. Mejor aún, stroke-miterlimit se excluye del código SVG exportado cuando es el valor predeterminado.

Aún así, si exportamos cualquier ruta con bevel o round después de que se modificó el límite, el stroke-miterlimit volverá al código, a menos que mantengamos las 4 unidades del valor predeterminado en el cuadro Limit. Mismo truco que Illustrator.

Estos ejemplos funcionarán bien si elegimos la opción Guardar como → SVG optimizado. Inkscape es gratuito y de código abierto y, al final del día, tiene el código más ordenado en lo que respecta a stroke-miterlimit y muchas opciones para optimizar el código para exportar.

Pero si están más familiarizado con Illustrator (como yo), hay una solución a tener en cuenta. Figma, debido a las unidades de grado y la expansión de los trazos, se siente más distante de las especificaciones y el comportamiento esperado.

Para cerrar

Eso es lo que aprendí sobre el atributo stroke-miterlimit de SVG. Es otra de esas cosas fáciles de pasar por alto que podríamos cortar a ciegas, particularmente al [optimizar un archivo SVG] (https://css-tricks.com/tools-for-optimizing-svg/). Entonces, ahora, cuando se encuentre configurando stroke-miterlimit, sabrán lo que hace, cómo funciona junto con stroke-linejoin y por qué diablos puede obtener una unión biselada al establecer un valor de límite de inglete.

Este artículo se publicó por primera vez en CSS-Tricks. Gracias a las ediciones de Geoff Graham ♥

Las animaciones son la mejor manera de darle vida a nuestros sitios web: nos ayudan a contar historias y comunicar lo que está pasando en ese momento. Llaman naturalmente nuestra atención, por lo que es importante aprender cómo y cuándo aplicarlos. Si usamos las animaciones de la forma correcta, podemos mejorar la usabilidad de nuestro sitio web, si abusamos de ellas podemos arruinar la experiencia del usuario.

En este artículo voy a mostrar un ejemplo de animaciones interactivas, las que aparecen justo después de que los usuarios realizan una acción y pueden ayudarlos a notar los resultados.

Un buen caso para usar interacciones SVG son las validaciones de formularios. Podemos hacerle saber al usuario lo que está sucediendo en el momento en que interactúa con las entradas.

En este ejemplo, necesitamos que se llenen ambos campos. Tan pronto como el usuario escriba cualquier letra, el ícono de verificación verde confirmará que la entrada es válida. Esta es una pequeña interacción que podemos lograr agregando el atributo HTML5 "required" a nuestro text "input" o "textarea" de esta manera:

<input type=”text” name=”name” id=”name” aria-required=”true” autocorrect=”off” required>

En CSS usamos el selector + pseudo-clase: input:valid o textarea:valid con un SVG en el fondo que se mostrará solo cuando el elemento sea válido:

input#name:valid, 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;
  border: 3px solid $lightgreen;
  transition: background ease 0.2s;
}

Al agregar un SVG en línea en CSS, es importante usar el namespace xmlns=”http://www.w3.org/2000/svg" o la imagen no se mostrará.

La transición del fondo hará que el SVG se mueva desde su posición inicial al 98% a la derecha, como se define en el background en CSS.

En JavaScript podemos verificar esas validaciones y agregar una clase al formulario (y los SVG) cuando ambos campos estén completos, y otra clase si al menos un campo está vacío. Cada clase se vinculará a una animación CSS: una hará que el formulario tiemble y el sobre se caiga del botón Enviar; la otra hará volar el sobre directamente al buzón y se levantará la bandera roja.

document.getElementById(‘sendBtn’).addEventListener(‘click’, function (e) { 
 if (submitName[‘0’].validity.valid && submitText[‘0’].validity.valid) {
 e.preventDefault();
  message.classList.remove(‘not-active’);
  message.classList.add(‘active’);
  mailbox.classList.add(‘active’);
 }
 else {
  message.classList.add(‘not-active’);
  formshake.classList.add(‘active’);
 }
});