Compare commits
13 Commits
0d6542289e
...
post-siden
| Author | SHA1 | Date | |
|---|---|---|---|
| b4a1097845 | |||
| adc582116b | |||
| 7d5c696fa7 | |||
| 60eea00b88 | |||
| da72464f9a | |||
| 1a77127979 | |||
| 15e61d858d | |||
| 1972c5714c | |||
| ce411549ad | |||
| ec22cebeac | |||
| 40ea5014dd | |||
| 05c8fcf5f4 | |||
| e0c2dc2ab8 |
@ -3,6 +3,7 @@
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<link rel="preload" href="/Tajawal-Regular.woff2" as="font" type="font/woff2" />
|
||||
<link rel="preload" href="/Baskerville-Regular.woff2" as="font" type="font/woff2" />
|
||||
<link rel="icon" href="/favicon.png" />
|
||||
<link rel="stylesheet" href="/style.css" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
|
||||
42
src/lib/Dropcap.svelte
Normal file
42
src/lib/Dropcap.svelte
Normal file
@ -0,0 +1,42 @@
|
||||
<script>
|
||||
// Usage: <Dropcap word="Lorem">ipsum dolor sit amet...</Dropcap>
|
||||
|
||||
export let word;
|
||||
const initial = word.slice(0, 1);
|
||||
const remainder = word.slice(1);
|
||||
|
||||
// a few letters are narrower at the top, so we need more of a shift
|
||||
const shiftValues = {
|
||||
A: '-0.45em',
|
||||
L: '-0.3em',
|
||||
R: '-0.25em',
|
||||
};
|
||||
|
||||
const shift = shiftValues[initial] || '0em';
|
||||
</script>
|
||||
|
||||
<style>
|
||||
.drop-cap {
|
||||
text-transform: uppercase;
|
||||
color: #8c0606;
|
||||
/* box-sizing: border-box;*/
|
||||
font-size: calc(var(--content-size) * var(--content-line-height) * 1.75);
|
||||
float: left;
|
||||
font-family: 'Baskerville';
|
||||
line-height: 0.8;
|
||||
margin-right: 0.1em;
|
||||
display: block;
|
||||
}
|
||||
|
||||
.first-word {
|
||||
margin-left: var(--shift);
|
||||
font-variant: petite-caps;
|
||||
}
|
||||
</style>
|
||||
|
||||
<p>
|
||||
<span class="drop-cap">{initial}</span>
|
||||
<span class="first-word" style:--shift={shift}>{remainder}</span>
|
||||
<slot></slot>
|
||||
</p>
|
||||
|
||||
@ -13,6 +13,14 @@
|
||||
export const draft = false;
|
||||
</script>
|
||||
|
||||
<style>
|
||||
.subtitle {
|
||||
font-size: 0.9em;
|
||||
font-style: italic;
|
||||
margin-top: -0.5rem;
|
||||
}
|
||||
</style>
|
||||
|
||||
<svelte:head>
|
||||
<title>{title}</title>
|
||||
<link rel="stylesheet" href="/prism-dracula.css" />
|
||||
@ -20,6 +28,6 @@
|
||||
|
||||
<div id="post">
|
||||
<h1 id="{makeSlug(title)}">{title}</h1>
|
||||
<p><em>{formatDate(date)}</em></p>
|
||||
<p class="subtitle">{formatDate(date)}</p>
|
||||
<slot></slot>
|
||||
</div>
|
||||
|
||||
@ -10,7 +10,7 @@
|
||||
margin-left: 0.05rem;
|
||||
|
||||
&:after {
|
||||
font-size: 0.75rem;
|
||||
font-size: 0.75em;
|
||||
position: relative;
|
||||
bottom: 0.3rem;
|
||||
color: #8c0606;
|
||||
@ -23,9 +23,13 @@
|
||||
|
||||
&:before {
|
||||
content: counter(sidenote) " ";
|
||||
position: relative;
|
||||
/* absolute positioning puts it at the top-left corner of the sidenote, overlapping with the content
|
||||
(because the sidenote is floated it counts as a positioned parent, I think) */
|
||||
position: absolute;
|
||||
/* translate moves it out to the left (and just a touch up to mimic the superscript efect)
|
||||
-100% refers to the width of the element, so it pushes it out further if necessary (i.e. two digits instead of one) */
|
||||
transform: translate(calc(-100% - 0.2rem), -0.15rem);
|
||||
font-size: 0.75rem;
|
||||
bottom: 0.2rem;
|
||||
color: #8c0606;
|
||||
}
|
||||
}
|
||||
@ -43,7 +47,7 @@
|
||||
.sidenote {
|
||||
--gap: 2rem;
|
||||
--sidenote-width: min(14rem, calc(50vw - var(--gap) - var(--content-width) / 2));
|
||||
max-width: var(--sidenote-width);
|
||||
width: var(--sidenote-width);
|
||||
hyphens: auto;
|
||||
position: relative;
|
||||
float: right;
|
||||
@ -51,6 +55,16 @@
|
||||
margin-right: calc(0rem - var(--sidenote-width) - var(--gap)); // gives us 2rem of space between content and sidenote
|
||||
margin-bottom: 0.7rem;
|
||||
}
|
||||
|
||||
.nested.sidenote {
|
||||
margin-right: 0;
|
||||
margin-top: 0.7rem;
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
.dismiss {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
/* mobile display */
|
||||
@ -67,12 +81,15 @@
|
||||
.sidenote {
|
||||
box-sizing: border-box;
|
||||
position: fixed;
|
||||
z-index: 1;
|
||||
left: 0;
|
||||
bottom: 0;
|
||||
width: 100vw;
|
||||
padding-top: 1rem;
|
||||
padding-bottom: 1rem;
|
||||
padding-right: 2rem;
|
||||
--pad: max(1rem, calc(50vw - var(--content-width) / 2));
|
||||
padding-left: var(--pad);
|
||||
padding-right: var(--pad);
|
||||
background-color: #fff;
|
||||
box-shadow: 0 -2px 4px -1px rgba(0, 0, 0, 0.06), 0 -2px 12px -2px rgba(0, 0, 0, 0.1);
|
||||
display: none;
|
||||
@ -81,19 +98,35 @@
|
||||
.sidenote-toggle:checked + .sidenote {
|
||||
display: block;
|
||||
}
|
||||
|
||||
.dismiss {
|
||||
position: absolute;
|
||||
right: 1.5rem;
|
||||
top: -0.2rem;
|
||||
|
||||
font-size: 1.25rem;
|
||||
color: #8c0606;
|
||||
cursor: pointer;
|
||||
|
||||
&:hover {
|
||||
transform: scale(1.1);
|
||||
font-weight: 800;
|
||||
}
|
||||
}
|
||||
|
||||
/* slight tweaks for in between state */
|
||||
@media (min-width: 52.5em) and (max-width: 70em) {
|
||||
.sidenote {
|
||||
padding-left: calc(50vw - 19rem);
|
||||
}
|
||||
}
|
||||
@media (max-width: 52.5em) {
|
||||
.sidenote {
|
||||
padding-left: 2rem;
|
||||
}
|
||||
}
|
||||
|
||||
// /* slight tweaks for in between state */
|
||||
// @media (min-width: 52.5em) and (max-width: 70em) {
|
||||
// .sidenote {
|
||||
// padding-left: calc(50vw - 19rem);
|
||||
// }
|
||||
// }
|
||||
// @media (max-width: 52.5em) {
|
||||
// .sidenote {
|
||||
// padding-left: 2rem;
|
||||
// }
|
||||
// }
|
||||
</style>
|
||||
|
||||
<script context="module">
|
||||
@ -101,6 +134,21 @@
|
||||
</script>
|
||||
|
||||
<script>
|
||||
import { onMount } from 'svelte';
|
||||
|
||||
let noteBody;
|
||||
let nested = false;
|
||||
onMount(() => {
|
||||
// check to see if the parent node is also a sidenote, if so move this one to the end
|
||||
let parentNote = noteBody.parentElement.closest('span.sidenote');
|
||||
if (parentNote) {
|
||||
noteBody.remove();
|
||||
parentNote.appendChild(noteBody);
|
||||
nested = true;
|
||||
}
|
||||
});
|
||||
|
||||
|
||||
const id = Math.random().toString().slice(2);
|
||||
let toggle;
|
||||
|
||||
@ -120,6 +168,7 @@
|
||||
|
||||
<label for={id} on:click={toggleState} class="counter"></label>
|
||||
<input {id} bind:this={toggle} type="checkbox" class="sidenote-toggle" />
|
||||
<span class="sidenote">
|
||||
<span class="sidenote" class:nested bind:this={noteBody}>
|
||||
<label class="dismiss" for={id} on:click={toggleState}>×</label>
|
||||
<slot></slot>
|
||||
</span>
|
||||
48
src/lib/UnstyledSidenote.svelte
Normal file
48
src/lib/UnstyledSidenote.svelte
Normal file
@ -0,0 +1,48 @@
|
||||
<script>
|
||||
export let floatingCounter = true;
|
||||
export let classes = '';
|
||||
export {classes as class};
|
||||
</script>
|
||||
|
||||
<style>
|
||||
:global(body) {
|
||||
counter-reset: sidenote unstyled-sidenote;
|
||||
}
|
||||
|
||||
.counter {
|
||||
counter-increment: unstyled-sidenote;
|
||||
margin-left: 0.05rem;
|
||||
}
|
||||
.counter::after {
|
||||
content: counter(unstyled-sidenote);
|
||||
font-size: 0.75em;
|
||||
position: relative;
|
||||
bottom: 0.3em;
|
||||
color: #0083c4;
|
||||
}
|
||||
|
||||
.sidenote {
|
||||
color: var(--content-color-faded);
|
||||
font-size: 0.8rem;
|
||||
}
|
||||
.sidenote.floatingCounter::before {
|
||||
content: counter(unstyled-sidenote);
|
||||
font-size: 0.75rem;
|
||||
color: #0083c4;
|
||||
/* Since the sidenote is floated it counts as a positioned element,
|
||||
so this would make the counter overlap the start of the text... */
|
||||
position: absolute;
|
||||
/* ...except that we move it out to the left and up a bit, so
|
||||
it's hanging out in space. 100% refers to the width of this
|
||||
pseudo-element, so we handle different-sized counters the same. */
|
||||
transform: translate(
|
||||
calc(-100% - 0.16em),
|
||||
-0.12em
|
||||
);
|
||||
}
|
||||
</style>
|
||||
|
||||
<span class="counter"></span>
|
||||
<span class="sidenote {classes}" class:floatingCounter={floatingCounter}>
|
||||
<slot></slot>
|
||||
</span>
|
||||
20
src/lib/projects/sidenotes/Frame.svelte
Normal file
20
src/lib/projects/sidenotes/Frame.svelte
Normal file
@ -0,0 +1,20 @@
|
||||
<script>
|
||||
import Step from './Step.svelte';
|
||||
import {onMount} from 'svelte';
|
||||
|
||||
let frame;
|
||||
onMount(() => {
|
||||
frame.setAttribute('srcdoc', frame.innerHTML);
|
||||
})
|
||||
</script>
|
||||
|
||||
|
||||
<iframe bind:this={frame}>
|
||||
<html>
|
||||
<head></head>
|
||||
<body>
|
||||
<Step />
|
||||
<p>Goodbye world!</p>
|
||||
</body>
|
||||
</html>
|
||||
</iframe>
|
||||
7
src/lib/projects/sidenotes/Step.svelte
Normal file
7
src/lib/projects/sidenotes/Step.svelte
Normal file
@ -0,0 +1,7 @@
|
||||
<script>
|
||||
let count = 0;
|
||||
</script>
|
||||
|
||||
<p>hello world!</p>
|
||||
<button on:click={() => count++}>Increment</button>
|
||||
<p>The count is: {count}</p>
|
||||
@ -13,9 +13,9 @@ A while back I had occasion to make a number of docker containers directly acces
|
||||
|
||||
In my case, the reason for doing this was so that I could expose multiple difference services that all wanted to bind the same port. In other words, given that I was going to be hosting more than one HTTP-based application, I didn't want to have to remember (and type out all the time) a bunch of different ports to distinguish between the services I wanted to talk to. DNS is great, but it only points to IP addresses<Sidenote>Well, SRV records can include ports, but browsers don't pay attention to those.</Sidenote>, after all.
|
||||
|
||||
That said, had I only realized it at the time, there's a much better way to accomplish this than exposing entire containers to the LAN, and much less... questionable from a security standpoint: Just bind multiple IPs on the host. Docker allows you to specify what IP address to bind when forwarding a port to a container, so you can forward e.g. 192.168.50.21:80 to App 1, and 192.168.50.22:80 to App 2, and neither the apps nor the users need ever worry their pretty little heads about a thing. This is better than exposing the container directly - containerized applications generally expect to be pretty isolated from a networking point of view, with external traffic only hitting the one or two ports that they specify as their window to the outside world. So if some packaged application has to run its own Redis server<Sidenote>Because some people just can't help jamming Redis into every app they write, it's like a spinal reflex or something.</Sidenote>, it might not take the extra step of only binding to localhost, and congratulations now anyone on the LAN can read your session cookies or whatever.<Sidenote>Alternatively you can do what I did: Set up a _shared_ Redis server for a _bunch_ of different applications, in Docker of course, and then _knowingly_ expose that to the entire LAN, and damn the torpedoes. I cannot legally recommend this course of action.</Sidenote>
|
||||
That said, had I only realized it at the time, there's a much better way to accomplish this than exposing entire containers to the LAN, and much less... questionable from a security standpoint: **Just bind multiple IPs on the host**. Docker allows you to specify what IP address to bind when forwarding a port to a container, so you can forward e.g. 192.168.50.21:80 to App 1, and 192.168.50.22:80 to App 2, and neither the apps nor the users need ever worry their pretty little heads about a thing. This is better than exposing the container directly - containerized applications generally expect to be pretty isolated from a networking point of view, with external traffic only hitting the one or two ports that they specify as their window to the outside world. So if some packaged application has to run its own Redis server<Sidenote>Because some people just can't help jamming Redis into every app they write, it's like a spinal reflex or something.</Sidenote>, it might not take the extra step of only binding to localhost, and congratulations now anyone on the LAN can read your session cookies or whatever.<Sidenote>Alternatively you can do what I did: Set up a _shared_ Redis server for a _bunch_ of different applications, in Docker of course, and then _knowingly_ expose that to the entire LAN, and damn the torpedoes. I cannot legally recommend this course of action.</Sidenote>
|
||||
|
||||
The caveat here is of course that you need to be sure the IP addresses you use aren't going to be stolen out from under you by somebody's iPad or something next time it connects to the network. This is easy if you control the DHCP server, and either easy or impossible if you don't. For reasons that I've never fully understood, but _probably_ boil down to leaving room for people to do exactly this sort of thing, many standard DHCP configurations assign IPs from just a portion of the available range. .100 is a common start point in a /24 network, so you can usually expect that .2-.99 will be available for you to work your will upon.
|
||||
The caveat here is of course that you need to be sure the IP addresses you use aren't going to be stolen out from under you by somebody's iPad or something next time it connects to the network. This is easy if you control the DHCP server, and either easy or impossible if you don't. For reasons that I've never fully understood, but _probably_ boil down to leaving room for people to do exactly this sort of thing, many standard DHCP configurations assign IPs from just a portion of the available range. `.100` is a common start point in a /24 network, so you can usually expect that `.2`-`.99`<Sidenote>Someday I'm going to set up a network where the router is at, like, .233 or something instead of .1, just to freak out the one or two people who might ever notice.</Sidenote> will be available for you to work your will upon.
|
||||
|
||||
The worse solution (exposing containers directly to the LAN) has this same caveat, so it's just worse in every way, there's really no advantage except that _maybe_ it's lower-overhead, since not as much forwarding of packets needs to take place. So yeah, probably just don't unless your containerized application _really needs_ Layer 2 access to the network, like it's an intrusion detection system and needs keep an eye on broadcast traffic or something.
|
||||
|
||||
@ -40,4 +40,6 @@ This isn't actually what the first draft of this post said. Initially I was goin
|
||||
|
||||
`ipvlan` is a lot easier, though, and gives you almost exactly the same result. The only difference is that with `macvlan` Docker will actually make up a MAC address for the virtual interface and respond to ARP queries and so on with that. With `ipvlan` it just uses the host MAC. My suspicion is that this is probably another argument _for_ `ipvlan`, as I think I remember reading that multiple MAC addresses on one physical interface is considered a Bad Sign by some network watchdog types of things.
|
||||
|
||||
I'm really not sure why I ended up going for `macvlan` in my own case. Maybe `ipvlan` was a later invention so the guides I came across weren't aware of it? Anyway it's there, and it works a lot better than `macvlan` for most use cases, so it's almost certainly what you should use.<Sidenote>In the event that you need to use either of them, that is. Which you probably [don't](#aside-you-probably-dont-want-this).</Sidenote>
|
||||
|
||||
So there you have it. You can dump containers on your LAN, and they will (from a networking standpoint) behave as if they were their own machines. But you probably don't want to.
|
||||
|
||||
24
src/routes/_posts/languages-high-and-low.svx
Normal file
24
src/routes/_posts/languages-high-and-low.svx
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
title: 'Languages: High and Low'
|
||||
description: How high is up?
|
||||
date: 2022-08-19
|
||||
draft: true
|
||||
---
|
||||
|
||||
<script>import Sidenote from '$lib/Sidenote.svelte';</script>
|
||||
|
||||
Here's a fun way to start an argument: Go ask on a programming forum whether C should be considered a "high-level" or "low-level" language. The majority of responses will be along the lines of "low-level, obviously, you have to call `malloc()` all the time", but every once in a while you'll find some crusty old wizard who earned his sripes on MULTICS grousing about how kids these days don't understand what a _real_ low-level language looks like, and back in my day we had to flip individual bits with our teeth, and so on.
|
||||
|
||||
The truth is, asking whether a language is high- or low-level unqualifiedly is sort of like asking whether an object is heavy. Heavy relative to what? The question is open-ended without some frame of reference.<Sidenote>Of course, most people have an implicit frame of reference for this question that resolves to "heavy relative to the objects I commonly encounter in my day-to-day life". As it turns out (in my opinion), most programmers have a similar implicit frame of reference when it comes to languages, which is where you get the disagreement I mentioned earlier.</Sidenote> A boulder is heavy relative to a peanut, but quite light compared to an oil tanker.
|
||||
|
||||
A better question, in my opinion, is whether one language is _higher-_ or _lower-level_ than another, and this is where it gets interesting. Most people will probably agree that higher-level languages are _more abstract_ than lower-level ones, i.e. they take more of the fiddly details of what's actually going on inside the computer and hide them away so that you, the programmer, don't have to worry about them.
|
||||
|
||||
You can probably throw little language-specific details back and forth until the cows come home, but I think there are a few common "break-points" that you can use to group languages into buckets of similarly high- or low-level-ness. To me, they look something like this:
|
||||
|
||||
* **Level 1** langauges give you control over individual registers (just assembly, basically)
|
||||
* **Level 2** languages give you control over memory allocation and raw pointers. E.g. C and C++, and Zig I guess? Also a lot of older languages like Pascal and Ada.
|
||||
* **Level 3** languages handle memory allocation and deallocation for you, but still distinguish between the stack and the heap. Java, C#, and Go fall here, as do Nim, Crystal, probably Pony, V, and others.<Sidenote>You can even make the argument that Rust belongs at this level. Even though it's often referred to as a "systems" language, which most people associate with "low level", it _kind of_ abstracts away the work of allocating and deallocating memory. It just doesn't abstract it quite as _much_ as other languages, since you do still have to think about it.</Sidenote> You can further split this level into those that require a runtime (Java, C#) and those that don't (Go, Nim, Crystal, etc.) Although more properly I guess the latter category just embed their runtime, rather than requiring it to exist separately.
|
||||
* **Level 4** languages give you control over things like intermediate variables and so on - there are probably a lot of sub-levels here, like having to instantiate loop variables vs. having them handled for you,<Sidenote>Or both! Hi Javascript!</Sidenote> but I think this is the core of it. Most dynamic/interpreted languages probably fall here: Python, JS, Ruby, PHP, Perl, etc.
|
||||
* **Level 5** languages don't give you control over any of those. The only one I can think of off the top of my head is SQL, but there are probably others. I have a hunch that at this point you tend to see a lot more domain-specific stuff, since it's easier to abstract away details when you know what the use-case will look like.
|
||||
|
||||
I can also imagine a Level 0 which gives you control over things that aren't currently exposed by the underlying hardware. For instance, you could have a language construct that allows you to "pin" memory regions to a certain cache level, guaranteeing that you can always access it quickly. Or you could attach a "hint" to a branching codepath that allows you to override the CPU's branch predictor, if you know that one case will be overwhelmingly more common than the other. I wonder whether we'll start to see this sort of thing in the future, as Moore's Law continues to slow down and people start looking for more and more ways to squeeze maximum performance out of their hardware.
|
||||
201
src/routes/_posts/sidenotes.svx
Normal file
201
src/routes/_posts/sidenotes.svx
Normal file
@ -0,0 +1,201 @@
|
||||
---
|
||||
title: Sidenotes
|
||||
description: An entirely-too-detailed dive into how I implemented sidenotes for this blog.
|
||||
date: 2023-08-14
|
||||
---
|
||||
<script>
|
||||
import Dropcap from '$lib/Dropcap.svelte';
|
||||
import Sidenote from '$lib/Sidenote.svelte';
|
||||
import UnstyledSidenote from '$lib/UnstyledSidenote.svelte';
|
||||
import Frame from '$lib/projects/sidenotes/Frame.svelte';
|
||||
</script>
|
||||
|
||||
<style>
|
||||
.counter {
|
||||
counter-increment: sidenote;
|
||||
}
|
||||
|
||||
.counter::before {
|
||||
content: counter(sidenote);
|
||||
color: var(--accent-color);
|
||||
font-size: 0.75rem;
|
||||
position: relative;
|
||||
bottom: 0.2rem;
|
||||
margin-left: 0.1rem;
|
||||
}
|
||||
|
||||
.sidenote-absolute {
|
||||
position: absolute;
|
||||
left: calc(50% + min(100%, var(--content-width)) / 2 + 1rem);
|
||||
max-width: 12rem;
|
||||
font-size: 0.75rem;
|
||||
}
|
||||
.sidenote-absolute::before {
|
||||
content: counter(sidenote);
|
||||
color: var(--accent-color);
|
||||
font-size: 0.75rem;
|
||||
position: relative;
|
||||
bottom: 0.2rem;
|
||||
margin-right: 0.1rem;
|
||||
}
|
||||
|
||||
:global(.sn-float) {
|
||||
float: right;
|
||||
}
|
||||
:global(.sn-clear) {
|
||||
float: right;
|
||||
clear: right;
|
||||
}
|
||||
:global(.sn-gutter) {
|
||||
float: right;
|
||||
width: 14rem;
|
||||
margin-right: -14rem;
|
||||
}
|
||||
:global(.sn-gap) {
|
||||
float: right;
|
||||
width: 14rem;
|
||||
margin-right: -16rem;
|
||||
}
|
||||
:global(.sn-var-width) {
|
||||
float: right;
|
||||
--width: min(14rem, calc(50vw - var(--content-width) / 2) - 2rem);
|
||||
width: var(--width);
|
||||
margin-right: calc(0rem - var(--width) - 2rem);
|
||||
}
|
||||
</style>
|
||||
|
||||
<Dropcap word="One">of my major goals when building this blog was to have sidenotes. I've always been a fan of sidenotes on the web, because the most comfortable reading width for a column of text is <em>far</em> less than the absurd amounts of screen width we tend to have available, and what else are we going to use it for?<Sidenote>Some sites use it for ads, of course, which is yet another example of how advertising ruins everything.</Sidenote></Dropcap>
|
||||
|
||||
Footnotes don't really work on the web the way they do on paper, since the web doesn't have page breaks. You _can_ stick your footnotes in a floating box at the bottom of the page, so they're visible at the bottom of the text just like they would be on a printed page, but this sacrifices precious vertical space.<Sidenote>On mobile, it's _horizontal_ space that's at a premium, so I do use this approach there. Although I'm a pretty heavy user of sidenotes, so I have to make them toggleable as well or they'd fill up the entire screen.</Sidenote> Plus, you usually end up with the notes further away from the point of divergence than they would be as sidenotes anyway.
|
||||
|
||||
I'm also not a huge fan of show-on-hover/click for marginalia, because it requires an extra interaction--and often a fairly precise one, which is always annoying.<Sidenote>This is especially true on mobile, where I've found myself selecting text instead of showing/hiding a note because I didn't get my finger in quite the right place.</Sidenote> Admittedly this style _does_ get you the absolute minimum distance between the marginalia and the main content, but I think the extra interaction is too heavy a price to pay.<Sidenote>Except on mobile, as mentioned. Mobile displays just don't have _any_ extra space at all, so you're left choosing between various unappealing options.</Sidenote>
|
||||
|
||||
So we're left with sidenotes, which I consider the crème de la crème of web-based marginalia. So okay, sure, sidenotes are great and all, but how do we actually _do_ them? Well! _wipes imaginary sweat from brow_ It sure was tough, and for a while there I thought I'd never make it through, but I done did figgered it out in the end!<Sidenote>_Narrator:_ He had not figured it out. He had googled around until he found someone else who had figured it out, and then copied their solution.</Sidenote>
|
||||
|
||||
## The Suboptimal Solution: Absolute Positioning
|
||||
|
||||
I'm naturally lazy, so I wanted the authoring experience to be as low-friction as possible so that I wouldn't end up foregoing sidenotes just because they were too much of a pain to put in. Since I had already settled on [mdsvex](https://mdsvex.pngwn.io/docs) for authoring my posts, I wanted sidenotes to be just another component that I could throw in mid-stream whenever I had an ancillary thought to express. This meant that DOM-wise, the sidenotes were going to be mixed right in with the main body text. Since I was also hoping to do this in pure CSS,<Sidenote>Because as much as I claim not to care, I secretly fear the Hacker News anti-Javascript brigade and desperately crave their approval.</Sidenote> meant that I was going to have to do something that removed the sidenote from the normal document flow, such as `position: absolute`.
|
||||
|
||||
My first approach was something like this:
|
||||
|
||||
```css
|
||||
.sidenote {
|
||||
position: absolute;
|
||||
/* 50% takes us to the midpoint of the page,
|
||||
half of content-width gets out out to the gutter,
|
||||
and the extra 1rem gives us some breathing room. */
|
||||
left: calc(50% + var(--content-width) / 2 + 1rem);
|
||||
max-width: 12rem;
|
||||
font-size: 0.75rem;
|
||||
}
|
||||
```
|
||||
|
||||
And it worked! Sort of. Here's an example.<span class="counter"></span><span class="sidenote-absolute">My initial take on sidenotes. Seems to be working, right?</span> Unfortunately it has a major flaw: Absolute positioning removes an element from the document flow _entirely_, while I wanted sidenotes to still flow with _each other_, That doesn't happen with this solution--if you have multiple sidenotes too close together, they will overlap because absolute positioning Just Doesn't Care.<span class="counter"></span><span class="sidenote-absolute">Like this one.</span><span class="counter"><span class="sidenote-absolute" style="transform: translateY(0.2rem)">And this one, which I've moved down just a smidge to make the overlap more apparent.</span>
|
||||
|
||||
Obviously, it isn't that hard to just scan through the page looking for sidenotes, detect when they overlap, and then (since they're already absolutely positioned) adjust their `top` values appropriately to get rid of the overlap. But I didn't want to do this for a variety of reasons.
|
||||
|
||||
* I wanted to write this as a Svelte component, which means that's the obvious place to put this logic. But because there are many instances of the component and I only want to run the collision-detection logic once, it has to be coordinated across multiple instances of the same component, which is painful.
|
||||
* Because we have to wait for the sidenote elements to _have_ concrete positions before we can detect whether they collide, we can't do this until they are mounted (i.e. inserted into the DOM). I was concerned that this would cause [FOUC](https://en.wikipedia.org/wiki/Flash_of_unstyled_content)-like problems, although in retrospect I don't actually recall it happening.<Sidenote>Possibly it was mitigated by the way Svelte batches DOM updates.</Sidenote>However, since I was always planning on static-rendering the site and letting SvelteKit do client-side hydration on page load, I don't think the possibility could ever be ruled out entirely.
|
||||
* Anything that triggered a reflow could cause the text to move around, but the sidenotes might not follow suit.<Sidenote>Specifically: sidenotes that had been adjusted to get rid of overlap would stay where they were, because they would already have an explicit `top` property. Sidenotes that hadn't been adjusted would move up and down as text reflowed, but this meant they could end up overlapping again.</Sidenote> [There are a lot of things that can cause a reflow](https://gist.github.com/paulirish/5d52fb081b3570c81e3a),<Sidenote>And this is just the ones that come from Javascript! It doesn't even address stuff like resizing the window or expanding/collapsing a `<details>` element.</Sidenote> and I'd have to listen to all of them if I wanted this to be a fully general solution. Sure, I could just be aware of this problem and avoid using reflow-causing events where possible--but I wanted the freedom to be able to add as much interactivity as I felt like to any given blog post without having to worry.
|
||||
|
||||
None of these problems are _completely_ inaddressible, but it was all going to be very fiddly to fix properly, so I decided to do a bit more research before throwing in the towel. And boy am I glad that I did, because it turns out that with enough...
|
||||
|
||||
## CSS Wizardry
|
||||
|
||||
...anything is possible.
|
||||
|
||||
Eventually I ran across [this post](https://scripter.co/sidenotes-using-only-css/), which solved my problem almost perfectly. The basic idea is extremely straightforward:
|
||||
|
||||
1. Give your sidenotes a `float` and `clear` in the same direction, so that they are removed from the regular document flow _but_ (and this is crucual) _they will still take each other into account for layout purposes._
|
||||
2. Give them a fixed width, and then:
|
||||
3. Give them a negative margin equal to the max-width, so that they are pulled out of the body of the text and hang out in the gutter.
|
||||
|
||||
It's shockingly simple, to be honest--I would never have thought of it myself, but I'm glad somebody out there did.<Sidenote>It's worth noting that this same approach seems to be used by [Tufte CSS](https://edwardtufte.github.io/tufte-css/), which I had looked at previously but had failed to comprehend, possibly because it doesn't really go into detail about its sidenote mechanism.</Sidenote> The only problem is that you can't nest sidenotes, which is something I had hoped to support, but we'll get to that in a bit.
|
||||
|
||||
## Implementation
|
||||
|
||||
It took me quite a while (longer than it should have, probably) to really grok this, so I wanted to go through the implementation step-by-step and show the effect of each component part. For starters, let's just get the basic appearance out of the way:
|
||||
|
||||
```css
|
||||
body {
|
||||
counter-reset: sidenote;
|
||||
}
|
||||
|
||||
.counter {
|
||||
counter-increment: sidenote;
|
||||
margin-left: 0.05rem;
|
||||
}
|
||||
.counter::after {
|
||||
content: counter(unstyled-sidenote);
|
||||
font-size: 0.75em;
|
||||
position: relative;
|
||||
bottom: 0.3em;
|
||||
color: var(--accent-color);
|
||||
}
|
||||
|
||||
.sidenote {
|
||||
color: var(--content-color-faded);
|
||||
font-size: 0.8rem;
|
||||
}
|
||||
.sidenote::before {
|
||||
content: counter(unstyled-sidenote);
|
||||
font-size: 0.75rem;
|
||||
color: var(--accent-color);
|
||||
/* Since the sidenote is floated it counts as a positioned element,
|
||||
so this would make the counter overlap the start of the text... */
|
||||
position: absolute;
|
||||
/* ...except that we move it out to the left and up a bit, so
|
||||
it's hanging out in space. 100% refers to the width of this
|
||||
pseudo-element, so we handle different-sized counters the same. */
|
||||
transform: translate(
|
||||
calc(-100% - 0.16em),
|
||||
-0.12em
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
This handles font size, color, and counters--CSS counters are very convenient for this, because they automatically adjust themselves whenever I go back and add or remove a sidenote earlier in the page. That gives us sidenote that looks like this:<UnstyledSidenote floatingCounter={false}>We're going to use a different color counter for these ones, so they can be more easily distinguished.</UnstyledSidenote>
|
||||
|
||||
It's still in flow, so our first change will be to remove it from the standard flow with `float: right`. Doing that moves it over to the side, like so.<UnstyledSidenote class="sn-float">The float also unmoors it from the text baseline.</UnstyledSidenote> Notice how it still takes up space in the body text, even though it's happening in a different place than its DOM location.
|
||||
|
||||
To keep it from doing that, we'll add a combination of a fixed width and a negative margin. The fixed width is primarily to give us a "target" number for the negative margin, since there isn't a good way to reference the width of the _current_ item when defining margins. (`margin-right: 100%` would move it by the width of the _containing_ block, which is not what we want.) With that in place, here's what we get.<UnstyledSidenote class="sn-gutter">Looking pretty good!</UnstyledSidenote> Unfortunately this example and subsequent ones don't work on mobile, since there are no gutters. Sorry about that! You'll have to view the desktop version to make them show up.
|
||||
|
||||
The next step is to keep the sidenotes from overlapping when there are multiple of them in quick succession, like these two.<UnstyledSidenote class="sn-gutter">This is one sidenote.</UnstyledSidenote><UnstyledSidenote class="sn-gutter">Another sidenote, which overlaps the first.</UnstyledSidenote> We do that with the `clear` property, which, when applied to a floated element, causes it to drop below any preceding floated elements on the specified side with which it would otherwise share a line.
|
||||
|
||||
This is easiest to show with an example, so let's do that. Here are two sidenotes with just `float: right` and no negative margin.<UnstyledSidenote class="sn-float">One.</UnstyledSidenote><UnstyledSidenote class="sn-float">Two.<span style="margin-right: 0.75rem"></span></UnstyledSidenote> [[Click here]] to animate the negative margin being applied to first the one, then the other. Applying negative margin to the first sidenote creates space for the other one to move to the side, since by nature floats want to form a horizontal row against the side of their containing block. Once we start applying negative margin to the second sidenote, though, normal flow rules don't apply, and they start to overlap.
|
||||
|
||||
This is fixed by `clear` because it changes the behavior of floats. Here are the same two sidenotes as above, but with `clear: right` applied to the second.<UnstyledSidenote class="sn-float">One.</UnstyledSidenote><UnstyledSidenote class="sn-clear">Two.</UnstyledSidenote> The `clear` property causes the second sidenote to drop below the first, which happens to be exactly the behavior that we want. All that's left is to apply the negative margin like so<UnstyledSidenote class="sn-clear sn-gutter">Three.</UnstyledSidenote><UnstyledSidenote class="sn-clear sn-gutter">Four.</UnstyledSidenote>and the whole stack will slide right over into the gutter.
|
||||
|
||||
It's smack up against the body text, though. In fact, since the floating counter hangs off to the left, it actually overlaps with the body text.(Depending on line wrapping, this may not be immediately apparent from the above.)
|
||||
|
||||
We can fix that in one of two ways. 1) We can increase the negative margin so that it's _greater_ than the width of the sidenote, or 2) We can just stick in some padding.<UnstyledSidenote class="sn-gap">Voila! Collision avoided.</UnstyledSidenote> I like the first option better, because it better reflects what we're actually doing here--margin is for creating caps _outside_ and _between_ elements, while padding is for gaps _inside_.
|
||||
|
||||
Here's what we have so far:
|
||||
|
||||
```css
|
||||
.sidenote {
|
||||
float: right;
|
||||
width: 14rem;
|
||||
margin-right: -16rem;
|
||||
}
|
||||
```
|
||||
|
||||
We still have a bit of a problem, though. Because we've assigned the sidenote a fixed width, it doesn't automatically shrink when the window gets too small for it. Obviously, of course, at _some_ point we're going to switch to the mobile version, which displays at the bottom of the screen and can be toggled on or off. But there are plenty of widths where sidenotes would still work perfectly well, just with a slightly narrower width than our initial `14rem`.
|
||||
|
||||
Fortunately, CSS `calc()` is widely supported and does exactly what we need.<UnstyledSidenote class="sn-var-width">Here we are! You may need to resize your window to get full effect.</UnstyledSidenote> Let's take a look:
|
||||
|
||||
```css
|
||||
.sidenote {
|
||||
float: right;
|
||||
--width: min(
|
||||
14rem,
|
||||
calc( (100vw - var(--content-width) ) / 2 - 2rem )
|
||||
);
|
||||
width: var(--width);
|
||||
margin-right: calc(0rem - var(--width) - 2rem);
|
||||
}
|
||||
```
|
||||
|
||||
To calculate the width, we take the full viewport (`100vw`) and subtract the width of the main column (`var(--content-width)`). This gives us the combined width of both gutters, but since we only want the width of a single gutter we divide by 2. Then we subtract a further `2rem` so that our width is a little less than the full width of ther gutter, to give us some breathing room.
|
||||
|
||||
For the margin, we just take the value we calculated for the width and subtract it from 0 (to make it negative), then subtract a further 2rem to pull the sidenote out by that much more to give us breathing room.
|
||||
@ -8,13 +8,31 @@ draft: true
|
||||
import Sidenote from '$lib/Sidenote.svelte';
|
||||
</script>
|
||||
|
||||
Clarke's Law<Sidenote>Actually it's Clarke's Third Law, there are two others. Shows what I know. I will, however, continue to refer to it as "Clarke's Law" for the time being, since it's easier to type and I'm lazy.</Sidenote>, i.e. "Sufficiently advanced technology is indistinguishable from magic," is a well-known dictum in fiction. I've never had a significant reason to disagree with it in the past, but recently I read _Elder Race_ by Adrian Tchaikovsky and it got me thinking. The upshot is, I've come to the conclusion that (within the world of fiction, of course) sufficiently advanced technology actually _is_ distinguishable from magic, in fact almost always so. Moreover, the distinction is really quite simple: Does the "magic" operate through _extrinsic_ or _intrinsic_ means? Does the magic-user act by operating a device that acts on the natural world, or does he simply exert his will and the world conforms to his desire? If the former, it's probably technology, and if the latter, it's probably magic.
|
||||
Arthur C. Clarke is famous for many things, among them being his dictum that "Sufficiently advanced technology is indistinguishable from magic."<Sidenote>Which I had always thought of as "Clarke's Law", I looked it up when I went to write this and discovered that it's actually Clarke's _Third_ Law. Apparently he has two others. I don't know that I've ever run into them, though. Maybe he should have led with this one?</Sidenote> I'm often happy to take issue with Clarke's opinions, so today I want to put this one on the chopping block.
|
||||
|
||||
Before we get started, a note: the pedantic may argue that by "indistinguishable" he simply means "from the outside," as it were. That is, if you're an untrained citizen of the Galactic Empire or whatever, your knowledge of how a hyperdrive works is so far removed from the reality that it might as well be magic - certainly you couldn't build a new one from scratch, or even fix a broken one. That's as may be, but it's not the interpretation that I want to address here, for two reasons: 1) it's boring, and 2) I don't think that's what Clarke actually meant when he coined the phrase.
|
||||
|
||||
In fact, I think Clarke was thinking more along these lines: Advanced technology (by which I mean, technology that is more advanced than anything we have today) and magic both postulate that the impossible is possible. In the case of non-fundamental advances you can kind of see how this might come about, like an economically feasible Mach 3 passenger aircraft, for instance. But as technology gets further and further from the current state of the art, and encompasses more and more that's not just "we don't know if it's possible" but "we actually think it's impossible" the divorce from reality becomes so complete that it's _just as profound_ as a wizard who levitates and summons fireballs out of the air by sheer power of will.<Sidenote>It's also interesting to note that Clarke wrote primarily _near-future_ sci-fi - his most famous work is set _twenty years ago_, for goodness sake! But perhaps that has something to do with his apparent disdain for grander flights of sci-fi fancy.</Sidenote>
|
||||
|
||||
That's what I'm disagreeing with. In particular I take issue with the term "indistinguishable," because it implies there is _no basis_ by which the technology in question can be distinguished from magic. I think, however, that there usually _is_ such a distinction, and in fact it's quite easy to make. And it doesn't have anything to do with _how_ advanced the technology is, which may be why it didn't occur to Clarke, but this is my blog so I get to be as nitpicky as I like.<Sidenote>Yes, I know that I just implied above that I'm above pedantry, so what? Still my blog, and I don't have to be consistent unless I want to.</Sidenote>
|
||||
|
||||
To me, the distinction between technology and magic has always hinged more on the _mechanism_ of the thing than its degree of connection with reality. To wit: Does the [magic, technology] constitute an _intrinsic_ or _extrinsic_ means for someone to influence the world around them? If intrinsic, then it's magic. If extrinsic, then it's technology.
|
||||
|
||||
When I say "intrinsic" and "extrinsic" I'm mostly thinking of the origin of the power. An intrinsic power is something natural that the user is born with, while an extrinsic power is conferred by artifice - usually some sort of constructed device. There are definitely edge cases that blur the line between these distinctions, but they're mostly pretty clear when you're looking at individual examples.
|
||||
|
||||
For example, a wizard who moves objects by focusing his mind and exerting his will on the universe is using magic. A starship captain who moves objects using a tractor beam is using technology, because the tractor beam constitutes an _extrinsic_ means of interacting with the world. The only intrinsic tools that the starship captain uses are (presumably) hands to manipulate controls of some sort.<Sidenote>There could, of course, be some kind of computer-mediated direct-brain interface, but that definitely still counts as technology since, again, the computer is merely reacting to _normal human actions_, in this case thoughts.</Sidenote>
|
||||
|
||||
Interestingly, by this definition there's no need for magic to be restricted to a certain subset of the population. You could easily imagine a world where _everyone_ has the power of telekinesis or something, or even one of many powers, and in fact it would be quite interesting to explore the ramifications of such a world. Mostly, however, stories that portray magic as we've defined it portray it as something available to only a few.
|
||||
|
||||
## Original form
|
||||
|
||||
Clarke's Law<Sidenote>Actually it's Clarke's Third Law, there are two others. Shows what I know. I will, however, continue to refer to it as "Clarke's Law" for the time being, since it's easier to type and I'm lazy.</Sidenote>, i.e. "Sufficiently advanced technology is indistinguishable from magic," is a well-known dictum in science fiction. I've never had a significant reason to disagree with it in the past, but recently I read _Elder Race_ by Adrian Tchaikovsky and it got me thinking. The upshot is, I've come to the conclusion that (within the world of fiction, of course) sufficiently advanced technology actually _is_ distinguishable from magic, in fact almost always so. Moreover, the distinction is really quite simple: Does the "magic" operate through _extrinsic_ or _intrinsic_ means? Does the magic-user act by operating a device that acts on the natural world, or does he simply exert his will and the world conforms to his desire? If the former, it's probably technology, and if the latter, it's probably magic.
|
||||
|
||||
Before I get started though, the book: _Elder Race_ is quite enjoyable, and not very long either, so you should definitely read it if you're into either sci-fi _or_ fantasy, because it manages to be both. In the interest of avoiding too many spoilers I won't go into too much detail, but the main conceit of the book is spoiled by the jacket blurb anyway, so I won't worry too much about that one. In brief: _Elder Race_ is an enjoyable and fairly in-depth exploration of Clarke's Law. It spends a lot of time considering not just the basic aspects (Look, flying machines! Must be magic!) but deeper questions, like: how would you even go about explaining technology to someone from an un-technological society?
|
||||
|
||||
Unsurprisingly, it comes away with more or less the conclusion that you can't really: the technologically unaware will continue to regard your flying machines as magical conveyances held aloft by arcane powers, your radio as deep wizardry that allows you to commune with distant spirits, and so on. You can try to explain it all you like, but if you say "science" your listener will hear "magic," and if you say "it's just an understanding of natural forces built up over generations" they will hear "it's just hidden knowledge of the secrets of the universe, handed down from the ancients." There is a communications barrier that is, according to this view, insurmountable without starting at the very beginning and working your way up.
|
||||
|
||||
Now, this may or may not be true, but I'd like to take issue with the more general formulation of Clarke's Law. I've always taken the "indistinguishable" bit to mean that _no one_ can distinguish the two, not just that _those unfamiliar with technology_ can distinguish. I don't think that's the case, though. I think that you _can_ distinguish between magic and technology, and that the distinction is trivial in most cases. The question you can usually ask, and often get a clear answer to, is: "Does the [magic/technology] operate by means of devices, or does it rely on internal powers of the user?" if the former, it's technology. If the latter, it's magic.
|
||||
Now, this may or may not be true, but I'd like to take issue with the more general formulation of Clarke's Law. I've always taken the "indistinguishable" bit to mean that _no one_ can distinguish the two, not just that _those unfamiliar with technology_ can make the distinction. I don't think that's the case, though. I think that you _can_ distinguish between magic and technology, and that the distinction is trivial at least in many cases. The question you can usually ask, and often get a clear answer to, is: "Does the [magic/technology] operate by means of devices, or does it rely on internal powers of the user?" if the former, it's technology. If the latter, it's magic.
|
||||
|
||||
Let's take some examples. On the magic side, think of some of the classic swords-and-sorcery canon: _Earthsea_, _Wheel of Time_<Sidenote>Much as I dislike it, it's undeniably genre-defining.</Sidenote>, _Prydain Chronicles_, _Chronicles of Amber_, _Belgariad_, and so on.<Sidenote>You might notice that I've skipped LOTR here: don't worry, it will show up later.</Sidenote> All of these have in common that magic is effected by a _direct act of will_. There is no mediating device or artifice, the magician simply exerts his will on the universe. There may be techniques involved, or limits to what the magic can accomplish, but there's fundamentally just some direct connection between the wizard's will and the natural world that other people don't have, and that's what makes him a wizard.
|
||||
|
||||
|
||||
165
src/routes/_posts/vue-vs-svelte.svx
Normal file
165
src/routes/_posts/vue-vs-svelte.svx
Normal file
@ -0,0 +1,165 @@
|
||||
---
|
||||
title: Thoughts on Vue vs Svelte
|
||||
description: They're more similar than they are different, but they say the most bitter enemies are those who have the fewest differences.
|
||||
date: 2023-06-29
|
||||
---
|
||||
<script>
|
||||
import Dropcap from '$lib/Dropcap.svelte';
|
||||
import Sidenote from '$lib/Sidenote.svelte';
|
||||
</script>
|
||||
|
||||
|
||||
<Dropcap word="Recently">I've had a chance to get to know Vue a bit. Since my frontend framework of choice has previously been Svelte (this blog is built in Svelte, for instance) I was naturally interested in how they compared.</Dropcap>
|
||||
|
||||
Of course, this is only possible because Vue and Svelte are really much more similar than they are different. Even among frontend frameworks, they share a lot of the same basic ideas and high-level concepts, which means that we get to dive right into the nitpicky details and have fun debating `bind:attr={value}` versus `:attr="value"`. In the meantime, a lot of the building blocks are basically the same or at least have equivalents, such as:
|
||||
* Single-file components with separate sections for markup, style, and logic
|
||||
* Automatically reactive data bindings
|
||||
* Two-way data binding (a point of almost religious contention in certain circles)
|
||||
* An "HTML-first" mindset, as compared to the "Javascript-first" mindset found in React and its ilk. The best way I can describe this is by saying that in Vue and Svelte, the template<Sidenote>Or single-file component, anyway.</Sidenote> embeds the logic, whereas in React, the logic embeds the template.
|
||||
|
||||
I should also note that everything I say about Vue applies to the Options API unless otherwise noted, because that's all I've used. I've only seen examples of the Composition API (which looks even more like Svelte, to my eyes), I've never used it myself.
|
||||
|
||||
With that said, there are plenty of differences between the two, and naturally I find myself in possession of immediate and vehement Preferences.<Sidenote>I should also clarify that practically everything in this post is just that: a preference. While I obviously plan to explain my preferences and think it would be reasonable for other people to do the same, it's undeniably true that preferences can vary, and in a lot of cases are basically arbitrary. So if you find yourself disagreeing with all or most of what I say, consider it an opportunity to peer into the mindset of The Other Side.</Sidenote> Starting with:
|
||||
|
||||
## Template Syntax
|
||||
|
||||
Overall I think I favor Vue here. Both Vue and Svelte expect you to write most of your code in "single-file components", which are collections of markup, style, and logic<Sidenote>Much like a traditional HTML page.</Sidenote> that work together to describe the appearance and behavior of a component. But naturally, they do it slightly differently. Vue adds custom vue-specific attributes directly to the HTML elements, such as:
|
||||
```markup
|
||||
<div v-if="items.length">
|
||||
<p>Please choose an item.</p>
|
||||
<ul>
|
||||
<li v-for="item in items">{{ item.name }}</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div v-else>
|
||||
<p>There are no items available.</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
While Svelte takes the more common approach of wrapping bits of markup in its own templating constructs:
|
||||
|
||||
```svelte
|
||||
{#if items.length}
|
||||
<div>
|
||||
<p>Please choose an item</p>
|
||||
<ul>
|
||||
{#each items as item}
|
||||
<li>{item.name}</li>
|
||||
</ul>
|
||||
</div>
|
||||
{:else}
|
||||
<div>
|
||||
<p>There are no items available.</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
While Vue's approach may be a tad unorthodox, I find that I actually prefer it in practice. It has the killer feature that, by embedding itself inside the existing HTML, it doesn't mess with my indentation - which is something that has always bugged me about Mustache, Liquid, Jinja, etc.<Sidenote>Maybe it's silly of me to spend time worrying<Sidenote>Nested<Sidenote>Doubly-nested sidenote!</Sidenote> sidenote!</Sidenote> about something so trivial,<Sidenote>Second nested sidenote.</Sidenote> but hey, this whole post is one big bikeshed anyway.</Sidenote>
|
||||
|
||||
Additionally (and Vue cites this as the primary advantage of its style, I think) the fact that Vue's custom attributes are all syntactically valid HTML means that you can actually embed Vue templates directly into your page source. Then, when you mount your app to an element containing Vue code, it will automatically figure out what to do with it.<Sidenote>AlpineJS also works this way, but this is the *only* way that it works - it doesn't have an equivalent for Vue's full-fat "app mode" as it were.</Sidenote> This strikes me as a fantastic way to ease the transition between "oh I just need a tiny bit of interactivity on this page, so I'll just sprinkle in some inline components" and "whoops it got kind of complex, guess I have to factor this out into its own app with a build step and all now."
|
||||
|
||||
Detractors of this approach might point out that it's harder to spot things like `v-if` and `v-for` when they're hanging out inside of existing HTML tags, but that seems like a problem that's easily solved with a bit of syntax highlighting.<Sidenote>I'm being unfair here. It's more than just a lack of syntax highlighting, it's a reversal of the typical order in which people are used to reading code, where the control flow is indicated before whatever it's controlling. So you end up with a sort of [garden-path-like](https://xkcd.com/2793/) problem where you have to mentally double back and re-read things in a different light. I still don't think it's a huge issue, though, because in every case I'm come across the control flow bits (so `v-if`, `v-for`, and `v-show`) are specified _immediately_ after the opening tag. So you don't really have to double back by an appreciable amount, and it doesn't take too long to get used to it.</Sidenote>
|
||||
|
||||
Continuing the exploration of template syntax, Vue has some cute shorthands for its most commonly-used directives, including `:` for `v-bind` and `@` for `v-on`. Svelte doesn't really have an equivalent for this, although it does allow you to shorten `attr={attr}` to `{attr}`, which can be convenient. Which might as well bring us to:
|
||||
|
||||
## Data Binding
|
||||
|
||||
I give this one to Svelte overall, although Vue has a few nice conveniences going for it.
|
||||
|
||||
Something that threw me a tiny bit when I first dug into Vue was that you need to use `v-bind` on any attribute that you want to have a dynamic value. So for instance, if you have a data property called `isDisabled` on your button component, you would do `<button v-bind:disabled="isDisabled">` (or the shorter `<button :disabled="isDisabled">`).
|
||||
|
||||
The reason this threw me is that Svelte makes the very intuitive decision that since we already have syntax for interpolating variables into the text contents of our markup, we can just reuse the same syntax for attributes. So the above would become `<button disabled={isDisabled}>`, which I find a lot more straightforward.<Sidenote>If your interpolation consists of a single expression you can even leave off the quote marks (as I did here), which is pleasant since you already have `{}` to act as visual delimiters.</Sidenote> I also find it simpler in cases where you want to compose a dynamic value out of some fixed and some variable parts, e.g. `<button title="Save {{itemsCount}} items">` vs. `<button :title="`Save ${itemsCount} items`">`.
|
||||
|
||||
Two-way bindings in Svelte are similarly straightforward, for example: `<input type="checkbox" bind:checked={isChecked}>` In Vue this would be `<input type="checkbox" v-model="isChecked">`, which when you first see it doesn't exactly scream that the value of `isChecked` is going to apply to the `checked` property of the checkbox. On the other hand, this does give Vue the flexibility of doing special things for e.g. the values of `<select>` elements: `<select v-model="selectedOption">` is doing quite a bit of work, since it has to interact with not only the `<select>` but the child `<option>`s as well. Svelte just throws in the towel here and tells you to do `<select bind:value={selectedOption}>`, which looks great until you realize that `value` isn't technically a valid attribute for a `<select>`. So Svelte's vaunted principle of "using the platform" does get a _little_ bent out of shape here.
|
||||
|
||||
Oh, and two-way bindings in Vue get _really_ hairy if it's another Vue component whose attribute you want to bind, rather than a builtin form input. Vue enforces that props be immutable from the inside, i.e. a component isn't supposed to mutate its own props. So from the parent component it doesn't look too bad:
|
||||
```markup
|
||||
<ChildComponent v-model="childValue" />`
|
||||
```
|
||||
But _inside_ the child component:
|
||||
```js
|
||||
export default {
|
||||
props: ['modelValue'],
|
||||
emits: ['update:modelValue'],
|
||||
methods: {
|
||||
doThing() {
|
||||
this.$emit('update:modelValue', newValue)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In Svelte, you just `bind:` on a prop of a child component, and then if the child updates the prop it will be reflected in the parent as well. I don't think there's any denying that's a lot simpler.<Sidenote>I think this is where the "two-way data binding" holy wars start to get involved, but I actually really like the way Svelte does things here. I think most of the furor about two-way data binding refers to bindings that are _implicitly_ two-way, i.e. the child can mutate state that the parent didn't expect or intend it to. In Svelte's case, though, this is only possible if you explicitly pass the state with `bind:`, which signifies that you _do_ want this state to be mutated by the child and that you have made provisions therefor. </Sidenote>
|
||||
|
||||
Vue does have some lovely convenience features for common cases, though. One of my favorites is binding an object to the `class` of an HTML element, for example: `<button :class="{btn: true, primary: false}">` Which doesn't look too useful on its own, but move that object into a data property and you can now toggle classes on the element extremely easily by just setting properties on the object. The closest Svelte comes is `<button class:btn={isBtn} class:primary={isPrimary}>`, which is a lot more verbose. Vue also lets you bind an array to `class` and the elements of the array will be treated as individual class names, which can be convenient in some cases if you have a big list of classes and you're toggling them all as a set.
|
||||
|
||||
The other area where I vastly prefer Vue's approach over Svelte's is in event handlers. Svelte requires that every event handler be a function, either named or inline, so with simple handlers you end up with a lot of `<button on:click={() => counter += 1}` situations. Vue takes the much more reasonable approach of letting you specify a plain statement as your event handler, e.g. `<button @click="counter += 1">`. For whatever reason this has always particularly annoyed me about Svelte, so Vue's take is very refreshing.
|
||||
|
||||
Admittedly, the Svelte approach does lead more gracefully into more complex scenarios where you need to capture the actual JS event: it just gets passed to the function. Vue kind of capitulates on consistency here and _also_ lets you pass the name of a function to an event handler, which is then called with the event as an argument. _Oooor_, you can reference the event via the special variable `$event`, which is convenient but feels a bit shoehorned in.
|
||||
|
||||
I'm ragging on Vue for its inconsistency here but I should note that I still do prefer the Vue approach, warts and all. "A foolish consistency is the hobgoblin of small minds," after all, and Vue's syntax is just so _convenient_. Besides, it optimizes for the 95% of the time I don't care about capturing the event, because realistically when am I going to want to do that? In both Vue and Svelte, all the traditional use cases for capturing an event are solved in other ways:
|
||||
* You don't usually need `event.target`, because you can just give yourself a handle to the element directly (via `ref` in Vue, `bind:this=` in Svelte)
|
||||
* You don't need to use it to get the value of an input (common with events like `change`), because you're just going to use a two-way binding for that
|
||||
* In Vue, you don't even need it to check for modifier keys, because Vue gives you special syntax for this like `@event.shift`. (Svelte doesn't have an equivalent for this, so advantage Vue here again.)
|
||||
|
||||
You really only need to access the event when you're doing something more exotic, e.g. handling a bubbling event on a parent element and you need to check which child was actually the target, which does happen but again not the _majority_ of the time.
|
||||
|
||||
## Declaring Reactive Values
|
||||
|
||||
In Vue, reactive values (by which I mean "values that can automatically trigger a DOM update when they change") are either passed in as `props`, or declared in `data`. Or derived from either of those sources in `computed`. Then you reference them, either directly in your template or as properties of `this` in your logic. Which works fine, more or less, although you can run into problems if you're doing something fancy with nested objects or functions that get their own `this` scope.<Sidenote>It's worth noting that the Composition API avoids this, at the cost of having to call `ref()` on everything and reference `reactiveVar.value` rather than `reactiveVar` by itself.</Sidenote> The split between how you access something from the template and how you access it from logic was a touch surprising to me at first, though.
|
||||
|
||||
In Svelte, variables are just variables, you reference them the same way from everywhere, and if they need to be reactive it (mostly) just happens automagically. Svelte has a lot more freedom here because it's a compiler, rather than a library, so it can easily insert calls to its special `$$invalidate()` function after any update to a value that needs to be reactive.
|
||||
|
||||
Both frameworks allow you to either derive reactive values from other values, or just execute arbitrary code in response to data updates. In Vue these are two different concepts - derived reactive values are declared in `computed`, and reactive statements via the `watch` option. In Svelte they're just the same thing: Prefix any statement with `$:` (which is actually valid JS, as it turns out) and it will automatically be re-run any time one of the reactive values that it references gets updated. So both of the following:
|
||||
```js
|
||||
$: let fullname = `${firstname} ${lastname}`;
|
||||
$: console.log(firstname, lastname);
|
||||
```
|
||||
would re-run any time `firstname` or `lastname` is updated, assuming those are reactive values to begin with.
|
||||
|
||||
Overall I tend to prefer the simplicity of Svelte's approach to reactivity, although I do find the `$:` syntax a little weird. It may be valid JS, but it's not valid JS that anybody actually _uses_. Moreover its official meaning doesn't have anything to do with what Svelte is using it for, so the fact that iT's vAliD jAVaSCriPt doesn't really do much for me. I think Vue's `computed` and `watch` options are much more obvious, if only from how they're named.
|
||||
|
||||
That said, I don't have any better ideas for marking reactive statements in Svelte, especially given that sometimes you _want_ a statement to ignore updates even if it does reference a value that might be updated. So maybe this is just one of those compromises you have to make.
|
||||
|
||||
## Code Structure
|
||||
|
||||
I go back and forth on this one, but I _think_ I have a slight preference for Svelte (at least, at the moment.) The major difference is that Vue<Sidenote>If you're using the Options API, at least.</Sidenote> enforces a lot more structure than Svelte: Data is in `props`/`data`/`computed`, logic is in `methods`, reactive stuff is in `watch`, etc. Svelte, by contrast, just lets you do basically whatever you want. It does require that you have only one `<script>` tag, so all your logic ends up being co-located, but that's pretty much it. Everything else is just a convention, like declaring props at the top of your script.
|
||||
|
||||
The advantage of Vue's approach is that it can make it easier to find things when you're jumping from template to logic: you see `someFunction(whatever)`, you know it's going to be under `methods`. With Svelte, `someFunction` could be defined anywhere in the script section.
|
||||
|
||||
On the other hand, this actually becomes a downside once your component gets a little bit complex. Separation of concerns is nice and all, but sometimes it just doesn't work very well to split a given component, and it ends up doing several unrelated or at least clearly distinct things. In Vue-land, the relevant bits of state, logic, etc. are all going to be scattered across `data`/`methods`/etc, meaning you can't really see "all the stuff that pertains to this one bit of functionality" in one place. It's also very clunky to split the logic for a single component across multiple JS files, which you might want to do as another way of managing the complexity of a large component. If you were to try, you'd end up with a big "skeleton" in your main component file, e.g.
|
||||
|
||||
```js
|
||||
export default {
|
||||
import {doThing, mungeData} from './otherfile.js';
|
||||
|
||||
// ...
|
||||
computed: {
|
||||
mungeData,
|
||||
// ...
|
||||
}
|
||||
methods: {
|
||||
doThing,
|
||||
// ...
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
which doesn't seem very pleasant.
|
||||
|
||||
As a matter of fact, this was one of the primary [motivations](https://web.archive.org/web/20201109010309/https://composition-api.vuejs.org/#logic-reuse-code-organization) for the introduction of the Composition API in the first place.<Sidenote>Archive link, since that url now redirects to the [current Composition API FAQ](https://vuejs.org/guide/extras/composition-api-faq.html).</Sidenote> Unfortunately it also includes the downside that you have to call `ref()` on all your reactive values, and reference them by their `.value` property rather than just using the main variable. It's funny that this bothers me as much as it does, given that `this.someData` is hardly any more concise than `someData.value`, but there's no accounting for taste, I guess. Using `this` just feels more natural to me, although what feels most natural is Svelte's approach where you don't have to adjust how you reference reactive values at all.
|
||||
|
||||
Also, as long as we're harping on minor annoyances: For some reason I cannot for the life of me remember to put commas after all my function definitions in `computed`, `methods` etc. in my Vue components. It's such a tiny thing, but it's repeatedly bitten me because my workflow involves Vue automatically rebuilding my app every time I save the file, and I'm not always watching the console output because my screen real estate is in use elsewhere.<Sidenote>E.g. text editor on one screen with two columns of text, web page on one half of the other screen and dev tools on the other half. Maybe I need a third monitor?</Sidenote> So I end up forgetting a comma, the rebuild fails but I don't notice, and then I spend five minutes trying to figure out why my change isn't taking effect before I think to check for syntax errors.
|
||||
|
||||
It would be remiss of me, however, not to point out that one thing the Vue Options API enables<Sidenote>Kind of its initial _raison d'être_, from what I understand.</Sidenote> which is completely impossible with Svelte is at-runtime or "inline" components, where you just stick a blob of JS onto your page that defines a Vue component and where it should go, and Vue does the rest on page load. Svelte can't do this because it's a compiler, so naturally it has to compile your components into a usable form. This has many advantages, but sometimes you don't want to or even _can't_ add a build step, and in those cases Vue can really shine.
|
||||
|
||||
## Miscellany
|
||||
|
||||
### Performance
|
||||
|
||||
Performance isn't really a major concern for me when it comes to JS frameworks, since I don't tend to build the kind of extremely-complex apps where the overhead of the framework starts to make a difference. For what it's worth, though, the [Big Benchmark List](https://krausest.github.io/js-framework-benchmark/current.html) has Vue slightly ahead of Svelte when it comes to speed.<Sidenote>Although [recent rumors](https://twitter.com/Rich_Harris/status/1688581184018583558) put the next major version of Svelte _very_ close to that of un-framework'd vanilla JS, so this might change in the future.</Sidenote> I don't know how representative this benchmark is of a real-world workload.
|
||||
|
||||
As far as bundle size goes, it's highly dependent on how many components you're shipping - since Svelte compiles everything down to standalone JS and there's no shared framework, the minimum functional bundle can be quite small indeed. The flipside is that it grows faster with each component than Vue, again because there's no shared framework to rely on. So a Svelte app with 10 components will probably be a lot smaller than the equivalent Vue app, but scale that up to 1000 components and the advantage will most likely have flipped.
|
||||
|
||||
### Ecosystem
|
||||
|
||||
Vue has been around longer than Svelte, so it definitely has the advantage here. That said, Svelte has been growing pretty rapidly in recent years and there is a pretty decent ecosystem these days. This blog, for instance, uses [SvelteKit](https://kit.svelte.dev) and [mdsvex](https://mdsvex.pngwn.io/). But there are definitely gaps, e.g. I wasn't able to find an RSS feed generator when I went looking.<Sidenote>Arguably this is a lack in the SvelteKit ecosystem rather than the Svelte ecosystem, but I think it's fair to lump it together. SvelteKit is dependent on Svelte, so naturally it inherits all of Svelte's immaturity issues plus more of its own.</Sidenote> If I'd been using Vue/Nuxt it would have been available as a [first-party integration](https://content.nuxtjs.org/v1/community/integrations). All in all I'd say if a robust ecosystem is important to you then Vue is probably the better choice at this point.
|
||||
BIN
static/Baskerville-Regular.woff2
Normal file
BIN
static/Baskerville-Regular.woff2
Normal file
Binary file not shown.
@ -7,12 +7,28 @@
|
||||
font-display: block;
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: 'Baskerville';
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
src: url(/Baskerville-Regular.woff2) format('woff2');
|
||||
font-display: block;
|
||||
}
|
||||
|
||||
:root {
|
||||
--content-size: 1.25rem;
|
||||
--content-line-height: 1.3;
|
||||
--content-color: #1e1e1e;
|
||||
--content-color-faded: #555;
|
||||
--accent-color: #8c0606;
|
||||
}
|
||||
|
||||
html {
|
||||
font-family: 'Tajawal', sans-serif;
|
||||
font-size: 20px;
|
||||
line-height: 1.3;
|
||||
font-size: var(--content-size);
|
||||
line-height: var(--content-line-height);
|
||||
letter-spacing: -0.005em;
|
||||
color: #1e1e1e;
|
||||
color: var(--content-color);
|
||||
}
|
||||
|
||||
body {
|
||||
|
||||
281
tmp/crane.svg
Normal file
281
tmp/crane.svg
Normal file
@ -0,0 +1,281 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
<!-- Crane image created by macrovector on Freepik: https://www.freepik.com/free-vector/construction-icons-set_1537228.htm#query=crane&position=3&from_view=keyword -->
|
||||
|
||||
<svg
|
||||
width="28.305676mm"
|
||||
height="28.174238mm"
|
||||
viewBox="0 0 28.305676 28.174238"
|
||||
version="1.1"
|
||||
id="svg1392"
|
||||
inkscape:version="1.2 (dc2aedaf03, 2022-05-15)"
|
||||
sodipodi:docname="crane.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview1394"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#000000"
|
||||
borderopacity="0.25"
|
||||
inkscape:showpageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="0"
|
||||
inkscape:deskcolor="#d1d1d1"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
inkscape:zoom="2.1089995"
|
||||
inkscape:cx="-5.6899017"
|
||||
inkscape:cy="78.710306"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1017"
|
||||
inkscape:window-x="-8"
|
||||
inkscape:window-y="-8"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="layer1" />
|
||||
<defs
|
||||
id="defs1389" />
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-139.84716,-103.71933)">
|
||||
<path
|
||||
d="m 166.79605,124.82179 h 0.18627 v -20.83188 h -0.18627 v 20.83188"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path324" />
|
||||
<path
|
||||
d="m 166.25101,125.97184 h 1.27635 v -0.51893 c 0,-0.1323 -0.10724,-0.23919 -0.23918,-0.23919 h -0.79763 c -0.13229,0 -0.23954,0.10689 -0.23954,0.23919 v 0.51893"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path326" />
|
||||
<path
|
||||
d="m 166.6934,125.21372 h 0.39193 v -0.64981 h -0.39193 v 0.64981"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path328" />
|
||||
<path
|
||||
d="m 165.62554,126.85626 c 0,0.69814 0.56585,1.26365 1.26365,1.26365 0.69779,0 1.26365,-0.56551 1.26365,-1.26365 0,-0.6978 -0.56586,-1.26365 -1.26365,-1.26365 -0.6978,0 -1.26365,0.56585 -1.26365,1.26365"
|
||||
style="fill:#f9a727;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path330" />
|
||||
<path
|
||||
d="m 143.76637,124.8673 19.84057,-20.49675 -0.0935,-0.0903 -19.84093,20.49639 0.0938,0.0907"
|
||||
style="fill:#100f0d;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path332" />
|
||||
<path
|
||||
d="m 149.82885,128.1506 2.90478,-6.56802 10.82675,-17.25718 1.80869,1.13488 -10.81899,17.2466 -4.61751,5.50863 z m 13.67261,-24.08167 -10.93188,17.42652 -2.97638,6.72711 0.37782,0.23707 4.72899,-5.64338 10.92553,-17.41488 -2.12408,-1.33244"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path334" />
|
||||
<path
|
||||
d="m 154.67073,122.68783 -0.0988,0.1577 -1.96638,-1.23367 0.0988,-0.15769 1.96638,1.23366"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path336" />
|
||||
<path
|
||||
d="m 154.712,122.74604 -0.18132,0.0413 -0.71791,-3.13443 0.18168,-0.0416 0.71755,3.13478"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path338" />
|
||||
<path
|
||||
d="m 155.85042,120.93135 -3.13443,0.71755 -0.0416,-0.18132 3.13478,-0.71791 0.0413,0.18168"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path340" />
|
||||
<path
|
||||
d="m 155.87935,120.76167 -0.0991,0.15769 -1.96639,-1.23366 0.0991,-0.1577 1.96639,1.23367"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path342" />
|
||||
<path
|
||||
d="m 155.92062,120.81952 -0.18168,0.0416 -0.71755,-3.13443 0.18133,-0.0416 0.7179,3.13443"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path344" />
|
||||
<path
|
||||
d="m 157.05903,119.00483 -3.13478,0.71791 -0.0413,-0.18133 3.13443,-0.7179 0.0416,0.18132"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path346" />
|
||||
<path
|
||||
d="m 157.08761,118.8355 -0.0988,0.15769 -1.96638,-1.23366 0.0988,-0.15769 1.96638,1.23366"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path348" />
|
||||
<path
|
||||
d="m 157.12888,118.89336 -0.18132,0.0416 -0.71791,-3.13478 0.18168,-0.0413 0.71755,3.13443"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path350" />
|
||||
<path
|
||||
d="m 158.2673,117.07867 -3.13443,0.7179 -0.0416,-0.18168 3.13478,-0.71755 0.0413,0.18133"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path352" />
|
||||
<path
|
||||
d="m 158.29623,116.90898 -0.0991,0.15769 -1.96639,-1.23331 0.0991,-0.15804 1.96639,1.23366"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path354" />
|
||||
<path
|
||||
d="m 158.3375,116.96719 -0.18168,0.0416 -0.71755,-3.13479 0.18133,-0.0413 0.7179,3.13443"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path356" />
|
||||
<path
|
||||
d="m 159.47592,115.1525 -3.13479,0.7179 -0.0413,-0.18168 3.13443,-0.71755 0.0416,0.18133"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path358" />
|
||||
<path
|
||||
d="m 159.50449,114.98282 -0.0988,0.15804 -1.96638,-1.23366 0.0988,-0.15805 1.96638,1.23367"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path360" />
|
||||
<path
|
||||
d="m 159.54577,115.04102 -0.18133,0.0416 -0.71791,-3.13478 0.18169,-0.0413 0.71755,3.13443"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path362" />
|
||||
<path
|
||||
d="m 160.68418,113.22633 -3.13443,0.71791 -0.0416,-0.18168 3.13478,-0.71755 0.0413,0.18132"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path364" />
|
||||
<path
|
||||
d="m 160.71311,113.05665 -0.0991,0.15769 -1.96639,-1.23331 0.0991,-0.15805 1.96639,1.23367"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path366" />
|
||||
<path
|
||||
d="m 160.75438,113.11486 -0.18168,0.0416 -0.7179,-3.13478 0.18168,-0.0413 0.7179,3.13443"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path368" />
|
||||
<path
|
||||
d="m 161.8928,111.30017 -3.13479,0.7179 -0.0413,-0.18168 3.13443,-0.71755 0.0416,0.18133"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path370" />
|
||||
<path
|
||||
d="m 161.92137,111.13048 -0.0991,0.15805 -1.96603,-1.23367 0.0988,-0.15804 1.96638,1.23366"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path372" />
|
||||
<path
|
||||
d="m 161.96265,111.18869 -0.18133,0.0416 -0.71791,-3.13479 0.18169,-0.0416 0.71755,3.13478"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path374" />
|
||||
<path
|
||||
d="m 163.10106,109.374 -3.13443,0.7179 -0.0416,-0.18168 3.13478,-0.7179 0.0413,0.18168"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path376" />
|
||||
<path
|
||||
d="m 163.12999,109.20432 -0.0991,0.15769 -1.96639,-1.23367 0.0991,-0.15769 1.96639,1.23367"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path378" />
|
||||
<path
|
||||
d="m 163.17126,109.26252 -0.18168,0.0413 -0.71755,-3.13443 0.18133,-0.0416 0.7179,3.13478"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path380" />
|
||||
<path
|
||||
d="m 164.30968,107.44783 -3.13479,0.71755 -0.0413,-0.18132 3.13443,-0.71791 0.0416,0.18168"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path382" />
|
||||
<path
|
||||
d="m 164.33825,107.27815 -0.0988,0.15769 -1.96638,-1.23366 0.0988,-0.1577 1.96638,1.23367"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path384" />
|
||||
<path
|
||||
d="m 164.37953,107.33636 -0.18133,0.0413 -0.7179,-3.13443 0.18168,-0.0416 0.71755,3.13479"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path386" />
|
||||
<path
|
||||
d="m 165.51794,105.52167 -3.13443,0.71755 -0.0416,-0.18133 3.13443,-0.7179 0.0416,0.18168"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path388" />
|
||||
<path
|
||||
d="m 153.38944,124.32366 -0.18133,0.0416 -0.64382,-2.81128 0.18133,-0.0416 0.64382,2.81128"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path390" />
|
||||
<path
|
||||
d="m 153.34817,124.26581 -0.0988,0.15769 -1.48908,-0.93415 0.0991,-0.1577 1.48873,0.93416"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path392" />
|
||||
<path
|
||||
d="m 154.64215,122.85752 -2.81163,0.64382 -0.0413,-0.18168 2.81129,-0.64382 0.0416,0.18168"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path394" />
|
||||
<path
|
||||
d="m 152.06476,125.91399 -0.18556,0.012 -0.16228,-2.50931 0.18591,-0.0123 0.16193,2.50966"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path396" />
|
||||
<path
|
||||
d="m 152.02137,125.84096 -0.0988,0.15769 -0.98954,-0.62053 0.0991,-0.15769 0.98919,0.62053"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path398" />
|
||||
<path
|
||||
d="m 153.33405,124.43056 -2.31598,0.95461 -0.0709,-0.17215 2.31599,-0.95462 0.0709,0.17216"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path400" />
|
||||
<path
|
||||
d="m 167.06769,103.88196 c -0.20602,-0.12912 -0.44944,-0.1838 -0.69074,-0.15523 l -2.87549,0.3422 -0.0935,0.16122 2.09691,1.31551 1.58573,-1.32151 c 0.0522,-0.0434 0.0801,-0.10936 0.0759,-0.17709 -0.005,-0.0677 -0.0416,-0.12912 -0.0988,-0.1651"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path402" />
|
||||
<path
|
||||
d="m 163.77733,104.24179 2.71922,-0.33902 c 0.13687,-0.0169 0.27551,0.0138 0.39264,0.0871 l 0.0395,0.0247 c 0.0162,0.0102 0.0265,0.0275 0.0279,0.0466 0.001,0.019 -0.007,0.0378 -0.0215,0.0501 l -1.44533,1.20474 -1.71239,-1.07421"
|
||||
style="fill:#f9a727;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path404" />
|
||||
<path
|
||||
d="m 145.63997,128.61168 h 3.81459 v 0.62547 h -3.81459 v -0.62547"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path406" />
|
||||
<path
|
||||
d="m 140.21425,126.26888 c 0.0783,-0.35489 0.34149,-0.63994 0.68897,-0.74683 l 6.68832,-2.05246 -0.3549,5.14209 h -6.77756 c -0.18556,0 -0.3609,-0.084 -0.47696,-0.2286 -0.11606,-0.14429 -0.16051,-0.33373 -0.12065,-0.5147 l 0.35278,-1.5995"
|
||||
style="fill:#f9a727;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path408" />
|
||||
<path
|
||||
d="m 151.90037,131.89357 c 0.75917,0 1.37689,-0.61771 1.37689,-1.37724 0,-0.75918 -0.61772,-1.3769 -1.37689,-1.3769 -0.0243,-0.002 -3.12667,-0.22013 -4.15961,-0.22013 -1.03293,0 -4.13526,0.21802 -4.1663,0.22049 h -7.1e-4 c -0.75212,0 -1.36948,0.61736 -1.36948,1.37654 0,0.75953 0.61771,1.37724 1.37689,1.37724 h 8.31921"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path410" />
|
||||
<path
|
||||
d="m 143.58116,131.69778 c -0.65158,0 -1.18145,-0.52987 -1.18145,-1.18145 0,-0.65123 0.52669,-1.1811 1.17475,-1.1811 l 0.0141,-7.1e-4 c 0.03,-0.002 3.12667,-0.21943 4.15219,-0.21943 1.03082,0 4.11551,0.21696 4.14338,0.21908 l 0.008,7e-4 h 0.008 c 0.65158,0 1.18145,0.53023 1.18145,1.18146 0,0.65158 -0.52987,1.18145 -1.18145,1.18145 h -8.31921"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path412" />
|
||||
<path
|
||||
d="m 150.71891,130.51633 c 0,-0.65229 0.52882,-1.18146 1.18146,-1.18146 0.65263,0 1.18145,0.52917 1.18145,1.18146 0,0.65263 -0.52882,1.18145 -1.18145,1.18145 -0.65264,0 -1.18146,-0.52882 -1.18146,-1.18145"
|
||||
style="fill:#b8bbb6;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path414" />
|
||||
<path
|
||||
d="m 151.90037,131.19507 c 0.37429,0 0.67874,-0.30445 0.67874,-0.67874 0,-0.3743 -0.30445,-0.67875 -0.67874,-0.67875 -0.3743,0 -0.67875,0.30445 -0.67875,0.67875 0,0.37429 0.30445,0.67874 0.67875,0.67874"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path416" />
|
||||
<path
|
||||
d="m 145.53555,129.58146 c 0,-0.19014 0.15416,-0.34431 0.34431,-0.34431 0.19015,0 0.34431,0.15417 0.34431,0.34431 0,0.19015 -0.15416,0.34432 -0.34431,0.34432 -0.19015,0 -0.34431,-0.15417 -0.34431,-0.34432"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path418" />
|
||||
<path
|
||||
d="m 145.54331,131.35311 c 0,-0.19014 0.15416,-0.34431 0.34431,-0.34431 0.19015,0 0.34396,0.15417 0.34396,0.34431 0,0.19015 -0.15381,0.34432 -0.34396,0.34432 -0.19015,0 -0.34431,-0.15417 -0.34431,-0.34432"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path420" />
|
||||
<path
|
||||
d="m 149.25735,131.35311 c 0,-0.19014 0.15417,-0.34431 0.34432,-0.34431 0.19014,0 0.34431,0.15417 0.34431,0.34431 0,0.19015 -0.15417,0.34432 -0.34431,0.34432 -0.19015,0 -0.34432,-0.15417 -0.34432,-0.34432"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path422" />
|
||||
<path
|
||||
d="m 149.94598,129.58146 c 0,-0.19014 -0.15417,-0.34431 -0.34431,-0.34431 -0.19015,0 -0.34432,0.15417 -0.34432,0.34431 0,0.19015 0.15417,0.34432 0.34432,0.34432 0.19014,0 0.34431,-0.15417 0.34431,-0.34432"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path424" />
|
||||
<path
|
||||
d="m 144.76261,130.51633 c 0,-0.65229 -0.52881,-1.18146 -1.18145,-1.18146 -0.65264,0 -1.18145,0.52917 -1.18145,1.18146 0,0.65263 0.52881,1.18145 1.18145,1.18145 0.65264,0 1.18145,-0.52882 1.18145,-1.18145"
|
||||
style="fill:#b8bbb6;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path426" />
|
||||
<path
|
||||
d="m 143.58116,131.19507 c 0.3743,0 0.67874,-0.30445 0.67874,-0.67874 0,-0.3743 -0.30444,-0.67875 -0.67874,-0.67875 -0.3743,0 -0.67874,0.30445 -0.67874,0.67875 0,0.37429 0.30444,0.67874 0.67874,0.67874"
|
||||
style="fill:#252529;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path428" />
|
||||
<path
|
||||
d="m 143.43652,131.0088 h 8.60848 v -0.98495 h -8.60848 v 0.98495"
|
||||
style="fill:#f9a727;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path430" />
|
||||
<path
|
||||
d="m 147.23664,128.61168 h 3.55812 c 0.33761,0 0.61172,-0.27376 0.61172,-0.61172 v -0.73236 c 0,-0.72073 0.11465,-2.63737 -0.76377,-3.69429 -0.0744,-0.0896 -0.18485,-0.14147 -0.30092,-0.14147 h -2.60173 c -0.16158,0 -0.29704,0.12277 -0.31256,0.28364 l -0.19086,1.97943 v 2.91677"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path432" />
|
||||
<path
|
||||
d="m 150.76301,128.2649 c 0.16969,0 0.30797,-0.13794 0.30797,-0.30762 v -0.7165 c 0,-0.066 7.1e-4,-0.14217 0.002,-0.22648 0.01,-0.76165 0.03,-2.34562 -0.68192,-3.20216 -0.0173,-0.0212 -0.0437,-0.0335 -0.0709,-0.0335 h -2.54529 c -0.008,0 -0.0155,0.006 -0.0162,0.0148 l -0.16404,1.69827 c -0.0141,0.14464 0.025,0.28928 0.10971,0.40711 l 1.52153,2.11702 c 0.11219,0.15628 0.29316,0.24906 0.48578,0.24906 h 1.05163"
|
||||
style="fill:#4c5462;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path434" />
|
||||
<path
|
||||
d="m 141.47331,125.91928 h 2.36891 c 0.0723,0 0.13052,0.0924 0.13052,0.20637 h -0.13052 -0.13053 -2.10785 -0.13053 -0.13053 c 0,-0.11394 0.0582,-0.20637 0.13053,-0.20637"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path436" />
|
||||
<path
|
||||
d="m 141.47331,126.34649 h 2.36891 c 0.0723,0 0.13052,0.0924 0.13052,0.20673 h -0.13052 -0.13053 -2.10785 -0.13053 -0.13053 c 0,-0.1143 0.0582,-0.20673 0.13053,-0.20673"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path438" />
|
||||
<path
|
||||
d="m 141.47331,126.77406 h 2.36891 c 0.0723,0 0.13052,0.0924 0.13052,0.20637 h -0.13052 -0.13053 -2.10785 -0.13053 -0.13053 c 0,-0.11394 0.0582,-0.20637 0.13053,-0.20637"
|
||||
style="fill:#e4731a;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.0352778"
|
||||
id="path440" />
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 17 KiB |
99
tmp/index.html
Normal file
99
tmp/index.html
Normal file
@ -0,0 +1,99 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>Under Construction</title>
|
||||
|
||||
<style>
|
||||
body {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
main {
|
||||
background-color: #f2f2f2;
|
||||
padding: 1rem;
|
||||
height: 100vh;
|
||||
width: 100vw;
|
||||
justify-content: center;
|
||||
align-content: center;
|
||||
display: grid;
|
||||
}
|
||||
|
||||
#hero {
|
||||
padding: 4rem;
|
||||
background-color: white;
|
||||
border-radius: 100%;
|
||||
}
|
||||
|
||||
#hero img {
|
||||
width: 16rem;
|
||||
}
|
||||
|
||||
p {
|
||||
font-family: sans-serif;
|
||||
margin-bottom: 2rem;
|
||||
margin-top: 2rem;
|
||||
font-size: 1.5rem;
|
||||
text-align: center;
|
||||
}
|
||||
</style>
|
||||
|
||||
<script src="https://cdnjs.cloudflare.com/ajax/libs/luxon/3.0.4/luxon.min.js" integrity="sha512-XdACFfCJeqqfVU8mvvXReyFR130qjFvfv/PZOFGwVyBz0HC+57fNkSacMPF2Dyek5jqi4D7ykFrx/T7N6F2hwQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
|
||||
</head>
|
||||
<body>
|
||||
<main>
|
||||
<p style="font-size:2.5rem;color:#505050">Coming Soon™</p>
|
||||
<div id="hero">
|
||||
<img src="/crane.svg">
|
||||
</div>
|
||||
<p>
|
||||
Under Construction for <br />
|
||||
<span id="counter" style="margin-top:0.5rem"></span>
|
||||
</p>
|
||||
</main>
|
||||
</body>
|
||||
|
||||
<script>
|
||||
function u(v, unit) {
|
||||
if (v === 1) {
|
||||
return `${v} ${unit}`;
|
||||
}
|
||||
else {
|
||||
return `${v} ${unit}s`;
|
||||
}
|
||||
}
|
||||
|
||||
function f(n) {
|
||||
let s = n.toString();
|
||||
if (s.length == 1) {
|
||||
return '0' + s;
|
||||
}
|
||||
return s;
|
||||
}
|
||||
|
||||
const start = luxon.DateTime.fromSeconds(1634529923);
|
||||
function setDuration() {
|
||||
var diff = luxon.DateTime.now().diff(start);
|
||||
const years = Math.floor(diff.as('years'));
|
||||
diff = diff.minus(luxon.Duration.fromObject({years}));
|
||||
const months = Math.floor(diff.as('months'));
|
||||
diff = diff.minus(luxon.Duration.fromObject({months}));
|
||||
const days = Math.floor(diff.as('days'));
|
||||
diff = diff.minus(luxon.Duration.fromObject({days}));
|
||||
const hours = Math.floor(diff.as('hours'))
|
||||
diff = diff.minus(luxon.Duration.fromObject({hours}));
|
||||
const minutes = Math.floor(diff.as('minutes'));
|
||||
diff = diff.minus(luxon.Duration.fromObject({minutes}));
|
||||
const seconds = Math.floor(diff.as('seconds'));
|
||||
diff = diff.minus(luxon.Duration.fromObject({seconds}));
|
||||
const millis = diff.as('milliseconds');
|
||||
|
||||
const timeString = `${u(years, "year")}, ${u(months, "month")}, ${u(days, "day")}, ${f(hours)}:${f(minutes)}:${f(seconds)}.${Math.floor(millis / 100)}`;
|
||||
document.getElementById('counter').innerHTML = timeString;
|
||||
|
||||
window.setTimeout(setDuration, 10);
|
||||
}
|
||||
setDuration();
|
||||
|
||||
</script>
|
||||
|
||||
</html>
|
||||
Reference in New Issue
Block a user