add retext-passive

Author: keithamus

.remarkrc.mjs

@@ -22,6 +22,7 @@ export default {
     [retext, Parser],
     "retext-indefinite-article",
     "retext-diacritics",
+    ["retext-passive", { ignore: ["read", "set"] }],
     ["retext-readability", { threshold: 6 / 7 }],
     [
       "retext-spell",

CONTRIBUTING.md

@@ -10,7 +10,7 @@ Contributions are always welcome! Before contributing, please read 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
-  issue first! This way we can discuss an action plan and figure out a high level overview of what should be written.
+  issue first! This way we can discuss an action plan and figure out a high level overview of what we should write.
 
 ### Setup
 
@@ -23,8 +23,8 @@ $ npm install
 $ npm start
 ```
 
-Once this is done you can visit <http://localhost:8080/> to see the local copy of the website. As you edit files the
-website will automatically rebuild, and you can see the changes reflected in your browser.
+You can now visit <http://localhost:8080/> to see the local copy of the website. As you edit files the website will
+automatically rebuild, and you can see the changes reflected in your browser.
 
 ### Running checks/tests
 

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

@@ -44,7 +44,7 @@ _The journey_ is a hallmark of every great framework. The plethora of front-end
 From [Lit][lit] to [Vue][vue] to [Svelte][svelte] to [React][react] to [Remix][remix], every one starts out with the
 basics, and eventually leads you to [drawing the rest of the owl][owl]. The story of Web Components lacks this. MDN
 provides you with all the resources to know about the building blocks, but doesn't tell you how to put them together. On
-how to draw the rest of the owl is left to you.
+how to draw the rest of the owl is down to you.
 
 And building good owls - I mean UI - is _hard_. Building a component that's durable to the variety of situations it gets
 placed in. Capable of accepting the wide inputs it needs, accessible for sighted users, users of screen readers,
@@ -61,7 +61,7 @@ rooms. Not all the furnishings are here yet. We're working on it. But we wanted
 feedback and improve. We've shared early versions of the content we have so far with newcomers and seasoned experts
 alike. Everyone has said they've learned something new. We couldn't wait any longer.
 
-The content we have is split into three sections for now:
+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.

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

@@ -116,7 +116,7 @@ into issues with code that isn't expecting to see the newly added logic.
 _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 read out not only by their label but also referred to as "buttons").
+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

learn/components/initializing-your-component.md

@@ -8,8 +8,8 @@ components might keep a memory of things - often called _state_. All of these th
 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 done with _class fields_
-or as logic during the _constructor_.
+any _state_ will want to be instantiated with each new component instance created. This can be accomplished with _class
+fields_ or as logic during the _constructor_.
 
 ### Class Fields
 

learn/components/lifecycle-reference.md

@@ -70,7 +70,7 @@ that means:
 ### What is `connectedCallback` good for?
 
 The `connectedCallback` is called _as soon as_ the element is attached to a `document`, and so the elements
-`.ownerDocument` property will be set (usually that will point to the global `document` object).
+`.ownerDocument` property will be available (usually that will point to the global `document` object).
 
 This _may_ occur _before_ an element has any children appended to it, so you should be careful not expect an element to
 have children during a `connectedCallback` call. This means you might want to avoid using APIs like `querySelector`.

learn/components/naming-your-components.md

@@ -89,7 +89,7 @@ element names like `<abbreviated-text>` or `<widget-accessory>`. Words longer th
 spell, so try to avoid those. Words with double letters (abbreviated, occasion, accommodate) can be tricky too. Words
 using different letters with the same sound (necessary, accessory) often get misspelled. Words with "silent" consonants
 (knack, assign, doubt) are difficult, especially people for whom English is not their first language. In these cases it
-might be better to replace a hard to spell word with a simpler word, e.g. `<abbreviated-text>` could be come
+might be better to replace a hard to spell word with a simpler word, e.g. `<abbreviated-text>` could become
 `<short-text>`, `<approximate-date>` could be `<rounded-date>`. Alternatively you could replace one hard to spell word
 with two easier to spell words that mean the same thing, for example `<establish-account>` could be `<set-up-account>`.
 

learn/components/rendering.md

@@ -176,9 +176,9 @@ class StopWatchElement extends HTMLElement {
 
 If you're using a _declarative ShadowDOM_ then you'll need to use a special API called _Element Internals_. To get to a
 Web Components _Element Internals_, `.attachInternals()` can be called. It can only be called once though - subsequent
-calls will throw an error. Internals should be kept private to a Web Component class as it contains a variety of
-internal APIs for a Web Component. The Element Internals API **also** has a `.shadowRoot` property, but this one can
-also get the _closed ShadowRoot_:
+calls will throw an error. Internals should remain private to a Web Component class as it contains a variety of internal
+APIs for a Web Component. The Element Internals API **also** has a `.shadowRoot` property, but this one can also get the
+_closed ShadowRoot_:
 
 ```html
 <stop-watch>

learn/javascript/classes.md

@@ -36,7 +36,7 @@ console.assert(mypoint instanceof Point)
 
 ### Defining a public API
 
-Classes can be given public properties, and methods to give them features which other code can use. They can also have
+Classes can have public properties, and methods to give them features which other code can use. They can also have
 special well known methods that get automatically called during certain events:
 
 ```js

learn/javascript/events-in-more-detail.md

@@ -17,7 +17,7 @@ The [previous section][events] showed how you can add an _Event listener_ with `
 more than one. In fact, you can use a single function to listen to multiple different event types, if they each have
 different names.
 
-Listeners are given the `Event` object, so the listener function can use that to determine which event type the listener
+Listeners are passed the `Event` object, so the listener function can use that to determine which event type the listener
 was called on, using `.type`:
 
 ```js