Fix typos in docs (#5649)

docs/FAQ.md

@@ -1,4 +1,4 @@
-# FAQ (Frequenty Asked Questions)
+# FAQ (Frequently Asked Questions)
 
 You may link to this document using short form:
   https://www.dearimgui.org/faq
@@ -56,7 +56,7 @@ or view this file with any Markdown viewer.
 - The [Glossary](https://github.com/ocornut/imgui/wiki/Glossary) page may be useful.
 - The [Issues](https://github.com/ocornut/imgui/issues) and [Discussions](https://github.com/ocornut/imgui/discussions) sections can be searched for past questions and issues.
 - Your programming IDE is your friend, find the type or function declaration to find comments associated with it.
-- The `ImGui::ShowMetricsWindow()` function exposes lots of internal information and tools. Although it is primary designed as a debugging tool, having access to that information tends to help understands concepts.
+- The `ImGui::ShowMetricsWindow()` function exposes lots of internal information and tools. Although it is primarily designed as a debugging tool, having access to that information tends to help understands concepts.
 
 ##### [Return to Index](#index)
 
@@ -123,7 +123,7 @@ void MyLowLevelMouseButtonHandler(int button, bool down)
 ```
 
 
-**Note:** The `io.WantCaptureMouse` is more correct that any manual attempt to "check if the mouse is hovering a window" (don't do that!). It handle mouse dragging correctly (both dragging that started over your application or over a Dear ImGui window) and handle e.g. popup and modal windows blocking inputs.
+**Note:** The `io.WantCaptureMouse` is more correct that any manual attempt to "check if the mouse is hovering a window" (don't do that!). It handles mouse dragging correctly (both dragging that started over your application or over a Dear ImGui window) and handle e.g. popup and modal windows blocking inputs.
 
 **Note:** Those flags are updated by `ImGui::NewFrame()`. However it is generally more correct and easier that you poll flags from the previous frame, then submit your inputs, then call `NewFrame()`. If you attempt to do the opposite (which is generally harder) you are likely going to submit your inputs after `NewFrame()`, and therefore too late.
 
@@ -240,7 +240,7 @@ Button("OK");      // ERROR: ID collision with the first button! Interacting wit
 Button("");        // ERROR: ID collision with Begin("MyWindow")!
 End();
 ```
-Fear not! this is easy to solve and there are many ways to solve it!
+Fear not! This is easy to solve and there are many ways to solve it!
 
 - Solving ID conflict in a simple/local context:
 When passing a label you can optionally specify extra ID information within string itself.
@@ -259,7 +259,7 @@ End();
 ```cpp
 Checkbox("##On", &b);  // Label = "",       ID = hash of (..., "##On")   // No visible label, just a checkbox!
 ```
-- Occasionally/rarely you might want change a label while preserving a constant ID. This allows
+- Occasionally/rarely you might want to change a label while preserving a constant ID. This allows
 you to animate labels. For example you may want to include varying information in a window title bar,
 but windows are uniquely identified by their ID. Use "###" to pass a label that isn't part of ID:
 ```cpp
@@ -310,7 +310,7 @@ PushID("node");
   PopID();
 PopID();
 ```
-- Tree nodes implicitly creates a scope for you by calling `PushID()`:
+- Tree nodes implicitly create a scope for you by calling `PushID()`:
 ```cpp
 Button("Click");       // Label = "Click",  ID = hash of (..., "Click")
 if (TreeNode("node"))  // <-- this function call will do a PushID() for you (unless instructed not to, with a special flag)
@@ -346,7 +346,7 @@ Long explanation:
 - Each rendering function decides on a data type to represent "textures". The concept of what is a "texture" is entirely tied to your underlying engine/graphics API.
  We carry the information to identify a "texture" in the ImTextureID type.
 ImTextureID is nothing more that a void*, aka 4/8 bytes worth of data: just enough to store 1 pointer or 1 integer of your choice.
-Dear ImGui doesn't know or understand what you are storing in ImTextureID, it merely pass ImTextureID values until they reach your rendering function.
+Dear ImGui doesn't know or understand what you are storing in ImTextureID, it merely passes ImTextureID values until they reach your rendering function.
 - In the [examples/](https://github.com/ocornut/imgui/tree/master/examples) backends, for each graphics API we decided on a type that is likely to be a good representation for specifying an image from the end-user perspective. This is what the _examples_ rendering functions are using:
 ```cpp
 OpenGL:
@@ -499,7 +499,7 @@ Applications in the `examples/` folder are not DPI aware partly because they are
 The reason DPI is not auto-magically solved in stock examples is that we don't yet have a satisfying solution for the "multi-dpi"  problem (using the `docking` branch: when multiple viewport windows are over multiple monitors using different DPI scale). The current way to handle this on the application side is:
 - Create and maintain one font atlas per active DPI scale (e.g. by iterating `platform_io.Monitors[]` before `NewFrame()`).
 - Hook `platform_io.OnChangedViewport()` to detect when a `Begin()` call makes a Dear ImGui window change monitor (and therefore DPI).
-- In the hook: swap atlas, swap style with correctly sized one, remap the current font from one atlas to the other (may need to maintain a remapping table of your fonts at variying DPI scale).
+- In the hook: swap atlas, swap style with correctly sized one, remap the current font from one atlas to the other (may need to maintain a remapping table of your fonts at varying DPI scale).
 
 This approach is relatively easy and functional but come with two issues:
 - It's not possibly to reliably size or position a window ahead of `Begin()` without knowing on which monitor it'll land.