[BUG] Progress Circle load animation is wrong direction

[RasmusKjeldgaard]

• [x] I have written a good issue

Describe the bug

When the progress circle is visible on page load, the animation goes from 100% progress backwards towards the value set by consumers, instead of building up from 0 towards the set value.

This does not happen when the progress circle is below the fold, and the animation is triggered by the intersection observer once the progress circle is scrolled into view.

Describe how to reproduce the bug

1. Go to https://cookbook.kirby.design/#/home/showcase/progress-circle
2. See that the progress circles immediately visible loads counter-clockwise from full to value
3. Scroll down to see progress circles previously hidden outside the viewport animating correctly, clockwise from 0 to value

Which Kirby version was used?

9.4.1

What was the expected behavior?

Progress circle should animate clockwise from 0 to the set value on page load and when scrolled into view.

Are there any additional context?

Here are the offset and centerCircumference values when it loads the wrong way around

---

Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Verification

To make sure the bug is not intended behaviour; it should be verified by a member of team Kirby before moving on to implementation.

• [ ] Make sure the NOT verified label has been removed by a member of team Kirby; do not proceed until this is done.

Implementation

The contributor who wants to implement this issue should:

• [ ] Make sure you have read: "Before you get coding".
• [ ] Signal to others you are working on the issue by assigning yourself.
• [ ] Create a branch from the develop branch following our branch naming convention.
• [ ] Create a test that reproduces the bug following guidelines in: "The good: Test".
• [ ] Write code to fix the bug

Review

Once the issue has been implemented and is ready for review:

• [ ] Do a self-review.
• [ ] Create a pull-request.

[RasmusKjeldgaard]

Bug verification

The progress circle seems to be implemented with the approach outline in this guide. I've tried to sum it up in the following:

The progress-part of the progress circle is implemented with a <circle> element and a combination of the stroke-dasharray and the stroke-dashoffset attributes. The dasharray is set to a single value equal to the totalt circumference of the circle, which means that the stroke will be a dashed line with equal length strokes and gaps, where each is the length of the circles circumference.

With only dasharray set, the initial state of the progress circle is then fully progressed, as the progress dash is the full length of the circle. The clever "hack" is now that we can use dash-offset to push back the starting point of the first dash. As evident from the following screenshot, we initialize the offset as being equal to the circumference, meaning that the progress should be pushed all the way back to zero as a starting point.

For some reason that I am too simple-minded to understand Because Angulars attribute bindings are evaluated at a later point in time this offset is not what is initially rendered on screen. On the first render, even though our offset matches the circumference, the stroke is fully visible:

At a later point the attribute is correctly bound based on the progress circles value, creating a new offset calculation causing the browser to animate between the two offset states (fully visible progress circle --> offset calculated for value of 50) causing the backwards motion.