With over 20 years of experience, we transform your digital presence. We specialize in website and E-Shop development, SEO and Digital Marketing, ERP software and smart automation that take your business to the next level.
Address:
154 Egnatia Street, Thessaloniki 546 36
Phone:
+30 231 231 4095
E-mail:
[email protected]
Ready for the next step?;
Timing charts make the timing dependencies of an SVG animation visible before the SMIL markup is written. See how they organize syncbase, overlaps, resets, and reduced-motion fallback.
A timing chart for SVG animations is the simplest way to visualize the timing relationships before writing SMIL markup. Each line corresponds to an action and indicates when it begins, when it ends, which other action it overlaps with, and what reset is required for the sequence to repeat smoothly.
The method does not reduce the number of <animate> tags. However, it reduces mental complexity: designers, developers, and product owners all view the same blueprint, compare versions before the production code is changed, and design the behavior from the outset for prefers-reduced-motion. For websites and online stores, this means more controllable loaders, indicators, onboarding animations, and micro-interactions.
A timing chart is a set of timeline bars. Each bar represents a specific animation action and marks its start and end. The lines can follow one another, run parallel, overlap, or be separated by an intentional gap.
It doesn't have to be visually complex or perfectly scaled. It needs to maintain the correct relative order and label each line with a clear name and duration. When the chart shows fadeInLeft, fadeInMiddle and fadeOutGroup, the same vocabulary must appear in the SVG IDs.
This mapping transforms a vague comment such as «make it smoother’ into a controlled decision: which action will start earlier, how much overlap is needed, and where the pause should remain. In the Web design focused on UX and conversions, this precision helps the motion serve the user's action rather than functioning as a standalone effect.
An SVG can be animated using CSS, JavaScript, or SMIL, which stands for Synchronized Multimedia Integration Language. SMIL is declarative: elements such as <animate>, <animateTransform> and <set> They specify what changes, for how long, and in relation to which event or animation.
Its special value comes into play when the asset needs to remain self-contained and be loaded as an image. In an SVG image context, such as when used <img>, built-in JavaScript is disabled for security reasons. SMIL animations can run without JavaScript, but the team should test the actual behavior in browsers, CMSs, email previews, or other environments where the file will be used.
The choice isn't a matter of fashion. It depends on where the asset is loaded, which SVG properties need to be updated, whether interaction is required, how the fallback will be handled, and who will maintain it. A project that starts with website design inspiration This technical decision is necessary before a visual concept can be transferred as-is to production.
Selection rule: Don't approve SMIL just because the demo works inline. Check the final SVG URL, the actual embedding element, the target browsers, caching, the reduced-motion fallback, and the absence of critical information that depends exclusively on the animation.
The basic concept behind SMIL is simple: an animation element targets one element and one property at a time. If a circle needs to change fill and opacity, separate declarations are required. If the pattern is repeated over three cycles, the timing relationships multiply along with the markup.
In CSS or JavaScript, many properties can be grouped into keyframes, functions, or timelines. In SMIL, the mapping is more fragmented. The problem isn’t just that the file gets larger; it’s that the next developer has to mentally reconstruct relationships between tags that may be located in different places.
That's why descriptive IDs are part of the architecture and not just a nice-to-have. Combine action and purpose, such as fadeInLeft ή moveClipPathRight, and avoid names such as anim1. The same logic applies when the Interface technology influences modern UX: The intent must remain clear even when the implementation changes.
Syncbase allows the begin or at the end an animation to refer to the .begin or at the .end another animation by its ID. The official specification also allows for an optional positive or negative offset.
The Relationship begin="colorChange.end - 300 ms" indicates that the opacity change begins 300 milliseconds before the colorChange. The meaning is evident in the markup: you don't need to add up the absolute times to understand the overlap.
Negative offsets require caution. If the calculated start time falls before the beginning of the document timeline or before a future event, the user agent does not play the event. The animation may start as if part of its duration had already elapsed, and it may not be displayed in its entirety. This behavior should be a test case, not an assumption.
A primary animation also reduces maintenance. Secondary movements can start from primary.begin ή primary.end. If the team moves the entire group forward in time, the primary changes and the relevant dependencies remain consistent.
Architecture of Time
Use an absolute start only for the entry point and syncbase for the internal relationships within the sequence. Thus, a change in duration or a pause does not require recalculation at every subsequent tag, and the timing chart remains consistent with the code.
A spinner with three dots is enough to illustrate the problem. Each dot fades in and fades out, so six are needed <animate> elements. The naming convention links the action to the position: left, middle, and right.
In the first version, the fade-ins play sequentially from left to right. When the rightmost fade-in ends, the three fade-outs begin simultaneously. The fadeOutLeft It can serve as the primary for the group, and the other two can start from fadeOutLeft.begin. After the group ends, the sequence restarts.
The timing chart makes it easy to compare variations: sequential fade-outs, an earlier overlap, starting from the semicolon, or a pause before the restart. The artwork remains the same, but the perceived pace changes. If the spinner appears during checkout or a search, the variation should be evaluated under actual latency conditions rather than in an isolated loop.
There is no documented conversion rate derived from the timing chart. Its value lies in the fact that it makes the sequence measurable and comparable. The team can record when it occurs, how long it lasts, and whether it helps or distracts the user.
When clip paths, strokes, and geometric transformations are added, the sequence acquires a state. A rectangle inside <clipPath> It can move over a circle and reveal the stroke in a different way. The radius of the circle must take into account half stroke-width so that the final footprint does not increase unnecessarily.
An animation such as moveClipPathLeft the group can start. The subsequent clip-path animations are linked to the syncbase, while the fade-ins begin when the corresponding movement is complete. If the fade-in changes fill-opacity and the general fade-out opacity, the chart should show that fill and stroke are not affected in the same way.
The fill="freeze" retains a property in its final value after the active interval. In a repeating sequence, this creates a need for an explicit reset. The <set> elements can be returned fill-opacity, opacity and clip-path coordinates in their initial state. Since they have no duration, they are represented as instantaneous events in the timing chart.
The crucial test is the loop's boundary: there should be no frames with an incorrect state, a sudden flash, or an invisible element. These issues often go unnoticed when the animation is checked only once and become apparent after repeated use.
The prefers-reduced-motion This is a media feature that indicates the user prefers less unnecessary movement. It does not automatically disable SVG animations. The team must decide what to remove, what to slow down, what to replace, and what information should remain visible without motion.
For a non-interactive asset, a <picture> can provide a different source based on media conditions. A CSS background-image It can also be converted to a static version. Inline CSS within the SVG itself or JavaScript with matchMedia() and the SMIL DOM interface are other options, but they must be evaluated based on the image context and compatibility.
Opacity animations are not automatically safe for everyone, nor do they serve as a universal fallback. Scaling, panning, rapid movements, and continuous loops can act as vestibular triggers. The right decision starts with the meaning: if the motion conveys a state, the static version needs an equivalent, understandable state.
The Cognitive Integration in User Research It helps the team evaluate this behavior based on actual user needs, not just technical compliance. Reduced motion, focus, contrast, and a clear context should all be part of the same review.
Accessibility gate: The reduced-motion version must be available before the animation asset is approved. Test it with the preference enabled in the operating system, rather than relying solely on the DevTools override.
A chart is useful only when it is linked to an actual process. The following sequence combines design intent, SMIL dependencies, fallback, and QA into a single deliverable.
Seven Steps to Controllable SVG Motion
Note which SVG element changes, which property moves, and what the initial and final states are. Don't start with durations.
Use names such as fadeInMiddle ή moveClipPathRight so that the chart, markup, and test cases all speak the same language.
Draw a line for each action and note the corresponding durations. Add the instantaneous resets as separate events.
Maintain perfect timing at the entry point and coordinate the internal movements with .begin, .end and documented offsets.
Decide whether to use a static image, a more subtle motion, or a different approach. Maintain the same meaning and status without motion.
Check inline SVG, <img>, <picture> or background, depending on the production, along with cache, dimensions, responsive behavior, and target browsers.
Note any resets, flashes, overlaps, and pauses in the loops. Save the timing chart along with the asset and the acceptance criteria for this release.
The sequence is, of course, part of an organized project Website development, from the brief to launch. An animation is not a file that is delivered at the end; it is a component with a design intent, technical dependencies, and acceptance criteria.
The chart and SMIL are not in competition. The former describes the intent over time, while the latter carries it out. The confusion arises when the team expects the markup to serve simultaneously as an implementation, documentation, and review tool.
The blueprint and code must remain in sync
Timing Chart
It displays "begin," "end," "overlap," "pause," "parallel groups," and "resets." It allows design, product, and development teams to compare versions before the asset is modified.
SMIL markup
It specifies elements, properties, durations, syncbase references, and final values. It requires browser tests, a reduced-motion strategy, and verification of the loop state.
When the code changes, the chart is updated as well. Otherwise, the blueprint becomes outdated and creates a false sense of certainty. For small teams, a versioned diagram in the repository or in the design file is sufficient, as long as it is linked to the specific SVG revision.
A loader is not neutral when it appears during checkout, search, payment, or the loading of personalized content. Duration, frequency, and restarts affect how the user perceives the wait. The timing chart does not prove an improvement in conversion; however, it allows for the design and measurement of a specific variation.
In a E-shop: From Strategy to Launch, the animation must be linked to the actual state. If the payment is complete, the loader must stop. If there is an error, the status must be made clear without relying on animation. If the process is delayed, the team should troubleshoot the backend and frontend rather than mask the problem with a more complex loop.
Performance remains part of the experience. An optimized SVG may be lightweight, but an overly complex DOM, complex filters, or continuous motion come at a cost. The Website Speed Guide explains why visual quality must be evaluated alongside rendering, responsive assets, and actual devices.
For brand systems, the timing chart can capture motion tokens such as direction, overlap, and pause without requiring the same artwork at every touchpoint. Thus, consistency relates to behavior rather than the mindless replication of an effect.
Before production, the team must verify that each row in the chart corresponds to a real ID, that no syncbase points to a missing element, and that negative offsets behave as intended and have been tested. In the loop, all frozen values and clip-path coordinates must be reset to their correct initial state.
The test is conducted in a real-world context, on both desktop and mobile devices, with reduced motion enabled and disabled. The following are observed: focus, status, responsive dimensions, horizontal overflow, layout shift, and rendering cost. The website maintenance It must also include these assets when browser engines, templates, or performance budgets change.
The final deliverable is not just the SVG. It includes the timing chart, the reduced-motion version, the integration points, the target browsers, and the acceptance tests. With this package, the motion remains understandable even after the original creator leaves, and it can be further developed without the need for arbitrary recalculations of timings.
Website Development
TWO DOTS combines UX, accessibility, responsive implementation, and performance so that SVG animations, loaders, and microinteractions have a clear purpose, a testable fallback, and maintainable code.
Frequently Asked Questions (FAQs)
It is a temporal blueprint in which each line indicates the beginning and end of a specific action. This is how sequences, parallel actions, overlaps, gaps, and resets appear before they are transferred to the SMIL markup.
SMIL, which stands for Synchronized Multimedia Integration Language, is SVG's declarative animation mechanism. Elements such as `animate`, `animateTransform`, and `set` change properties or values without requiring JavaScript.
Yes, SMIL animations can work in SVG files loaded as images in modern browsers, while embedded JavaScript is disabled in an image context. The exact behavior should always be tested in browsers and at the points where it is integrated into the project.
Syncbase defines the start of an animation in relation to the start or end of another animation, with an optional positive or negative offset. In this way, the markup describes temporal dependencies rather than repeating fragile absolute times.
A primary animation serves as a common reference point in time for a group of actions. When the group is moved forward in time, the secondary animations can remain tied to the same begin or end, minimizing changes.
No. The media feature conveys the user's preference, but the implementation must respect it by using a static or milder version, a different image source, appropriate CSS rules, or controlled JavaScript logic where permitted.
It retains the "animated" property in the final value after the active interval. In a loop, you may need to use `set elements` or redesign the sequence so that `fill`, `opacity`, `clip-path` coordinates, and other state values are restored correctly before the restart.
No. The timing chart is a design and communication tool, so it can be used to organize CSS animations, the Web Animations API, or JavaScript timelines. The "syncbase" syntax is specific to SMIL, but the logic behind the timing blueprint is not.
