fix retext lint errors

Author: keithamus

CONTRIBUTING.md

@@ -9,7 +9,7 @@ Contributions are always welcome! Before contributing, please read the
 - If you're looking for issues to resolve, a good place to start is the
   [help wanted label](https://github.com/WebComponentsGuide/webcomponents.guide/labels/help%20wanted) and/or
   [good first issue label](https://github.com/WebComponentsGuide/webcomponents.guide/labels/good%20first%20issue).
-- If you have to contribute to bigger pieces, like an idea or new section, tutorial, or blog post, then please raise an
+- If you're contributing to larger pieces, like an idea or new section, tutorial, or blog post, then please raise an
   issue first! This way we can discuss an action plan and figure out a high level overview of what we should write.
 
 ### Setup
@@ -28,5 +28,5 @@ automatically rebuild, and you can see the changes reflected in your browser.
 
 ### Running checks/tests
 
-When making contributions, please make sure to run `npm run check`, to ensure your contributions are correctly formatted
-and spelled. You can also run `npm run format` to automatically format all files.
+When making contributions, please make sure to run `npm run check`, to make sure your contributions are correctly
+formatted and spelled. You can also run `npm run format` to automatically format all files.

blog/2023-01-09-introducing-webcomponents-guide.md

@@ -7,9 +7,9 @@ excerpt: >
   Hello, world! Announcing the launch of a new way to learn how to create Web Components.
 ---
 
-The Web is a special place. It's a giant ecosystem that organically grows day by day. Rather than being designed behind
+The Web is an amazing place. It's a giant ecosystem that organically grows day by day. Rather than being designed behind
 closed doors by a single corporation, the web is designed in the open by developers who _use_ the platform. It's one of
-the very few areas in which we see many competing corporations work together to ensure a productive, interoperable set
+the very few areas in which we see many competing corporations work together to create a productive, interoperable set
 of APIs that millions of other companies can leverage. No other platform comes close.
 
 When I first picked up Microsoft Front Page '98 and started trying to build my own site, I was immediately hooked. Over
@@ -21,13 +21,13 @@ HTML 5 and thinking "wouldn't it be great to define our own tags?". Luckily I wa
 decade of innovation on the web saw exactly that. Today Web Components allow engineers to define their own tags with
 unique functionality.
 
-Web Components started out as a collection of specs from Google. The initial release of the "Custom Elements API" in
-2014 (referred to as "Custom Elements V0"). It predated modern JavaScript idioms like ES6 Classes. Google Chrome was the
-only browser to ship the V0 spec, despite many experiments like Mozilla's [x-tag][x-tag] and Google's
-[polymer][polymer]. By 2016 browser vendors agreed on and shipped a new specification (Custom Elements V1). This new
-spec coincided with powerful new technologies such as ShadowDOM and HTML Templates. Luckily today this is a footnote in
-the history of the web platform and Web Components. Web Components a proven set of technologies used by companies the
-world over. There is one sticking point remaining though.
+Web Components started out as a collection of specs from Google. The first release of the "Custom Elements API" in 2014
+(referred to as "Custom Elements V0"). It predated modern JavaScript idioms like ES6 Classes. Google Chrome was the only
+browser to ship the V0 spec, despite many experiments like Mozilla's [x-tag][x-tag] and Google's [polymer][polymer]. By
+2016 browser vendors agreed on and shipped a new specification (Custom Elements V1). This new spec coincided with
+powerful new technologies such as ShadowDOM and HTML Templates. Luckily today this is a footnote in the history of the
+web platform and Web Components. Web Components a proven set of technologies used by companies the world over. One
+sticking point remaining though.
 
 One of the best things about the web is the sheer number of learning materials available. Corporations like Mozilla,
 Google and Microsoft collaborate on excellent resources like [MDN][mdn], or [web.dev][web-dev]. There exists an army of
@@ -38,7 +38,7 @@ As great as these learning resources are, they cast a wide net. When speaking to
 Components, one question I am often asked is "how can I find out more?". "The documentation is all there", I say, "just
 look it up on MDN". While MDN provides a great reference, it doesn't give you _the journey_. It can't give you _the
 journey_, because it's job is to be a reference. [MDN still documents Custom Elements V0 APIs][mdn-ce-v0]. Despite the
-various sign posts telling you not to use this, it remains, because MDN's job is to be a reference.
+various sign posts telling you not to use this, it's still documented, because MDN's job is to be a reference.
 
 _The journey_ is a hallmark of every great framework. The plethora of front-end frameworks today have _the journey_.
 From [Lit][lit] to [Vue][vue] to [Svelte][svelte] to [React][react] to [Remix][remix], every one starts out with the
@@ -65,7 +65,7 @@ The content we have is divided into three sections for now:
 
 - **[Learn][learn]**: This will take you through _the journey_. Learn the basic building blocks and learn how to connect
   them to make useful user experiences.
-- **[Tutorials][tutorials]**: This section will give you more substantial end-to-end guides on how to build one specific
+- **[Tutorials][tutorials]**: This section will give you larger end-to-end guides on how to build one specific
   component, end to end. Each tutorial might not cover all topics. They will cover extended platform features or
   third-party libraries. They might make design decisions that aren't applicable to all web components. But we hope some
   will be exactly the kind of technique you're looking for. We hope this is an area where you can learn how experienced

learn/components/autonomous-vs-customized-elements.md

@@ -5,7 +5,7 @@ order: 2
 
 In the [previous section][defining-a-component] we learned about _Autonomous Custom Elements_ vs _Customized Built-in
 Elements_. The most popular way to make elements is to use the _Autonomous Custom Element_ style, by making up your own
-tag and extending `HTMLElement`. However, each style comes with different trade-offs.
+tag and extending `HTMLElement`. Each style comes with different trade-offs.
 
 Choosing a type of component to build will depend on a lot of factors. _Autonomous Custom Elements_ give you a blank
 canvas to work with. _Customized Built-ins_ **extend** the element you're customizing. Here are some considerations to
@@ -24,13 +24,13 @@ also means existing code that queries for `button` elements will also find your
 `.querySelectorAll('button')` will find all button elements, including ones which are _Customized Built-in elements_.
 The way to find _non-Customized Built-ins_ is to use a selector like: `.querySelectorAll('button:not([is])')`.
 
-This difference in tag name also effects how you'll select for these elements in CSS. There are additional CSS
+This difference in tag name also effects how you'll select for these elements in CSS. It also has some additional CSS
 considerations...
 
 ### CSS & Styling
 
 Given _Autonomous Custom Elements_ have their own tag, they are unlikely to conflict with existing CSS. They can have
-_classes_ added to them, and so can be styled by existing CSS but it is opt-in.
+_classes_ added to them, and so can be styled by existing CSS but it's opt-in.
 
 As _Customized Built-ins_ keep their tags (e.g. `<button is="fancy-button">`) any CSS that has rules like `button {}`
 will apply. This means if you have some existing CSS that applies to _built-ins_, it'll also apply to the _Customized
@@ -41,7 +41,7 @@ All _built-ins_ have some _user-agent CSS_ supplied already, for example `div` e
 styles, so `<button is="fancy-button">` will look the same as `<button>` until you customize it further.
 
 If you want to customize a _built-in_ by applying only new styles and not adding any new logic, it might be best to use
-a CSS class instead. The main benefit of _Customized Built-ins_ is to extend or add new logic.
+a CSS class instead. _Customized Built-ins_ are best used when extending or adding new logic.
 
 If you create an _Autonomous Custom Element_ (e.g. `<fancy-button>`) you'll need to style it from scratch as _Autonomous
 Custom Elements_ have no default CSS. You will probably want to add some CSS to these elements - even if it's just
@@ -68,7 +68,7 @@ want to customize a _built-in_. Here's a list of _built-ins_ that you can custom
 - `<section>`
 - `<span>`
 
-_ShadowDOM_ can be really useful for providing encapsulated markup and styles. Styles within _ShadowDOM_ don't effect
+_ShadowDOM_ can be really useful for providing encapsulated markup and styles. Styles within _ShadowDOM_ don't affect
 the rest of the page, and so it can be a really useful place to add styles to your elements. If this is a high priority,
 you might find using an _Autonomous Custom Element_ to be a better choice than the limited set of built-ins which can
 use _ShadowDOM_.
@@ -105,23 +105,23 @@ These all extend from `HTMLElement` themselves so you'll still get everything `H
 
 Extending from `HTMLButtonElement`, for example, means your class will inherit the button's properties, like `.type`,
 `.disabled`, `.forms`, `.name`, `.value`, and so on. On one hand this would be a lot of code to replicate yourself with
-an _Autonomous Custom Element_, but on the other hand your element adopting all of these might not be desirable.
+an _Autonomous Custom Element_, but your element adopting all these might not be desirable.
 
-When extending from a _Customized Built-in_, overriding the already existing methods and properties can have undesirable
+When extending from a _Customized Built-in_ overriding the existing methods and properties can have undesirable
 consequences. It might be tempting to add new `.type` values to `<button>` for example, but in doing so you might run
 into issues with code that isn't expecting to see the newly added logic.
 
 ### Accessibility
 
 _Customized Built-ins_ have very good accessibility information built right into them. Most have an _implicit role_
-which means that assistive technologies know how to interpret them. For example using a _screen reader_, it is possible
-to navigate through all of the headings in a web page, and the purpose of form controls is explained as each one is
-focused (e.g. buttons are announced not only by their label but also referred to as "buttons").
-
-_Autonomous Custom Elements_, on the other hand, do not have any accessibility information built into them. Assistive
-technologies such as _screen readers_ will read the contents of the element as if it were plain text; treating it the
-same as a `<div>` or `<span>`. It's possible to customize how assistive technology like _screen readers_ handle your
-element by using the [Accessible Rich Internet Applications (or ARIA)][aria] APIs, such as the `role=` attribute.
+which means that assistive technologies know how to interpret them. For example using a _screen reader_, it's possible
+to navigate through all the headings in a web page, and the purpose of form controls is explained as each one is focused
+(e.g. buttons are announced not only by their label but also referred to as "buttons").
+
+_Autonomous Custom Elements_, do not have any accessibility information built into them. Assistive technologies such as
+_screen readers_ will read the contents of the element as if it were plain text; treating it the same as a `<div>` or
+`<span>`. It's possible to customize how assistive technology like _screen readers_ handle your element by using the
+[Accessible Rich Internet Applications (or ARIA)][aria] APIs, such as the `role=` attribute.
 
 Accessibility can be hard to get right. Many assistive tools behave differently, and much like browsers, support is not
 universal and consistent. It's always worth getting comfortable with these tools, and testing your web applications

learn/components/index.md

@@ -4,8 +4,8 @@ order: 1
 ---
 
 Most components you write will need some kind of JavaScript. While it's not **strictly** necessary, more often than not
-you'll want to add JavaScript to provide logic. To do this you'll need to create a JavaScript `class`, and use the
-_Custom Elements Registry_ to attach your class so the browser knows to use it.
+you'll want to add JavaScript to drive logic. To do this you'll need to create a JavaScript `class`, and use the _Custom
+Elements Registry_ to attach your class so the browser knows to use it.
 
 Without the _Custom Element Registry_ the browser won't know what JavaScript to associate to what elements. By default,
 whenever the browser encounters a tag it does not know, it will use the `HTMLUnknownElement` class to give it a default
@@ -14,8 +14,8 @@ With your own class _defined_, any time the browser sees the defined tag, it wil
 class_.
 
 To define a _Custom Element_, you can use the global `customElements` API. You won't need to include any JavaScript
-libraries to use `customElements`, it's a global that already exists, like `console` or `localStorage`. There are two
-types of elements you can define:
+libraries to use `customElements`, it's a global that already exists, like `console` or `localStorage`. You can define
+two types of element:
 
 ## Autonomous Custom Elements
 

learn/components/initializing-your-component.md

@@ -4,8 +4,8 @@ order: 5
 ---
 
 Components can have many things that make them useful, for example styles, templates, or other information. Some
-components might keep a memory of things - often called _state_. All of these things need to be initialized using
-different techniques. You will likely use a combination of these techniques when building a component.
+components might keep a memory of things - often called _state_. All these things need to be initialized using different
+techniques. You will likely use a combination of these techniques when building a component.
 
 It can be very useful to create things during _instantiation_, that is when the component is first created. Most likely
 any _state_ will want to be instantiated with each new component instance created. This can be accomplished with _class
@@ -40,7 +40,7 @@ a _lifecycle callback_...
 ### Adding logic when an element is inserted into the DOM
 
 Perhaps more valuable than knowing when an element is created, is to know when it gets _inserted_ into the DOM. At this
-point an element can look at its _parent elements_ to know where it is in the tree, and can do useful logic like adding
+point an element can look at its _parent elements_ to know where it's in the tree, and can do useful logic like adding
 _event listeners_, and start rendering or animating.
 
 If a _custom element_ has a `connectedCallback()` function, then the browser will automatically call this whenever the

learn/components/lifecycle-reference.md

@@ -119,25 +119,26 @@ class MyElement extends HTMLElement {
 }
 ```
 
-When a document is parsed all of the attributes which are observed will result in a call to
-`attributeChangedCallback()`. This can happen _before_ the element is connected and `connectedCallback` has been called,
-so avoid relying on the element being connected during this time.
+When a document is parsed all the attributes which are observed will result in a call to `attributeChangedCallback()`.
+This can happen _before_ the element is connected and `connectedCallback` has been called, so avoid relying on the
+element being connected during this time.
 
-The `attributeChangedCallback()` will fire whenever `setAttribute`, `removeAttribute`, `toggleAttribute` are called if
-they are changing an observed attribute.
+The `attributeChangedCallback()` will be called whenever `setAttribute`, `removeAttribute`, `toggleAttribute` are called
+if they are changing an observed attribute.
 
 Attributes are also nodes that can be constructed with [`document.createAttribute()`][createattribute], which returns an
 `Attr` object. This `Attr` object can then be applied to the element via `.setAttributeNode()`. This will also result in
 the `attributeChangedCallback()` being called if it's an observed attribute. An `Attr` object also has a `.value`
 property; changing that will _also_ call `attributeChangedCallback()`.
 
 It's worth noting that even if the _new_ value is the same as the _old_ value, calling `setAttribute` or changing the
-`.value` on an `Attr` will result in the `attributeChangedCallback()` being called. In other words, it is possible for
+`.value` on an `Attr` will result in the `attributeChangedCallback()` being called. In other words, it's possible for
 `attributeChangedCallback` to be called when `oldValue === newValue`. In most cases this really won't matter much, and
 in some cases this is very helpful; but sometimes this can bite, especially if you have
 [non-idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_examples) code inside your
 `attributeChangedCallback`. Try to make sure operations inside `attributeChangedCallback` are idempotent, or perhaps
-consider adding a check to ensure `oldValue !== newValue` before performing operations which may be sensitive to this.
+consider adding a check to make sure `oldValue !== newValue` before performing operations which may be sensitive to
+this.
 
 ## `adoptedCallback()`