npm - @askviraj/linter - Versions diffs - 1.1.0 → 1.1.3 - Mend

@askviraj/linter 1.1.0 → 1.1.3

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1621) hide show

package/node_modules/@rviscomi/capo.js/docs/src/content/docs/user/extension.mdx DELETED Viewed

@@ -1,116 +0,0 @@
----
-title: Using the Capo extension
-description: Learn about the Capo extension for Chrome and how to use it with capo.js
-hero:
-  actions:
-    - text: Install the extension
-      link: https://chrome.google.com/webstore/detail/capo-get-your-%EF%B9%A4%F0%9D%9A%91%F0%9D%9A%8E%F0%9D%9A%8A%F0%9D%9A%8D%EF%B9%A5/ohabpnaccigjhkkebjofhpmebofgpbeb
-      icon: rocket
-      variant: primary
----
-import { Steps } from "@astrojs/starlight/components";
-import CapoOptions from "../../../components/CapoOptions.astro";
-import CapoPalette from "../../../components/CapoPalette.astro";
-import InlineCapoIcon from "../../../components/InlineCapoIcon.astro";
-import InlineCapoWeightBars from "../../../components/InlineCapoWeightBars.astro";
-![Capo extension](../../../assets/capo-chrome.png)
-Capo is a Chrome extension that gives you one-click access to the capo.js script. Clicking the extension icon ( <InlineCapoIcon/> ) will open a color bar visualizing the `<head>` ordering, and log messages to the console, including validation warnings and detailed element info.
-## Understanding the color bar
-The first thing you'll see when you click the Capo extension icon ( <InlineCapoIcon/> ) is the color bar. This is how Capo visualizes the _actual_ order of the `<head>` elements as well as the _sorted_ order, with the colors indicating the element weight.
-![Capo extension](../../../assets/capo-extension.png)
-The top row of colors represents the _actual_ order of elements. \
-The bottom row of colors represents the _sorted_ order of elements.
-Ideally, the actual order will be very similar to the sorted order.
-<CapoPalette
-  colors='[
-  "#9e0142",
-  "#d53e4f",
-  "#f46d43",
-  "#fdae61",
-  "#fee08b",
-  "#e6f598",
-  "#abdda4",
-  "#66c2a5",
-  "#3288bd",
-  "#5e4fa2",
-  "#cccccc"
-]'
-/>
-<InlineCapoWeightBars weight="11" length="1" /> _Red_ colors indicate the most important, highest-weighted elements, like [pragma directives](./rules/#-11-pragma-directives) and the [`<title>`](./rules/#-10-title) element.
-<InlineCapoWeightBars weight="5" length="1" /> _Green_ colors indicate the average-importance,
-medium-weighted elements, like [synchronous scripts](./rules/#-6-synchronous-scripts)
-and [styles](./rules/#-5-synchronous-styles).
-<InlineCapoWeightBars weight="3" length="1" /> _Blue_ colors indicate low-importance,
-low-weighted elements, like [deferred scripts](./rules/#-3-deferred-scripts) and
-[speculative resource hints](./rules/#-2-prefetch-and-prerender-hints).
-<InlineCapoWeightBars weight="1" length="1" /> _Gray_ indicates the least important,
-lowest-weighted elements, as a catch-all for everything else that doesn't have an
-explicit weight, like social metadata.
-:::tip
-Hover over any color in the color bar to display a tooltip summarizing the element and its weight.
-:::
-See the [Rules](./rules) guide for a complete list of all the weights and what they measure.
-## Using Capo in the console
-In addition to overlaying the color bar on top of the page, clicking the Capo extension icon ( <InlineCapoIcon/> ) also logs to the DevTools console.
-Color bars for the actual and sorted `<head>` orderings are show in addition to a summary of any validation warnings.
-![Capo extension logging to the console with expanded details](../../../assets/crx-console-expanded.png)
-Color bars are rendered in a collapsed view by default. Clicking the color bar will expand it into the full details for each element in order. The details include:
-- a visualization of the element weight as a colored bar and label
-- a reference to the element
-- additional validation info (where applicable)
-![Capo extension logging to the console with interactive details](../../../assets/crx-console-interactive.png)
-References to elements are interactive. Right-clicking on the element brings up a context menu with a list of actions you can take on the element. Some helpful actions include revealing the element in the Elements panel of DevTools and copying the element markup.
-## Installation
-To install the Capo extension:
-<Steps>
-1. Navigate to the [Capo extension](https://chrome.google.com/webstore/detail/capo-get-your-%3Chead%3E-in-o/ohabpnaccigjhkkebjofhpmebofgpbeb) in the Chrome Web Store
-   ![The Capo extension in the Chrome Web Store](../../../assets/crx-store.png)
-2. Click the **Add to Chrome** button
-3. On any page, click the Capo icon ( <InlineCapoIcon/> ) in the browser toolbar
-   Open the DevTools Console to see additional logs
-   ![Capo extension](../../../assets/capo-extension.png)
-</Steps>
-:::note
-The extension will auto-update whenever new versions are released.
-:::
-## Configuration
-<CapoOptions />
-The extension comes with a few default options for static evaluation, validation, and the color palette.
-See the [Configuration](/capo.js/user/config/#configuring-the-extension) guide for more info on accessing the options page and what each option does.

package/node_modules/@rviscomi/capo.js/docs/src/content/docs/user/performance.mdx DELETED Viewed

@@ -1,6 +0,0 @@
----
-title: Improve performance
-description: Learn about how optimal head ordering can improve performance
----
-Coming soon

package/node_modules/@rviscomi/capo.js/docs/src/content/docs/user/quick-start.mdx DELETED Viewed

@@ -1,26 +0,0 @@
----
-title: Quick start guide to capo.js
-description: What's Capo, how do you use it, and why should you care?
----
-import InlineCapoIcon from '../../../components/InlineCapoIcon.astro';
-`capo.js` is a tool for assessing the quality of the document `<head>`. You can run it in your browser as a Chrome extension.
-An unoptimized `<head>` can lead to poor performance and a poor user experience. `capo.js` can help you identify and fix these issues.
-## _Veloce_: Chrome extension
-:::note[Recommended]
-The [Capo extension](https://chrome.google.com/webstore/detail/capo-get-your-%3Chead%3E-in-o/ohabpnaccigjhkkebjofhpmebofgpbeb) is the easiest way to use `capo.js`.
-:::
-The best way to start using `capo.js` is to install the [Capo extension for Chrome](https://chrome.google.com/webstore/detail/capo-get-your-%3Chead%3E-in-o/ohabpnaccigjhkkebjofhpmebofgpbeb):
-1. Navigate to the [Capo extension](https://chrome.google.com/webstore/detail/capo-get-your-%3Chead%3E-in-o/ohabpnaccigjhkkebjofhpmebofgpbeb) in the Chrome Web Store
-2. Click the **Add to Chrome** button
-3. On any page, click the Capo icon <InlineCapoIcon /> in the browser toolbar
-    - Open the DevTools Console to see additional logs
-Learn more about [using the extension](/capo.js/user/extension/) and interpreting the results.

package/node_modules/@rviscomi/capo.js/docs/src/content/docs/user/rules.mdx DELETED Viewed

@@ -1,202 +0,0 @@
----
-title: The rules of capo.js
-description: Learn how capo.js classifies and scores elements.
-tableOfContents:
-  maxHeadingLevel: 4
----
-import InlineCapoWeightBars from '../../../components/InlineCapoWeightBars.astro';
-import { Tabs, TabItem } from '@astrojs/starlight/components';
-Elements are categorized into 11 groups. Each group has an associated weight to determine the optimal sort order. Elements within the same group are considered equal weight and displayed in the order they're found in the document.
-## <InlineCapoWeightBars weight="11" /> 11. Pragma directives
-Pragma directives are the highest weighted elements in capo.js. They tell the browser how to parse or handle the document, so they must be discovered **as early as possible** to avoid race conditions with other content.
-### `<meta http-equiv>`
-The `http-equiv` meta tag is used to set directives equivalent to HTTP headers.
-Most HTTP headers are [unsupported keywords](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/) for the `http-equiv` attribute, so capo.js only recognizes a few of them:
-- `default-style`
-- `x-dns-prefetch-control`
-- `accept-ch`
-- `delegate-ch`
-- `content-security-policy`
-- `origin-trial`
-- `content-type`
-Some keywords like `refresh` are standardized and widely supported by browsers, but capo.js does not weigh them as highly as other `http-equiv` directives because it's not strictly necessary for them to be placed in the top position.
-#### `default-style`
-:::caution[Obsoletion warning]
-capo.js discourages using this keyword in favor of modern CSS alternatives. However, in cases where the keyword _must_ be used, capo.js recommends placing it in the top position.
-:::
-[`default-style`](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/#default-style) is an obscure-yet-valid keyword that tells the browser which [alternate stylesheet](https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets) to use as the preferred default.
-This declaration should come before any stylesheets that may need to be enabled.
-#### `x-dns-prefetch-control`
-[`x-dns-prefetch-control`](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/#x-dns-prefetch-control) is a non-standard keyword that tells the browser whether to perform DNS prefetching on the page.
-Its only legitimate use is to disable prefetching, so when it's present, capo.js recommends placing it in the top position before any DNS lookups occur.
-#### `accept-ch`
-[`accept-ch`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-CH) is a non-standard keyword that tells the browser which client hints to send back to the server.
-This declaration should be set before any subresource requests are made to the origin, so capo.js recommends placing it in the top position.
-#### `delegate-ch`
-[`delegate-ch`](https://github.com/WICG/client-hints-infrastructure#delegate-ch) is a non-standard keyword that tells the browser which client hints may be delegated to third party origins.
-#### `content-security-policy`
-:::caution[Performance warning]
-Due to a known [performance bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1458493), capo.js discourages using this keyword in favor of its HTTP header alternative. However, in cases where the keyword _must_ be used, capo.js recommends placing it in the top position.
-:::
-[`content-security-policy`](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/#content-security-policy) is a non-standard keyword that provides the browser with a security policy to use on the page.
-To effectively mitigate all possible security risks, this declaration should be set before any resource content, so capo.js recommends placing it in the top position.
-Note that the meta tag version of CSP has functional limitations compared to the HTTP header, such as lack of support for the `report-to` directive.
-#### `origin-trial`
-`origin-trial` is a non-standard keyword that allows developers to test new web platform features on a per-origin basis.
-See [origin trial validation](/capo.js/user/validation/#no-invalid-origin-trials) for more information about how capo.js validates origin trial tokens.
-Because origin trials have the potential to influence how the browser behaves, capo.js recommends placing this declaration in the top position.
-#### `content-type`
-:::caution[Obsoletion warning]
-capo.js discourages using this keyword in favor of the [`charset`](#meta-charset) meta tag or `Content-Type` HTTP header. However, in cases where the keyword _must_ be used, capo.js recommends placing it in the top position.
-:::
-[`content-type`](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/#content-type) is a standard keyword that defines the character encoding for the page.
-See [`<meta charset>`](#meta-charset) for more information about why this declaration should be placed in the top position.
-### `<meta charset>`
-Every page must declare a character encoding of `UTF-8`, using either the `charset` meta tag or the `Content-Type` HTTP response header. When the meta tag is used, it must be discoverable within the first 1024 bytes of the document.
-To avoid encoding issues with user-visible content like the `<title>` element, capo.js recommends placing this declaration in top position.
-### `<meta name=viewport>`
-The viewport meta tag is used to control the layout of the page on mobile devices.
-To avoid a flash of unstyled content or incorrect sizing on mobile devices, capo.js recommends placing the viewport meta tag in the top position.
-### `<base>`
-The `base` element sets the base URL for all relative URLs in the document.
-To avoid any broken links for resources loaded early in the document, capo.js recommends placing the `<base>` element in the top position.
-## <InlineCapoWeightBars weight="10" /> 10. Title
-### `<title>`
-capo.js recommends placing the `<title>` element early in the document to ensure it's discoverable by the browser as early as possible. This is important for users to see the title in the browser tab or title bar, which serves as a signal that the page is loading.
-Additionally, placing the `<title>` after the [`<meta charset>`](#meta-charset) ensures that any special characters in the title are rendered correctly.
-## <InlineCapoWeightBars weight="9" /> 9. Preconnect hints
-### `<link rel=preconnect>`
-Preconnect hints tell the browser to establish a connection to a domain as early as possible, reducing the latency of future requests to that domain.
-To maximize the benefit of preconnecting, capo.js recommends placing these hints early in the document, before any resources from that domain are requested.
-## <InlineCapoWeightBars weight="8" /> 8. Asynchronous scripts
-### `<script async src>`
-Asynchronous scripts are downloaded in parallel to parsing and executed as soon as they are available.
-Because they don't block parsing, capo.js recommends placing them early in the document to start the download as soon as possible.
-## <InlineCapoWeightBars weight="7" /> 7. Import styles
-### `@import`
-:::caution[Performance warning]
-capo.js discourages using `@import` in favor of the [`<link rel=stylesheet>`](#link-relstylesheet) element. See [don't use @import](http://stevesouders.com/blog/2009/04/09/dont-use-import/) for more information.
-:::
-The `@import` rule is used to import style rules from other style sheets.
-Because `@import` rules must precede all other types of rules, capo.js recommends placing them early in the document.
-Capo.js scans the content of `<style>` tags for `@import` rules. If found, the entire `<style>` element is given a higher weight to encourage moving it earlier in the document, or ideally, replacing the `@import` with a `<link rel=stylesheet>` element.
-## <InlineCapoWeightBars weight="6" /> 6. Synchronous scripts
-### `<script src>`
-Synchronous scripts block the parsing of the document until they are downloaded and executed.
-Capo.js recommends placing them before synchronous styles. While the script still blocks parsing, modern browsers' preload scanners will discover and start downloading subsequent stylesheets in parallel. If placed after stylesheets, the script's execution would be blocked until the stylesheets are fully loaded.
-## <InlineCapoWeightBars weight="5" /> 5. Synchronous styles
-### `<link rel=stylesheet>`
-### `<style>`
-Synchronous styles are critical for rendering the page.
-Capo.js recommends placing them early in the document, but after synchronous scripts (if any), to ensure they are discovered and downloaded as soon as possible.
-## <InlineCapoWeightBars weight="4" /> 4. Preload hints
-### `<link rel=preload>`
-### `<link rel=modulepreload>`
-Preload hints tell the browser to download a resource as soon as possible, as it will be needed soon.
-While helpful, they are generally less critical than actual resources (like styles and scripts) that are needed immediately. Capo.js recommends placing them after critical resources, but before deferred scripts and prefetch hints, to ensure these resources start downloading as soon as possible.
-## <InlineCapoWeightBars weight="3" /> 3. Deferred scripts
-### `<script defer src>`
-Deferred scripts are downloaded in parallel to parsing but executed only after the document has been fully parsed.
-Because they don't block parsing and execute later, capo.js recommends placing them after critical resources and preload hints, but before prefetch hints.
-## <InlineCapoWeightBars weight="2" /> 2. Prefetch and prerender hints
-### `<link rel=prefetch>`
-### `<link rel=dns-prefetch>`
-### `<link rel=prerender>`
-Prefetch and prerender hints tell the browser to prepare for resources that might be needed for future navigations.
-Because they are not needed for the current page, capo.js recommends placing them at the bottom of the `<head>` to ensure they don't compete with resources needed for the current page.
-While `dns-prefetch` also deals with connection setup like [`preconnect`](#link-relpreconnect), it is placed here because it is a speculative hint for future navigations or low-priority resources, whereas `preconnect` is for resources needed immediately.
-## <InlineCapoWeightBars weight="1" /> 1. Everything else
-Any other elements found in the `<head>` that don't match the above categories are given the lowest weight.
-This includes elements like Open Graph tags (`<meta property="og:title">`), description tags (`<meta name="description">`), icons (`<link rel="icon">`), and other elements that don't affect the loading or rendering of the page. Capo.js recommends placing these at the very bottom of the `<head>`.

package/node_modules/@rviscomi/capo.js/docs/src/content/docs/user/validation.mdx DELETED Viewed

@@ -1,197 +0,0 @@
----
-title: Validation
-description: Learn about how capo.js validates the head element
----
-import { Image } from "astro:assets";
-import ValidationAreas from "../../../assets/validation-areas.png";
-The `<head>` element sets up all of the necessary metadata for a page to load properly and performantly. capo.js performs a number of validation checks on the `<head>` to ensure it meets modern best practices.
-:::tip
-Validation is enabled by default. To disable it, see the [configuration](/capo.js/user/config/#validation) options.
-:::
-There are a few ways to see when an element is invalid:
-- a warning is logged to the console
-- the element appears striped in the color bar
-- the expanded console entry is annotated with an ❌ icon
-<Image
-  src={ValidationAreas}
-  alt="Console logs showing all three ways elements are flagged as invalid."
-  loading="eager"
-/>
-In the example above, you can see all three ways that an element can be flagged as invalid: top-level warning, striped color bar, and warning styles in its expanded entry.
-![Invalid element in the extension color bar](../../../assets/validation-crx-stripes.png)
-The extension's color bar similarly displays a striped pattern when an element is invalid.
-## No disallowed elements
-According to the [HTML specification](https://html.spec.whatwg.org/multipage/semantics.html#the-head-element), the only [elements allowed in the `<head>`](https://html.spec.whatwg.org/multipage/dom.html#metadata-content-2) are:
-- `<base>`
-- `<link>`
-- `<meta>`
-- `<noscript>`
-- `<script>`
-- `<style>`
-- `<template>`
-- `<title>`
-If capo.js detects any other elements in the `<head>`, it will log a validation warning.
-![Validation warning that "IMG elements are not allowed in the head"](../../../assets/validation-invalid-element.png)
-In the example above, a `<noscript>` element contains an `<img>` child element, so capo.js warns that "IMG elements are not allowed in the `<head>`".
-:::danger
-When a browser encounters an invalid element, it will immediately close the `<head>` element and open the `<body>` element so that the element can be rendered.
-If any valid `<head>` elements come after the invalid element, they will end up in the `<body>`. This is especially problematic for elements that must only appear in the `<head>`, like [SEO metadata](https://twitter.com/JohnMu/status/1670835191852433409).
-:::
-Of all the invalid elements, `<img>` elements are the [most widespread](https://twitter.com/rick_viscomi/status/1671961075598737409), found on over 1.5 million web pages. This antipattern is commonly used by analytics scripts to fall back to image beacons when users have JavaScript disabled. Unless you routinely test your website with JavaScript disabled, you may be unaware of the potential breakages caused by prematurely closing the `<head>` element.
-## Exactly one `<title>` element
-The HTML specification requires that there be [exactly one `<title>` element](https://html.spec.whatwg.org/multipage/semantics.html#the-head-element) in the `<head>`, to specify the document title.
-If capo.js detects zero or more than one `<title>` element, it will log a validation warning:
-![Validation warning that "Expected exactly 1 title element, found 0"](../../../assets/validation-title.png)
-In the example above, the `<title>` element is missing, so capo.js warns that "Expected exactly 1 `<title>` element, found 0".
-## No more than one `<base>` element
-The HTML specification requires that there be [no more than one `<base>` element](https://html.spec.whatwg.org/multipage/semantics.html#the-head-element) in the `<head>`, to specify the document base URL.
-If capo.js detects more than one `<base>` element, it will log a validation warning:
-![Validation warning that "Expected no more than one 1 base element, found 0"](../../../assets/validation-base.png)
-In the example above, there is more than one `<base>` element, so capo.js warns that "Expected at most 1 `<base>` element, found 2".
-## No invalid `<meta http-equiv>` elements
-There are a handful of standardized pragma directives that can be used with the `http-equiv` attribute to change browser behavior. There are even some non-standard directives that browsers still choose support, the most notable being [`origin-trial`](#no-invalid-origin-trials). And there are actually a couple of standardized directives that are non-conforming, meaning that their use is totally discouraged, specifically: `content-language` and `set-cookie`.
-:::caution
-Contrary to popular belief, `http-equiv` meta tags _are not_ equivalent to HTTP headers. Learn more about why [you probably don't need `http-equiv` meta tags](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/).
-:::
-Even when using a standardized, supported, and conforming `http-equiv` directive, its `content` attribute value may still be invalid. For example, the `content-type` directive _must_ declare a character encoding of UTF-8. There are some additional restrictions on this directive, specifically the requirements that it be discovered within the first 1024 bytes and it doesn't coincide with the `<meta charset>` element.
-Many of these cases are harmless no-ops, but capo.js will validate them and provide a helpful warning message with relevant metadata to help you understand whether it's safe to remove it or if anything needs to be changed for it to work properly.
-There are some cases where it's not so harmless:
-- `set-cookie` doesn't actually set any cookies, which could lead to broken behavior.
-- `content-type` character encoding can be declared too late, which may lead to performance issues.
-- `content-security-policy` [breaks](https://issues.chromium.org/issues/40273969) Chrome's preload scanner, which may lead to performance issues.
-- `content-security-policy` directives like `frame-ancestors` and `sandbox` are not supported in meta tags and may have been set mistakenly, breaking assumptions about the page's security.
-- `description` and similar metadata may have been mistakenly assigned to the `http-equiv` meta attribute instead of the intended `name` attribute, which could break assumptions about the page's SEO.
-- `refresh` can reload or redirect the page and is known to cause [accessibility issues](https://www.w3.org/TR/WCAG10-HTML-TECHS/#meta-element).
-### No `<meta>` CSP
-According to the [W3C specification](https://w3c.github.io/webappsec-csp/#policy-delivery), a Content Security Policy (CSP) can be set as either an HTTP header or a `<meta http-equiv>` tag.
-Despite `<meta>` CSP declarations being technically valid, per the spec, browsers handle them differently. In particular, Chrome will disable the [preload scanner](https://web.dev/preload-scanner/) if it discovers a CSP declared after a `<script>` element. The preload scanner can improve performance by 20%, so this behavior has major implications on the user experience.
-:::danger
-Due to a [bug in Chrome](https://bugs.chromium.org/p/chromium/issues/detail?id=1458493), a `<meta>` CSP _anywhere_ in the `<head>` will disable the preload scanner.
-:::
-If capo.js detects a `<meta>` CSP anywhere in the `<head>`, it will log a validation warning:
-![Validation warning that "CSP meta tags disable the preload scanner due to a bug in Chrome. Use the CSP header instead."](../../../assets/validation-csp.png)
-In the example above, there is a `<meta>` CSP element, so capo.js warns that "CSP meta tags disable the preload scanner due to a bug in Chrome. Use the CSP header instead."
-This validation warning is an example of capo.js being more opinionated than simply following the specification. The warning includes a recommendation to use the CSP header instead, which avoids the preload scanner issue all together. Also note that the `Content-Security-Policy-Report-Only` directive is only valid as an HTTP header and not as a `<meta http-equiv>` element.
-Additionally, some CSP directives are not allowed in the `<meta>` declaration:
-- `frame-ancestors`
-- `sandbox`
-- `report-uri`
-If capo.js detects any of these directives in a `<meta>` CSP element, it will log a validation warning.
-### No invalid origin trials
-Sites can register for [origin trials](https://developer.chrome.com/en/docs/web-platform/origin-trials/) to enable individual experimental web platform features. To enable them on a given site, a token must be included as either an `Origin-Trial` HTTP header or `<meta http-equiv>` element.
-These tokens contain encoded metadata about the origin trial registration, including:
-- the name of the experimental feature
-- the allowed origin
-- the expiration date
-- whether other subdomains are allowed
-- whether other origins are allowed
-capo.js decodes these tokens and validates their metadata to ensure that:
-- the token is not expired
-- the origin is an allowed subdomain
-- the origin is an allowed third party
-:::caution[Origin trial validation with static evaluation]
-Embedded third parties may dynamically inject origin trial `<meta>` elements in order for them to make use of experimental features. By default, capo.js will only evaluate elements in the static `<head>`, so these elements will not be validated. Enable the [dynamic evaluation](/capo.js/user/config/#static-and-dynamic-evaluation) option to validate them.
-:::
-If capo.js detects an invalid origin trial token, it will log a validation warning:
-![Validation warnings that "Invalid origin trial token: invalid origin and expired."](../../../assets/validation-origin-trial.png)
-In the example above, two separate embedded third party scripts injected origin trial `<meta>` elements with invalid tokens, so in each case capo.js warns that there is an "Invalid origin trial token". The warning also includes a reference to the `<meta>` element as well as the decoded token metadata.
-In the first warning, the token contains an invalid origin. The token metadata is missing the `isThirdParty` flag and the `origin` property is set `https://googlesyndication.com:443`, which is presumably the third party that injected the token. However, because the origin of the page is different from the one in the origin trial metadata, and it wasn't registered as a third party token, it's not valid. A similar warning would appear if the origin of the page is `https://www.example.com` but the origin in the metadata is `https://example.com:443` and it's missing the `isSubdomain` flag.
-In the second warning, the origin is a valid third party, but the token is expired. In the token metadata, you can see that it expired in November 2022.
-### No invalid `default-style` directives
-The `default-style` directive indicates which [alternative stylesheet](https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets) should be enabled. While it's completely standard and supported across browsers, [adoption is extremely low](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/#http-equiv-adoption) at only about 1k websites. Of those, about [31%](https://rviscomi.dev/2023/07/you-probably-dont-need-http-equiv-meta-tags/#default-style) are used incorrectly.
-To be used correctly, the `content` attribute of the directive must be equal to the `title` value of an alternative stylesheet. capo.js will warn when the title cannot be found and the directive has no effect.
-In addition to flagging incorrect usage, capo.js will also discourage using this directive entirely. Setting a preferred stylesheet results in a flash of unstyled content, which could be avoided by using default stylesheets with `@media` rules instead.
-### No invalid character encoding
-The `content-type` directive is an alias for the `charset` meta tag, which declares the document's content encoding. The [HTML spec](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-type) places strict requirements on how and where this declaration can occur:
-- The document cannot have both a `content-type` directive and a `charset` meta tag
-- If one does exist, the character encoding declaration must be found within the firsts 1024 bytes of the document
-- If one does exist, the character encoding must be set to UTF-8
-It's valid for a document not to have either `content-type` nor `charset` meta tags, as long as the `Content-Type` HTTP header is set, also to UTF-8. capo.js does not presently validate HTTP headers, only the contents of the document `<head>`.
-capo.js will validate that all three of the requirements above are met, and log a warning if not. If there are redundant character encoding declarations, capo.js will warn on the `content-type` element, giving preference to the `charset` meta tag. If the declaration occurs too late, capo.js will include the byte index for reference. And if the encoding is not set to UTF-8, capo.js will log the actual encoding used.
-### No meta refresh
-The `refresh` directive can force the page to reload or redirect after a specified amount of time. This is considered an [accessibility issue](https://www.w3.org/TR/WCAG10-CORE-TECHS/#auto-page-refresh) by the WCAG. It can be disorienting to users for the page to suddenly reload or redirect, and there are more semantic ways to indicate that a page's contents have moved.
-capo.js issues a warning whenever a meta `refresh` directive is found. If it contains a redirect, capo.js encourages using HTTP 3xx redirects instead. Otherwise, it encourages including a mechanism for users to disable the auto-reloading behavior, if one is not already provided by browsers.
-### Don't disable DNS prefetching
-The [`x-dns-prefetch-control`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control) HTTP header and meta directive are non-standard, but widely supported. By default, most browsers will speculatively resolve the DNS records for URLs needed by the page, which is a generally accepted performance optimization.
-In Chrome, any value other than `on` will disable the default DNS prefetching behavior. capo.js will always warn when this directive is found, and the message will be unique to the usage. In cases when DNS prefetching is explicitly enabled, capo.js clarifies that this has no effect as it's already the default behavior. In cases where it's set to `off`, capo.js emphasizes the performance benefits of DNS prefetching and clarifies that it should only be disabled when there are legitimate security concerns. For all other values besides `on` and `off`, capo.js warns about using non-standard values and reiterates the performance and security considerations.
-## No invalid viewport directives
-The `viewport` meta tag is typically used to control the layout of the page on mobile devices. There are a small number of supported viewport directives, and capo.js will validate them to ensure they are used correctly.
-capo.js will log a warning if any unsupported directives are used, or if any of the supported directives are used incorrectly. For example, the `initial-scale` directive must be a positive number between 0.1 and 10 and capo.js will warn if it is not.
-Some directives have accessibility implications. For example, the `user-scalable` directive can be set to `no` to prevent users from zooming in on the page. This can be a problem for users with low vision who rely on zooming to read text. capo.js will log a warning if the `user-scalable` directive is set to `no`, or its alias `0`.

package/node_modules/@rviscomi/capo.js/docs/src/env.d.ts DELETED Viewed

	@@ -1,2 +0,0 @@
1	- /// <reference path="../.astro/types.d.ts" />
2	- /// <reference types="astro/client-image" />