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

learn/components/defining-a-component.md

@@ -9,8 +9,9 @@ _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
-behaviour. You can tell the browser to use a different class by _defining_ the tag name in the _Custom Element Registry_.
-With your own class _defined_, any time the browser sees the defined tag, it will set it up using the _associated class_.
+behaviour. You can tell the browser to use a different class by _defining_ the tag name in the _Custom Element
+Registry_. With your own class _defined_, any time the browser sees the defined tag, it will set it up using the
+_associated 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
@@ -48,10 +49,11 @@ message like `autonomous custom elements must extend HTMLElement`.
 ## Customized Built-in Elements
 
 _Customized Built-in_ elements are extensions to the browsers existing _built-in_ elements. For example if you wanted to
-make a button extends the normal behaviours, you can customise it with a _Customized Built-in_. Instead of making up your
-own tag name, you'll use the same tag as the _built-in_ you're targeting. Your class will also have to extend from the
-existing _built-in's_ class. For example extending the `<button>` element means your class will need to `extends HTMLButtonElement`. When
-you call `customElements.define` you will need to tell it that you're extending a _built-in_ tag:
+make a button extends the normal behaviours, you can customise it with a _Customized Built-in_. Instead of making up
+your own tag name, you'll use the same tag as the _built-in_ you're targeting. Your class will also have to extend from
+the existing _built-in's_ class. For example extending the `<button>` element means your class will need to
+`extends HTMLButtonElement`. When you call `customElements.define` you will need to tell it that you're extending a
+_built-in_ tag:
 
 ```js
 customElements.define(
@@ -181,11 +183,9 @@ Another thing you could do is move the definition into a static method on the cl
 
 ```js
 class MyElement extends HTMLElement {
-
   static define() {
     customElements.define("my-element", MyElement)
   }
-
 }
 ```
 

learn/components/naming-your-components.md

@@ -39,7 +39,8 @@ Try typing a tag name below to see if it's a valid custom element tag:
 
 ### Reserved tag names
 
-Some names are **disallowed** because they have existed in the _HTML spec_ before _custom elements_ were added. These are:
+Some names are **disallowed** because they have existed in the _HTML spec_ before _custom elements_ were added. These
+are:
 
 - `annotation-xml`
 - `color-profile`
@@ -58,19 +59,20 @@ DOMException: CustomElementRegistry.define: 'annotation-xml' is not a valid cust
 
 ## Tips on naming element
 
-While none of the following is prescriptive, here are some tips and tricks on how to pick a good name for your _custom elements_:
+While none of the following is prescriptive, here are some tips and tricks on how to pick a good name for your _custom
+elements_:
 
 ### Avoid splitting compound words
 
-It can be tricky to think of two words for every element, so it might be tempting to add a dash inside a compound word. 
+It can be tricky to think of two words for every element, so it might be tempting to add a dash inside a compound word.
 For example splitting "tooltip" into `tool-tip` or "overlay" into `over-lay`. Adding dashes to compound words like this
-can look a little confusing so it might be beneficial to spend the effort and think of another word to add to these,
-for example `tooltip-popover` or `overlay-dialog`.
+can look a little confusing so it might be beneficial to spend the effort and think of another word to add to these, for
+example `tooltip-popover` or `overlay-dialog`.
 
 ### Using names from existing elements
 
 If your _Autonomous Custom Element_ borrows concepts from other _built-ins_ then you could make up a similar name. For
-example `fancy-button` for an element like `<button>`, `color-input` for an element like `<input>`, or  `radial-meter`
+example `fancy-button` for an element like `<button>`, `color-input` for an element like `<input>`, or `radial-meter`
 for an element like `<meter>`. You might want to avoid doing this for all except _Customised Built-ins_. If your element
 doesn't share anything in common with an existing _built-in_, then it's best to avoid having a similar name, as it might
 cause confusion.
@@ -83,22 +85,23 @@ unclear what they do until you familiarise yourself with them. Good components h
 clear!
 
 Conversely using difficult to spell words can cause errors and typos more often. It's best to avoid difficult to spell
-element names like `<abbreviated-text>` or `<widget-accessory>`. Words longer than 10 characters tend to be difficult
-to spell, so try to avoid those. Words with double letters (abbreviated, occasion, accommodate) can be tricky too. Words
+element names like `<abbreviated-text>` or `<widget-accessory>`. Words longer than 10 characters tend to be difficult to
+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" consanants
-(knack, assign, doubt) are difficult, especially people 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 `<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>`.
+(knack, assign, doubt) are difficult, especially people 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
+`<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>`.
 
 Tag names don't have to use a single dash! Names like `<auto-complete-input>` or `<ajax-form-provider>` are valid, and
 can sometimes be clearer! However just like long methods or class names they can be overly verbose which makes them
 tiresome to read and type. It's good to avoid generic "filler" words that don't add to the meaning, like `wrapper`,
 `provider`, `effect`, or `element`.
 
 Some design systems will prefix their _Web Components_ with a branding. For example all of [Adobe Spectrum's][spectrum]
-_Web Components_ are prefixed `<sp-`, [Shoelace Components][shoelace] are prefixed `<sl-`. This can be useful, as you can
-easily tell apart a component from a design system to a generic off-the-shelf component. On the other hand, this makes
-every component name longer.
+_Web Components_ are prefixed `<sp-`, [Shoelace Components][shoelace] are prefixed `<sl-`. This can be useful, as you
+can easily tell apart a component from a design system to a generic off-the-shelf component. On the other hand, this
+makes every component name longer.
 
 [spectrum]: https://opensource.adobe.com/spectrum-web-components/
 [shoelace]: https://shoelace.style/

learn/index.md

@@ -10,8 +10,8 @@ _Web Components_ are a native way for web developers to build user interfaces. T
 you don't have to download any framework to get started! _Web Components_ fit right into your existing HTML today. If
 you've got a server that can render HTML, then you can render Web Components!
 
-_Web Components_ allow you to extend the vocabulary of your HTML. You can define new behaviors that go beyond the built in
-tags. New features such as `<slide-out-menu>` or `<stop-watch>` are at your finger tips. JavaScript can drive these
+_Web Components_ allow you to extend the vocabulary of your HTML. You can define new behaviors that go beyond the built
+in tags. New features such as `<slide-out-menu>` or `<stop-watch>` are at your finger tips. JavaScript can drive these
 definitions, allowing advanced behaviors and interactions.
 
 {% tip %}

learn/your-first-web-component.md

@@ -11,8 +11,8 @@ you've written JavaScript for the web before, you might already be familiar with
 APIs.
 
 _Web Components_ go further to add a powerful set of additional APIs. One of those is [_Custom
-Elements_][defining-a-component] which allows you to define your own HTML Elements. _Web Components_ can also make use of
-[_ShadowDOM_][shadowdom] which is a powerful API that allows you to manage how an element is rendered.
+Elements_][defining-a-component] which allows you to define your own HTML Elements. _Web Components_ can also make use
+of [_ShadowDOM_][shadowdom] which is a powerful API that allows you to manage how an element is rendered.
 
 [classes]: /learn/javascript/classes
 [events]: /learn/javascript/events