recommended changes in README.md

This sentence is quite interesting in that it seems to stack exception upon exception.

> But wouldn't that be awesome to keep using the existing variant syntax?

Normally "it" refers back in time to some previous noun, and so the instinct to use the word "that" instead is often correct.  And if the order of the ideas were rearranged, "that" would make perfect sense:

> But what if we could keep using the existing variant syntax? Wouldn't _that_ be awesome?

"That" works there (in the rearranged sentence) because it refers back to the previously mentioned _idea_ of keeping the existing syntax.  So in many cases "that" refers to an _idea_, while "it" refers to a _specific noun_.  It might be nice if this were a simple rule that we could expect English to always follow.

But in this case when we say "wouldn't it be awesome if...", the "it" is instead referring _ahead_ to an idea that is about to be mentioned.

I hope this is helpful, and feel free to ask me about any of the changes I'm recommending.

If you think I misunderstood anything in the original text and might be making the wrong recommendation, let me know and I'll make whatever amendments are necessary.

Author: brandonzylstra

README.md

@@ -33,17 +33,17 @@
 
 ---
 
-Seamless integration of [imgproxy](https://imgproxy.net)–a fast and secure standalone server for resizing and converting remote images–to your Rails app with zero changes to your codebase required.
+Seamless integration of [imgproxy](https://imgproxy.net)—a fast and secure standalone server for resizing and converting remote images—to your Rails app with zero changes to your codebase required.
 
-While [imgproxy.rb](https://github.com/imgproxy/imgproxy.rb) being a framework-agnostic Ruby gem includes proper support for Rails' most popular image attachment options: [Active Storage](https://edgeguides.rubyonrails.org/active_storage_overview.html) and [Shrine](https://github.com/shrinerb/shrine), it requires user to use imgproxy specific API:
+While [imgproxy.rb](https://github.com/imgproxy/imgproxy.rb) (being a framework-agnostic Ruby gem) includes proper support for Rails' most popular image attachment options, [Active Storage](https://edgeguides.rubyonrails.org/active_storage_overview.html) and [Shrine](https://github.com/shrinerb/shrine), it requires the user to use an imgproxy-specific API:
 
 ```ruby
 user.avatar.imgproxy_url(width: 250, height: 250)
 ```
 
-But wouldn't that be awesome to keep using existing variant syntax? For example, to use vips/ImageMagick in dev and imgproxy in production?
+But wouldn't it be awesome to keep using the existing variant syntax? For example, to use vips/ImageMagick in dev and imgproxy in production?
 
-And `imgproxy-rails` gem provides just that, thanks to [ActiveStorage::Variant API](https://api.rubyonrails.org/v7.1.3/classes/ActiveStorage/Variant.html) and [Proxy mode](https://guides.rubyonrails.org/active_storage_overview.html#proxy-mode).
+The `imgproxy-rails` gem provides just that, thanks to [ActiveStorage::Variant API](https://api.rubyonrails.org/v7.1.3/classes/ActiveStorage/Variant.html) and [Proxy mode](https://guides.rubyonrails.org/active_storage_overview.html#proxy-mode).
 
 ## Installation