npm run format

Author: keithamus

CODE_OF_CONDUCT.md

@@ -2,75 +2,60 @@
 
 ## Our Pledge
 
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, gender identity and expression,
-level of experience, education, socio-economic status, nationality, personal
-appearance, race, religion, or sexual identity and orientation.
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making
+participation in our project and our community a harassment-free experience for everyone, regardless of age, body size,
+disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education,
+socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
 
 ## Our Standards
 
-Examples of behavior that contributes to creating a positive environment
-include:
+Examples of behavior that contributes to creating a positive environment include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Our Responsibilities
 
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take
+appropriate and fair corrective action in response to any instances of unacceptable behavior.
 
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits,
+issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any
+contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
 
 ## Scope
 
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the
+project or its community. Examples of representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed representative at an online or offline
+event. Representation of a project may be further defined and clarified by project maintainers.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at webcomponentsguide@keithcirkel.co.uk. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at
+webcomponentsguide@keithcirkel.co.uk. All complaints will be reviewed and investigated and will result in a response
+that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality
+with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent
+repercussions as determined by other members of the project's leadership.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
 
 [homepage]: https://www.contributor-covenant.org
 
-For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq
+For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq

CONTRIBUTING.md

@@ -1,12 +1,16 @@
 # Contributing
 
