/* CSS that adds the bare minimum for a simple, accessible, * touch-friendly layout. * Nothing here exists purely for cosmetics; everything addresses a * specific a11y, compatibility, or critical * usability need. * * Three exceptions: * - I re-set the input styles so Safari wouldn't make them pill-shaped * - I tweaked some margins/paddings to make some things evenly aligned * - I made my IndieWeb profile photo align without an underline * on the whitespace between the photo and my name. * * I also don't use any non-microformats classes except when styling * depends on *content* of an element rather than structure/semantics. * Examples include images that look better with pixelated upscaling, * and posts on the list of entries in the "notes" section that are tall * and need a larger contain-intrinsic-size. * One exception: a class for narrow width body text. * * Some pages (e.g. post archives) are really long despite having a * small download size. Rather than resort to pagination, I decided to * use CSS containment and content-visibility. I test performance on * browsers with heavy throttling and no GPU acceleration to ensure that * they're gentle on the CPU. For instance, Lighthouse benchmarks my * machine's CPU power at 1200-1300 and recommends 2.8-3.0x throttling; * I throttle at 12-15x. * * "content-visibility: auto" implies containment; however, some * browsers don't support "content-visibility: auto" but do support the * "contain" property. To be consistent across all these browsers, I * therefore use both even if it's a bit redundant. Once the latest * Safari has supported "content-visibility: auto" for a year or so and * it's in the latest version of the Tor Browser (which typically uses * whatever the latest Firefox-ESR was a month or two ago), I'll * consider removing these redundancies. I'll probably have to wait two * years. * * To keep myself from caring about minute details, I limited myself to * only defining spacing in increments of .25em. Pixels are 1px or * multiples of 3px. This also improves compression. No more "finding * the perfect value". * * I cite WCAG 2.2 success criteria with "SC". I also tried to meet * the Google a11y requirement of 48px tap targets separated by atl * 8px, excluding inline links. This involved increasing font size, * padding, line-height, and margins. */ html { /* Mobile screens benefit from greater line-spacing so links are * further apart. Dyslexic users prefer the spacing too. * Necessary to meet SC 1.4.8. * <100dpi screens: sans-serif is better. Why did browsers settle * on serif being the default?? */ font: 100%/1.5 sans-serif; /* Nearly every page on my site is taller than the viewport. * Paint the scrollbar ASAP to prevent layout shifts. */ overflow-y: scroll; /* Site is already mobile optimized. * Don't screw up landscape mode. */ -webkit-text-size-adjust: none; text-size-adjust: none; } /* This should not take effect on printouts, to save paper. */ @media screen { body { /* Aligning to the center with space on both sides prevents accidental * link activation on tablets, and is a common practice that users are * more used to for articles. */ margin: auto; /* WCAG recommends a max line width. Not everyone can resize the * viewport. This isn't for large blocks of text yet, so we don't have * to go by SC 1.4.8. * 40em = lowest acceptable width for titles, nav, footers, etc */ max-width: 40em; /* Phone cases can cover the edges. Swipe-from-edge navigations * should not conflict with the page elements. Focus outlines for * heavily-padded nav links should not be cut-off. All three concerns * are addressed by adding some body padding. * I followed Google's a11y recommendations of "at least 8px space * between tappables" by creating margins/paddings between nav links; * re-use that same amount of space here. 24px is what it takes to * create atl 48px of non-interactive space on