1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-23 12:52:10 +00:00

Info about csp, halation

- Mention pitfalls of a <meta>-based CSP
- Describe halation a bit more, with an image.
This commit is contained in:
Rohan Kumar 2022-03-28 18:11:55 -07:00
parent aa631df58b
commit 3a639537b3
No known key found for this signature in database
GPG key ID: 1E892DB2A5F84479
5 changed files with 48 additions and 5 deletions

BIN
assets/p/halation.avif Normal file

Binary file not shown.

BIN
assets/p/halation.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.7 KiB

BIN
assets/p/halation.webp Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.1 KiB

View file

@ -70,6 +70,12 @@ sandbox allow-same-origin
While "script-src" restricts script loading, "sandbox" can also restrict script execution with stronger defenses against script injection (e.g. by a browser addon).¹ I added the "allow-same-origin" parameter so that these addons will still be able to function.²
If you're able to control your HTTP headers, then use headers instead of a <meta http=equiv> tag. In addition to not supporting certain directives, a CSP in a <meta> tag might let some items slip through:
> At the time of inserting the meta element to the document, it is possible that some resources have already been fetched. For example, images might be stored in the list of available images prior to dynamically inserting a meta element with an http-equiv attribute in the Content security policy state. Resources that have already been fetched are not guaranteed to be blocked by a Content Security Policy that's enforced late.
=> https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-security-policy HTML Living Standard, Content Security Policy state
### If you must enable scripts
Please use progressive enhancement³ throughout your site; every feature possible should be optional, and scripting is no exception.
@ -248,11 +254,16 @@ Note that the APCA isn't fully mature as of early 2022. Until version 3.0 of the
CSS filters such as "invert" are expensive to run, so use them sparingly. Simply inverting your page's colors to provide a dark theme could slow it down or cause a user's fans to spin.
Darker backgrounds draw less power on devices with OLED screens; however, backgrounds should never be solid black. White text on a black background causes halation, especially among astigmatic readers. There has been some experimental and plenty of anecdotal evidence to support this.
Darker backgrounds draw less power on devices with OLED screens; however, backgrounds should never be solid black. White text on a black background causes halation, especially among astigmatic readers. Halation comes from the word "halo", and refers to a type of "glow" or ghosting around words. There has been some experimental and plenty of anecdotal evidence to support this:
=> https://www.laurenscharff.com/research/AHNCUR.html Hill, Alyson (supervised by Scharff, L.V.) Readability Of Websites With Various Foreground / Background Color Combinations, Font Types And Word Styles, 1997
=> https://jessicaotis.com/academia/never-use-white-text-on-a-black-background-astygmatism-and-conference-slides/ Never Use White Text on a Black Background: Astygmatism and Conference Slides
Here's an approximation of what this kind of halation looks like:
=> gemini://seirdy.one/misc/halation.png Fuzzy white text on black background reading "But it is not" (image/png)
=> https://www.essentialaccessibility.com/blog/accessibility-for-people-with-astigmatism image source
I personally like a foreground and background of "#ececec" and "#0c0c0c", respectively. These shades seem to be as far apart as possible without causing accessibility issues: "#0c0c0c" is barely bright enough to create a soft "glow" capable of minimizing halos, but won't ruin contrast on cheap displays.
"Just disable dark mode" is a poor response to users complaining about halation: it ignores the utility of dark themes described at the beginning of this section.
@ -757,7 +768,7 @@ Before you throw up your hands and decide you can't help everyone, take another
## Further reading
Parts of this page can be thought of as an extension to the principles of Brutalist Web Design:
Parts of this page can be thought of as an extension to the principles of Brutalist Web Design, which favors "raw content true to its construction":
* Content is readable on all reasonable screens and devices.
* Only hyperlinks and buttons respond to clicks.

View file

