diff --git a/7-animation/2-css-animations/article.md b/7-animation/2-css-animations/article.md
index ee272b3c..3187ac9b 100644
--- a/7-animation/2-css-animations/article.md
+++ b/7-animation/2-css-animations/article.md
@@ -86,7 +86,7 @@ In `transition-duration` we can specify how long the animation should take. The
 
 In `transition-delay` we can specify the delay *before* the animation. For instance, if `transition-delay` is `1s` and `transition-duration` is `2s`, then the animation starts 1 second after the property change and the total duration will be 2 seconds.
 
-Negative values are also possible. Then the animation is shown immediately, but the starting point of the animation will be after given value (time). For example, if `transition-delay` is `-1s` and `transition-duration` is `2s`, then animation starts from the halfway point and total duration will be 1 second. 
+Negative values are also possible. Then the animation is shown immediately, but the starting point of the animation will be after given value (time). For example, if `transition-delay` is `-1s` and `transition-duration` is `2s`, then animation starts from the halfway point and total duration will be 1 second.
 
 Here the animation shifts numbers from `0` to `9` using CSS `translate` property:
 
@@ -421,7 +421,7 @@ In more technical details, when there's a style change, the browser goes through
 
 During a CSS animation, this process repeats every frame. However, CSS properties that never affect geometry or position, such as `color`, may skip the Layout step. If a `color` changes, the browser  doesn't calculate any new geometry, it goes to Paint -> Composite. And there are few properties that directly go to Composite. You can find a longer list of CSS properties and which stages they trigger at <https://csstriggers.com>.
 
-The calculations may take time, especially on pages with many elements and a complex layout. And the delays are actually visible on most devices, leading to "jittery", less fluid animations. 
+The calculations may take time, especially on pages with many elements and a complex layout. And the delays are actually visible on most devices, leading to "jittery", less fluid animations.
 
 Animations of properties that skip the Layout step are faster. It's even better if Paint is skipped too.
 
@@ -431,13 +431,13 @@ The `transform` property is a great choice, because:
 
 ...So browsers apply `transform` "on top" of existing Layout and Paint calculations, in the Composite stage.
 
-In other words, the browser calculates the Layout (sizes, positions), paints it with colors, backgrounds, etc at the Paint stage, and then applies `transform` to element boxes that need it. 
+In other words, the browser calculates the Layout (sizes, positions), paints it with colors, backgrounds, etc at the Paint stage, and then applies `transform` to element boxes that need it.
 
 Changes (animations) of the `transform` property never cause Layout and Paint steps. More than that, the browser  leverages the graphics accelerator (a special chip on the CPU or graphics card) for CSS transforms, thus making them very effecient.
 
 Luckily, the `transform` property is very powerful. By using `transform` on an element, you could rotate and flip it, stretch and shrink it, move it around, and [much more](https://developer.mozilla.org/docs/Web/CSS/transform#syntax). So instead of `left/margin-left` properties we can use `transform: translateX(…)`, use `transform: scale` for increasing element size, etc.
 
-The `opacity` property also never causes Layout (also skips Paint in Gecko). We can use it for show / hide or fade-in / fade-out effects. 
+The `opacity` property also never causes Layout (also skips Paint in Mozilla Gecko). We can use it for show/hide or fade-in/fade-out effects.
 
 Paring `transform` with `opacity` can usually solve most of our needs, providing fluid, good-looking animations.