-Contributions are always welcome! Before contributing, please read the [code of conduct](https://github.com/WebComponentsGuide/webcomponents.guide/blob/main/CODE_OF_CONDUCT.md).
+Contributions are always welcome! Before contributing, please read the
+[code of conduct](https://github.com/WebComponentsGuide/webcomponents.guide/blob/main/CODE_OF_CONDUCT.md).
 
 ## Where to start
 
 - If you've found typos or mistakes in the documentation, please go right ahead and raise a PR!.
-- 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 issue first! This way we can discuss an action plan and figure out a high level overview of what should be written. 
+- 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
+  issue first! This way we can discuss an action plan and figure out a high level overview of what should be written.
 
 ### Setup
 
@@ -19,8 +23,10 @@ $ 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.
+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.
 
 ### 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 ensure your contributions are correctly formatted
+and spelled. You can also run `npm run format` to automatically format all files.

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

@@ -10,21 +10,21 @@ tag and extending `HTMLElement`. However, each style comes with different trade-
 [defining-a-component]: /learn/components/defining-a-component
 
 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 think
-about:
+canvas to work with. _Customized Built-ins_ **extend** the element you're customizing. Here are some considerations to
+think about:
 
 ### Tag Name
 
-Perhaps the most obvious difference between the two is that _Autonomous Custom Elements_ get to create an entirely new tag
-name, and this means if you're querying for the element in the DOM, you'll need to reference that tag name, e.g.
+Perhaps the most obvious difference between the two is that _Autonomous Custom Elements_ get to create an entirely new
+tag name, and this means if you're querying for the element in the DOM, you'll need to reference that tag name, e.g.
 `.querySelector('fancy-button')` will return the first `<fancy-button>`.
 
-With _Customized Built-in_ elements, the tag name must match the element you're customising. For example if you wanted to
-customise a `<button>` element then your HTML will take the shape of `<button is="fancy-button>`. In order to query this
-element you'd need to use an _attribute selector_, for example `.querySelector('button[is="fancy-button"]')`. This also
-means existing code that queries for `button` elements will also find your _Customized Built-ins_. Calling
-`.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])')`.
+With _Customized Built-in_ elements, the tag name must match the element you're customising. For example if you wanted
+to customise a `<button>` element then your HTML will take the shape of `<button is="fancy-button>`. In order to query
+this element you'd need to use an _attribute selector_, for example `.querySelector('button[is="fancy-button"]')`. This
+also means existing code that queries for `button` elements will also find your _Customized Built-ins_. Calling
+`.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
 considerations...
@@ -34,16 +34,16 @@ considerations...
 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.
 
-As _Customised 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 built-ins_.
-This also includes the default _user agent CSS_.
+As _Customised 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
+built-ins_. This also includes the default _user agent CSS_.
 
-All _built-ins_ have some _user-agent CSS_ supplied already, for example `div` elements have `display: block;`, `<button>`
-elements are styled to look like your operating systems buttons. _Customised Built-ins_ will also get these styles, so
-`<button is="fancy-button">` will look the same as `<button>` until you customise it further.
+All _built-ins_ have some _user-agent CSS_ supplied already, for example `div` elements have `display: block;`,
+`<button>` elements are styled to look like your operating systems buttons. _Customised Built-ins_ will also get these
+styles, so `<button is="fancy-button">` will look the same as `<button>` until you customise 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.
+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.
 
 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
@@ -54,8 +54,8 @@ One other thing to think about with regard to styling is _encapsulated styles_ w
 ### ShadowDOM
 
 _Autonomous Custom Elements_ can make use of the [_ShadowDOM_][shadowdom]. Only a limited set of _built-ins_ can use the
-_ShadowDOM_. If you want to alter any nested elements, it's a great idea to use _ShadowDOM_, and so you probably won't want
-to customise a _built-in_. Here's a list of _built-ins_ that you can customise with _ShadowDOM_:
+_ShadowDOM_. If you want to alter any nested elements, it's a great idea to use _ShadowDOM_, and so you probably won't
+want to customise a _built-in_. Here's a list of _built-ins_ that you can customise with _ShadowDOM_:
 
 - `<article>`
 - `<aside>`
@@ -70,13 +70,13 @@ to customise a _built-in_. Here's a list of _built-ins_ that you can customise w
 - `<section>`
 - `<span>`
 
-_ShadowDOM_ can be really useful for providing encapsulated markup and styles. Styles within _ShadowDOM_ don't
-effect 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_.
+_ShadowDOM_ can be really useful for providing encapsulated markup and styles. Styles within _ShadowDOM_ don't effect
+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_.
 
-_ShadowDOM_ also provides elements with the ability to chose how nested elements render. An ability that many _built-ins_
-already have...
+_ShadowDOM_ also provides elements with the ability to chose how nested elements render. An ability that many
+_built-ins_ already have...
 
 [shadowdom]: /learn/components/shadowdom
 
@@ -85,11 +85,11 @@ already have...
 Many _built-in_ elements will only allow certain tags to nest inside ([you can read more about _Content Categories_ on
 MDN][content-categories]). For example a `<button>` tag only allows _[phrasing content]_ tags like `<b>`, `<strong>`,
 `<span>` and so on. Some elements, for example the `<details>` element will have specific associations with other
-elements. A `<summary>` tag can only exist as the _first child_ to a `<details>` element, and if it doesn't exist, it will
-be created by the `<details>` tag.
+elements. A `<summary>` tag can only exist as the _first child_ to a `<details>` element, and if it doesn't exist, it
+will be created by the `<details>` tag.
 
-_Customized Built-ins_ match the semantics of the _built-in_ they're customising, and that cannot be changed. So for example
-a `<button is="fancy-button">` will only allow nested _[phrasing content][phrasing-content]_ tags just like a
+_Customized Built-ins_ match the semantics of the _built-in_ they're customising, and that cannot be changed. So for
+example a `<button is="fancy-button">` will only allow nested _[phrasing content][phrasing-content]_ tags just like a
 `<button>`.
 
 _Autonomous Custom Elements_ allow any nested tag by default. This can be customised with _ShadowDOM_, but the default
@@ -121,15 +121,15 @@ into issues with code that isn't expecting to see the newly added logic.
 
 ### Accessibility
 
-_Customised 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 webpage, 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").
+_Customised 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 webpage, 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").
 
 _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 customise how assistive technology like _screen readers_ handle your element by
-using the [Accessible Internet Rich Applications (or ARIA)][aria] APIs, such as the `role=` attribute.
+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 customise how assistive technology like _screen readers_ handle your
+element by using the [Accessible Internet Rich 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