@ -69,6 +69,26 @@ sandbox allow-same-origin
`default-src: 'none'` implies `script-src: 'none'`, causing a compliant browser to forbid the loading of scripts. Furthermore, the `sandbox` CSP directive forbids a [wide variety](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/sandbox) of potentially insecure actions. While `script-src` restricts script loading, `sandbox` can also restrict script execution with stronger defenses against script injection (e.g. by a browser addon).[^1] I added the `allow-same-origin` parameter so that these addons will still be able to function.[^2]
If you're able to control your HTTP headers, then use headers instead of a `<meta http=equiv>` tag. In addition to not supporting certain directives, a CSP in a `<meta>` tag might let some items slip through:
<figure>
<blockquote>
<p>
At the time of inserting the <code>meta</code> element to the document, it is
possible that some resources have already been fetched. For example, images might be stored in
the <a href="https://html.spec.whatwg.org/multipage/images.html#list-of-available-images">list of available images</a> prior to dynamically inserting a <code>meta</code>
element with an <code>http-equiv</code> attribute in the Content security policy state.
Resources that have already been fetched are not guaranteed to be blocked by a <a href="https://w3c.github.io/webappsec-csp/#content-security-policy-object">Content
Security Policy</a> that's <a href="https://w3c.github.io/webappsec-csp/#enforced">enforced</a> late.
</p>
</blockquote>
<figcaption>
-- <cite>HTML Living Standard</cite>, [Content Security Policy state](https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-security-policy)
</figcaption>
</figure>
### If you must enable scripts
Please use progressive enhancement (<abbr title="progressive enhancement">PE</abbr>)[^3] throughout your site; every feature possible should be optional, and scripting is no exception.
@ -207,7 +227,18 @@ Note that the APCA isn't fully mature as of early 2022. Until version 3.0 of the
CSS filters such as `invert` are expensive to run, so use them sparingly. Simply inverting your page's colors to provide a dark theme could slow it down or cause a user's fans to spin.
Darker backgrounds draw less power on devices with OLED screens; however, backgrounds should never be solid black. White text on a black background causes halation, especially among astigmatic readers. There has been some [experimental](https://www.laurenscharff.com/research/AHNCUR.html) and plenty of [anecdotal](https://jessicaotis.com/academia/never-use-white-text-on-a-black-background-astygmatism-and-conference-slides/) evidence to support this. I personally like a foreground and background of `#ececec` and `#0c0c0c`, respectively. These shades seem to be as far apart as possible without causing accessibility issues: `#0c0c0c` is barely bright enough to create a soft "glow" capable of minimizing halos, but won't ruin contrast on cheap displays.
Darker backgrounds draw less power on devices with OLED screens; however, backgrounds should never be solid black. White text on a black background causes halation, especially among astigmatic readers. Halation comes from the word "halo", and refers to a type of "glow" or ghosting around words. There has been some [experimental](https://www.laurenscharff.com/research/AHNCUR.html) and plenty of [anecdotal](https://jessicaotis.com/academia/never-use-white-text-on-a-black-background-astygmatism-and-conference-slides/) evidence to support this.
<figure>
<figcaption>
The following image is an approximation of what halation looks like, cropped from <a href="https://www.essentialaccessibility.com/blog/accessibility-for-people-with-astigmatism">Essential Accessibility</a>.
</figcaption>
{{< picture name="halation" alt="Fuzzy white text on black background reading \"But it is not\"." >}}
</figure>
I personally like a foreground and background of `#ececec` and `#0c0c0c`, respectively. These shades seem to be as far apart as possible without causing accessibility issues: `#0c0c0c` is barely bright enough to create a soft "glow" capable of minimizing halos, but won't ruin contrast on cheap displays.
"Just disable dark mode" is a poor response to users complaining about halation: it ignores the utility of dark themes described at the beginning of this section.
@ -661,7 +692,8 @@ Parts of this page can be thought of as an extension to the principles of Brutal
<figure itemscope itemtype="https://schema.org/Quotation">
<blockquote>
<ul>
<p>Raw content true to its construction:</p>
<ol>
<li>Content is readable on all reasonable screens and devices.</li>
<li>Only hyperlinks and buttons respond to clicks.</li>
<li>Hyperlinks are underlined and buttons look like buttons.</li>
@ -669,7 +701,7 @@ Parts of this page can be thought of as an extension to the principles of Brutal
<li>View content by scrolling.</li>
<li>Decoration when needed and no unrelated content.</li>
<li>Perform&shy;ance is a feature.</li>
</ul>
</ol>
</blockquote>
<figcaption class="h-cite" itemprop="citation">
&mdash; {{<indieweb-person first-name="David" last-name="Copeland" url="https://naildrivin5.com/">}}, <cite itemprop="isPartOf" itemscope itemtype="https://schema.org/CreativeWork"><a class="u-url p-name" itemprop="url" href="https://brutalist-web.design/"><span itemprop="name">Brutalist Web Design</span></a></cite>