Fix typos in the documentation. (#731)

Co-authored-by: mundry <mundry@users.noreply.github.com>

docs/src/pages/blog/island-architecture.md

@@ -38,7 +38,7 @@ To develop a better understanding of what Jason meant with his proposal, let's q
 
 Think of a simple webpage. On which are many different types of components that are shown on this page, components that are shared across the site, others contain fixed content, some are a bit more elaborate that may perhaps use different state's or need to fetch multiple data streams from external sources.
 
-Such an site would would have very few actual 'moving' pieces, or _dynamic_ elements. For the most part the content tends to be fixed, and static.
+Such a site would have very few actual 'moving' pieces, or _dynamic_ elements. For the most part the content tends to be fixed, and static.
 
 In order to allow for dynamism and interactivity we are often left making overly complex solutions to deliver the slightest form of action on the application.
 
@@ -60,7 +60,7 @@ Helping to abstract away much of the complexity needed in implementing architect
 
 The likes of; [ASP.NET](https://dotnet.microsoft.com/learn/aspnet/what-is-aspnet-core) and [Blazor](https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor) for [.NET](https://dotnet.microsoft.com/), [Ruby On Rails](https://rubyonrails.org/), [Laravel](https://laravel.com/) & [Symphony](https://symfony.com/) for [PHP](https://www.php.net/), are examples of the MVC patterns seen in other server-side programming languages.
 
-For along time, JavaScript was solely restricted to the Browser, then [Node.js](https://nodejs.org/en/) appeared. Node.js is a standalone JavaScript runtime built on the Chrome V8 engine.
+For a long time, JavaScript was solely restricted to the Browser, then [Node.js](https://nodejs.org/en/) appeared. Node.js is a standalone JavaScript runtime built on the Chrome V8 engine.
 
 This was a seismic shift that occurred in Web Development, by allowing JavaScript to escape the browser and operate on the server, developers could use JS on both; Front & Back-ends, when developing their applications.
 
@@ -92,7 +92,7 @@ Some of these were developed by industry leaders, such as Google with their [Ang
 
 ## The Status Quo
 
-Its slightly hubris to suggest that the web development ecosystem had at all settled for any period of time, well at least long enough for a Status Quo to coalesce.
+It's slightly hubris to suggest that the web development ecosystem had at all settled for any period of time, well at least long enough for a Status Quo to coalesce.
 
 However, given the vibrancy and versatility of the ecosystem, a status quo had indeed began to take hold.
 
@@ -126,7 +126,7 @@ By doing so we can take full advantage of unbundled developer environments, allo
 
 Using ESM in the Browser, tools can build once and cache forever. Tree-shaking and code optimisations can occur, more frequently and with greater efficacy. Reducing massive bundle sizes down to a few hundred Kilobytes.
 
-Tools like [Snowpack](https://www.snowpack.dev/) and [Vite](https://vitejs.dev/) introduce an whole new experience that developers were previously denied in their development process and that is speed.
+Tools like [Snowpack](https://www.snowpack.dev/) and [Vite](https://vitejs.dev/) introduce a whole new experience that developers were previously denied in their development process and that is speed.
 
 With cut-edge DX features like [HMR](https://npm.io/package/esm-hmr) has quickly became the industry de facto, and build times reduced by a factor of 100x.
 
@@ -138,7 +138,7 @@ Into this new age ESM world, we have had a dearth of innovation from the establi
 
 Basic questions of : Websites or WebApp's were still unresolved. Where to render the site, on the server or on the client, perhaps a bit of both? What determines the need for dynamic content and what specifies content to be static?
 
-Witnessing frameworks slowly go full circle and return to Server-Side-Rendering (_SSR_) their applications was in part only allowed to be considered in an ESM world, however it was bit of an admission of culpability of sorts.
+Witnessing frameworks slowly go full circle and return to Server-Side-Rendering (_SSR_) their applications was in part only allowed to be considered in an ESM world, however it was a bit of an admission of culpability of sorts.
 
 By inadvertently admitting that the current model is flawed, opened up the space for a new form of discourse to enter, and help redefine the ecosystem moving forward.
 
@@ -166,13 +166,13 @@ This 'micro' architecture is similar to both 'micro-frontends' and 'micro-servic
 
 With Island-Architecture, he proposes a form of progressive enhancement for the dynamic components by using a technique known as _Partial Hydration_.
 
-Lets look at this following analogy:
+Let's look at this following analogy:
 
 On our Static page, we have an image carousel. Such carousel needs to have some form of interactivity to load the next image after a certain amount of time has elapsed, along with navigation and pagination buttons on the carousel.
 
 To do this we would need to implement some behaviour on our carousel.
 
-In the traditional sense, we might be using a React Component to help create the aforementioned experience. In order to do this we would have too include the React-runtime plugin as a top-level `<script>` within our HTML document.
+In the traditional sense, we might be using a React Component to help create the aforementioned experience. In order to do this we would have to include the React-runtime plugin as a top-level `<script>` within our HTML document.
 
 This means for our page, we need to wait for React to be fetched and downloaded, then parsed and executed, have it wait for the page to display the carousel before we receive the behaviour and functionality we expect from our small dynamic component.
 
@@ -184,7 +184,7 @@ This would then load the functionality for the carousel in-place, transforming i
 
 By now the idea of Island-architecture must be settling in, and one must be thinking, this is just [Progressive Hydration](<https://en.wikipedia.org/wiki/Hydration_(web_development)#Progressive_rehydration>), and you wouldn't be overly off mark.
 
-Progressive Hydration that is used in frameworks like: Angluar, React, Preact, Vue. Are individual components, which are loaded and then initialised over a period of time.
+Progressive Hydration that is used in frameworks like: Angular, React, Preact, Vue. Are individual components, which are loaded and then initialised over a period of time.
 
 Using scheduling processes, and accounting for things like viewport visibility, content value, probability of interaction etc. They can abstract away the intricacies and delivery this form of hydration for developers.
 
@@ -204,7 +204,7 @@ A key benefit is seen with the site performance. Since isolation is inherent, if
 
 As we explore further into the Island, we can see immediate trade differences between framework produced SSR solutions and those that could be provided by using Island Architecture.
 
-Quickly wandering back to the Status Quo for a brief interlude. We use SSR with SPA's to help tackle the downside of SPA's and its SEO. Appealing to the search engines in this manner has another negative affect on the UX.
+Quickly wandering back to the Status Quo for a brief interlude. We use SSR with SPA's to help tackle the downside of SPA's and its SEO. Appealing to the search engines in this manner has another negative effect on the UX.
 
 > "...visitors are left waiting for the actual functionality of a page to arrive while staring at a frustratingly fake version of that page." - Jason Miller
 
@@ -218,7 +218,7 @@ We find with our "Islands" model, that with Server rendering is a fundamental pa
 
 The responded HTML, would still contain all the rendered content that the user requested. With some islands yet to engage their client-sided interactivity. The document sent should contain all the content that the User would need.
 
-An example of this would be a product page for a e-commerce business. A product page, using the Islands model would contain that products description, price etc, Having the dynamic components becoming interactive on demand.
+An example of this would be a product page for a e-commerce business. A product page, using the Islands model would contain that product's description, price etc, Having the dynamic components becoming interactive on demand.
 
 We also discover that with the Islands model we have better accessibility and discoverability of our elements and the contents within.
 

docs/src/pages/core-concepts/astro-components.md

@@ -28,7 +28,7 @@ For example, this three-line file is a valid Astro component:
 
 An Astro component represents some snippet of HTML in your project. This can be a reusable component, or an entire page of HTML including `<html>`, `<head>` and `<body>` elements. See our guide on [Astro Pages](/core-concepts/astro-pages) to learn how to build your first full HTML page with Astro.
 
-**Every Astro component must include an HTML template.** While you can enhance your component in several ways (see below) at the end of the day its the HTML template that dictates what your rendered Astro component will look like.
+**Every Astro component must include an HTML template.** While you can enhance your component in several ways (see below), at the end of the day it's the HTML template that dictates what your rendered Astro component will look like.
 
 ### CSS Styles
 
@@ -69,7 +69,7 @@ Sass (an alternative to CSS) is also available via `<style lang="scss">`.
 
 ### Frontmatter Script
 
-To build a dynamic components, we introduce the idea of a frontmatter component script. [Frontmatter](https://jekyllrb.com/docs/front-matter/) is a common pattern in Markdown, where some config/metadata is contained inside a code fence (`---`) at the top of the file. Astro does something similar, but with full support for JavaScript & TypeScript in your components.
+To build dynamic components, we introduce the idea of a frontmatter component script. [Frontmatter](https://jekyllrb.com/docs/front-matter/) is a common pattern in Markdown, where some config/metadata is contained inside a code fence (`---`) at the top of the file. Astro does something similar, but with full support for JavaScript & TypeScript in your components.
 
 Remember that Astro is a server-side templating language, so your component script will run during the build but only the HTML is rendered to the browser. To send JavaScript to the browser, you can use a `<script>` tag in your HTML template or [convert your component to use a frontend framework](/core-concepts/component-hydration) like React, Svelte, Vue, etc.
 

docs/src/pages/core-concepts/component-hydration.md

@@ -28,7 +28,7 @@ There are plenty of cases where you need an interactive UI component to run in t
 - A mobile sidebar open/close button
 - A "Buy Now" button
 
-In Astro, it's up to you as the developer to explicitly "opt-in" any components on the page that need to run in the browser. Astro can then use this info to know exactly what JavaScript is needed, and only hydrate exactly what's needed on the page. This technique is is known as partial hydration.
+In Astro, it's up to you as the developer to explicitly "opt-in" any components on the page that need to run in the browser. Astro can then use this info to know exactly what JavaScript is needed, and only hydrate exactly what's needed on the page. This technique is known as partial hydration.
 
 **Partial hydration** -- the act of only hydrating the individual components that require JavaScript and leaving the rest of your site as static HTML -- may sound relatively straightforward. It should! Websites have been built this way for decades. It was only recently that Single-Page Applications (SPAs) introduced the idea that your entire website is written in JavaScript and compiled/rendered by every user in the browser.
 

docs/src/pages/core-concepts/layouts.md

@@ -41,7 +41,7 @@ const {title} = Astro.props;
 
 📚 The `<slot />` element lets Astro components define where any children elements (passed to the layout) should go. Learn more about how `<slot/>` works in our [Astro Component guide.](/core-concepts/astro-components)
 
-Once you have your first layout, You can use it like you would any other component on your page. Remember that your layout contains your page `<html>`, `<head>`, and `<body>`. You only need to provide the custom page content.
+Once you have your first layout, you can use it like you would any other component on your page. Remember that your layout contains your page `<html>`, `<head>`, and `<body>`. You only need to provide the custom page content.
 
 ```astro
 ---

docs/src/pages/core-concepts/project-structure.md

@@ -34,7 +34,7 @@ The src folder is where most of your project source code lives. This includes:
 - [Styling (CSS, Sass)](/guides/styling)
 - [Markdown](/guides/markdown-content)
 
-Astro has complete control over how these files get processed, optimized, and bundled in your final site build. Some files (like Astro components) never make it to the browser directly and are instead rendered to HTML. Other files (like CSS) are sent to the browser but may be bundled with other CSS files depending on how your site uses.
+Astro has complete control over how these files get processed, optimized, and bundled in your final site build. Some files (like Astro components) never make it to the browser directly and are instead rendered to HTML. Other files (like CSS) are sent to the browser but may be bundled with other CSS files depending on how your site uses them.
 
 ### `src/components`
 

docs/src/pages/getting-started.md

@@ -30,7 +30,7 @@ Like any unfamiliar technology, Astro does have a learning curve. With practice
 
 When you begin to learn Astro, you'll see many files using the `.astro` file extension. This is the **Astro component syntax**: a special HTML-like file format that Astro uses for templating. It was designed to feel familiar to anyone with HTML or JSX experience.
 
-Our guide on [Astro components](/core-concepts/astro-components) walks you through the new syntax, and is best way to learn.
+Our guide on [Astro components](/core-concepts/astro-components) walks you through the new syntax, and is the best way to learn.
 
 ### API Reference
 

docs/src/pages/guides/data-fetching.md

@@ -55,7 +55,7 @@ const Movies: FunctionalComponent = () => {
 export default Movies;
 ```
 
-If you load a component using `node-fetch` [interactively](/core-concepts/component-hydration), with `client:load`, `client:visible`, etc., you'll need to either not use `node-fetch` or switch to an [isomorphic](https://en.wikipedia.org/wiki/Isomorphic_JavaScript) library that will run both at build time and on the client, as the [`node-fetch` README.md](https://github.com/node-fetch/node-fetch#motivation) reccomends:
+If you load a component using `node-fetch` [interactively](/core-concepts/component-hydration), with `client:load`, `client:visible`, etc., you'll need to either not use `node-fetch` or switch to an [isomorphic](https://en.wikipedia.org/wiki/Isomorphic_JavaScript) library that will run both at build time and on the client, as the [`node-fetch` README.md](https://github.com/node-fetch/node-fetch#motivation) recommends:
 
 > Instead of implementing XMLHttpRequest in Node.js to run browser-specific [Fetch polyfill](https://github.com/github/fetch), why not go from native http to fetch API directly? Hence, node-fetch, minimal code for a window.fetch compatible API on Node.js runtime.
 >

docs/src/pages/guides/deploy.md

@@ -7,7 +7,7 @@ The following guides are based on some shared assumptions:
 
 - You are using the default build output location (`dist/`). This location [can be changed using the `dist` configuration option](/reference/configuration-reference).
 - You are using npm. You can use equivalent commands to run the scripts if you are using Yarn or other package managers.
-- Astro is installed as a local dev dependency in your project, and you have setup the following npm scripts:
+- Astro is installed as a local dev dependency in your project, and you have set up the following npm scripts:
 
 ```json
 {
@@ -133,7 +133,7 @@ With the `netlify.toml` file, add it at the top level of your project with the f
 
 Then, set up a new project on [Netlify](https://netlify.com) from your chosen Git provider.
 
-If you don't want to use the `netlify.toml`, when you go to [Netlify](https://netlify.com) and set up up a new project from Git, input the following settings:
+If you don't want to use the `netlify.toml`, when you go to [Netlify](https://netlify.com) and set up a new project from Git, input the following settings:
 
 - **Build Command:** `astro build` or `npm run build`
 - **Publish directory:** `dist`

docs/src/pages/guides/markdown-content.md

@@ -13,7 +13,7 @@ Also, Astro supports third-party plugins for Markdown. You can provide your plug
 
 > **Note:** Enabling custom `remarkPlugins` or `rehypePlugins` removes Astro's built-in support for [GitHub-flavored Markdown](https://github.github.com/gfm/) support, [Footnotes](https://github.com/remarkjs/remark-footnotes) syntax, [Smartypants](https://github.com/silvenon/remark-smartypants). You must explicitly add these plugins to your `astro.config.mjs` file, if desired.
 
-## Add a markdown plugin in Astro
+## Add a Markdown plugin in Astro
 
 If you want to add a plugin, you need to install the npm package dependency in your project and then update the `markdownOptions.remarkPlugins` or `markdownOptions.rehypePlugins` depends on what plugin you want to have:
 
@@ -26,7 +26,7 @@ export default {
       // If you need to provide options for the plugin, you can use an array and put the options as the second item.
       // 'remark-slug',
       // ['remark-autolink-headings', { behavior: 'prepend'}],
-    ]
+    ],
     rehypePlugins: [
       // Add a Rehype plugin that you want to enable for your project.
       // If you need to provide options for the plugin, you can use an array and put the options as the second item.
@@ -111,7 +111,7 @@ const { content } = Astro.props;
 
 ### Astro's Markdown Component
 
-Astro has a dedicated component used to let you render your markdown as HTML components. This is a special component that is only exposed to `.astro` files. To use the `<Markdown>` component, within yout frontmatter block use the following import statement:
+Astro has a dedicated component used to let you render your markdown as HTML components. This is a special component that is only exposed to `.astro` files. To use the `<Markdown>` component, within your frontmatter block use the following import statement:
 
 ```jsx
 ---
@@ -180,7 +180,7 @@ const expressions = 'Lorem ipsum';
 
 ### Remote Markdown
 
-If you have Markdown in a remote source, you may pass it directly to the Markdown component through the `content` attribute. For example, the example below fetches the README from Snowpack's Github repository and renders it as HTML.
+If you have Markdown in a remote source, you may pass it directly to the Markdown component through the `content` attribute. For example, the example below fetches the README from Snowpack's GitHub repository and renders it as HTML.
 
 ```jsx
 ---

docs/src/pages/guides/publish-to-npm.md

@@ -57,7 +57,7 @@ import { Bold, Capitalize } from '@example/my-components';
 
 ## Advanced
 
-We recommend a single `index.js` package entrypoint because this is what most users are familar with. However, in some rare scenarios you may want to have your users import each `.astro` component directly, in the same manner that you import `.astro` files in your own project.
+We recommend a single `index.js` package entrypoint because this is what most users are familiar with. However, in some rare scenarios you may want to have your users import each `.astro` component directly, in the same manner that you import `.astro` files in your own project.
 
 ```astro
 ---

docs/src/pages/guides/styling.md

@@ -150,7 +150,7 @@ All CSS is minified and bundled automatically for you in running `astro build`.
 
 We’ll be expanding our styling optimization story over time, and would love your feedback! If `astro build` generates unexpected styles, or if you can think of improvements, [please open an issue][issues].
 
-_Note: be mindful when some page styles get extracted to the ”common” bundle, and some page styles stay on-page. For most people this may not pose an issue, but when part of your styles are bundled they technically may load in a different order and your cascade may be different. While problem isn’t unique to Astro and is present in almost any CSS bundling process, it can be unexpected if you’re not anticipating it. Be sure to inspect your final production build, and please [report any issues][issues] you may come across._
+_Note: be mindful when some page styles get extracted to the ”common” bundle, and some page styles stay on-page. For most people this may not pose an issue, but when part of your styles are bundled they technically may load in a different order and your cascade may be different. While this problem isn’t unique to Astro and is present in almost any CSS bundling process, it can be unexpected if you’re not anticipating it. Be sure to inspect your final production build, and please [report any issues][issues] you may come across._
 
 ## Advanced Styling Architecture
 
@@ -288,7 +288,7 @@ So to recap, think of scoped styles as the backbone of your styles that get you
 
 ### More suggestions
 
-”But wait!” you may ask, having read the previous section. ”That doesn’t take care of [my usecase]!” If you‘re looking for more pointers on some common styling problems, you may be interested in the following suggestions. These all are cohesive, and fit with the **Hybrid Scoped + Utility** philosphy:
+”But wait!” you may ask, having read the previous section. ”That doesn’t take care of [my usecase]!” If you‘re looking for more pointers on some common styling problems, you may be interested in the following suggestions. These all are cohesive, and fit with the **Hybrid Scoped + Utility** philosophy:
 
 1. Split your app into Layout Components and Base Components
 1. Avoid Flexbox and Grid libraries (write your own!)
@@ -457,13 +457,13 @@ In other words, don’t do this:
 
 If you remember the [CSS box model][box-model], `margin` extends beyond the boundaries of the box. This means that when you place `margin` on the outermost element, now that will push other components next to it. Even though the styles are scoped, it’s _technically_ affecting elements around it, so it [breaks the concept of style containment][layout-isolated].
 
-When you have components that rearrage, or appear different when they’re next to other components, that’s a hard battle to win. **Components should look and act the same no matter where they are placed.** That’s what makes them components!
+When you have components that rearrange, or appear different when they’re next to other components, that’s a hard battle to win. **Components should look and act the same no matter where they are placed.** That’s what makes them components!
 
 💁 **Why this works well in Astro**: margins pushing other components around creeps into your styling architecture in sneaky ways, and can result in the creation of some wonky or brittle layout components. Avoiding it altogether will keep your layout components simpler, and you’ll spend less time styling in general.
 
 #### Suggestion #4: Avoid global media queries
 
-The final point is a natural boundary of **Scoped Styles**. That extends to breakpoints, too! You know that one, weird breakpoint where your `<Card />` component wraps awkardly at a certain size? You should handle that within `<Card />`, and not anywhere else.
+The final point is a natural boundary of **Scoped Styles**. That extends to breakpoints, too! You know that one, weird breakpoint where your `<Card />` component wraps awkwardly at a certain size? You should handle that within `<Card />`, and not anywhere else.
 
 Even if you end up with some random value like `@media (min-width: 732px) {`, that’ll probably work better than trying to create a global [magic number][magic-number] somewhere that only applies to one context (an arbitrary value may be “magic” to the rest of an app, but it does still have meaning within the context of a component that needs that specific value).
 

docs/src/pages/reference/api-reference.md

@@ -173,7 +173,7 @@ Astro will generate an RSS 2.0 feed at `/feed/[collection].xml` (for example, `/
 
 All ESM modules include a `import.meta` property. Astro adds `import[dot]meta[dot]env` through [Snowpack](https://www.snowpack.dev/).
 
-**`import[dot]meta[dot]env[dot]SSR`** can be used to know when rendering on the server. Some times you might want different logic, for example a component that should only be rendered in the client:
+**`import[dot]meta[dot]env[dot]SSR`** can be used to know when rendering on the server. Sometimes you might want different logic, for example a component that should only be rendered in the client:
 
 ```jsx
 import { h } from 'preact';

docs/src/pages/reference/renderer-reference.md

@@ -9,7 +9,7 @@ Internally, each framework is supported via a framework **renderer.** A renderer
 
 ## What is a renderer?
 
-A renderer is an NPM package that has two responsiblities:
+A renderer is an NPM package that has two responsibilities:
 
 1. _render a component to a static string of HTML_ at build time
 2. _rehydrate that HTML to create an interactive component_ on the client.