Tailwind will likely save me CSS-coding time

I subscribe to the functional/utility mindset now for CSS, so I know now that if I do CSS I’d make utility classes of my own, so why go through that work when Tailwind already likely has everything I’d probably make myself. I’ll save so much time looking through their library and class names instead of trying to invent everything myself. I’ll likely spend five minutes of documentation-hunting for every ten minutes of personal CSS coding I’d do myself.

A problem-solving algorithm where you write a bunch and close your eyes

A problem-solving algorithm: Write the problem and all its subproblems down Write what you know and don’t know To increase your knowns, read, converse, listen, watch Criticize knowns and existing solutions (not written about here) Cut out external stimuli to stimulate a recall response In general, wait for a solution There’s an intersection of knowns and unknowns, the conscious and subconscious mind that lasers through problems with force and speed.

Builds are not optional in the shadow-cljs.edn (for testing)

shadow-cljs uses a namespace-like config structure similar to deps.edn, relying heavily on “builds” (with parity to “aliases” in deps.edn). There are few root-level, non-build config options in shadow-cljs. Most options are in “builds”. Absent a “build”, shadow-cljs offers no way to specify a “target” (shadow-cljs can help you write ClojureScript for Node.js, the browser, or Karma–which do you want?). You also need it to specify directories for tests. To run tests with ClojureScript you need to output it to JS and then run the JS.

All <svg> attributes are optional, not required

The otherwise extremely helpful MDN SVG docs overcomplicate the <svg> element for beginners. They throw in viewBox, xmlns, width, and height attributes for the svg canvas when not a single one is required, and I think this will frustrate the beginner who’ll think these attributes are required. It’s only with serious study and experimentation did I learn they were not required. One will almost never use the viewBox (how often do you simply zoom in on an subsection of an image instead of just show the whol image), refer to xmlns (the browser’s default works fine), nor use the width or height attributes (which’ll crop your image).

Reduce the amount of CSS you need to write with utility classes

Utility CSS trumps semantic CSS! What changed me CSS-wise was when I analyzed Coub.com’s CSS and saw the “-always-visible” and “-scrolled” classes and wondered “why do that”? I understood that these were called utility classes and DuckDuckGo-ed “utility classes”. I stumbled on an article that described the switch from “semantic” to “utility” describing it as a “functional” approach to CSS. This reminded me of Tailwind, and sure enough this was written by the creator of Tailwind in 2017.

Margin collapsing: Adjacent elements share the biggest margin between them, ignoring the lesser of the margins

In CSS, the browser “collapses” adjacent element margins. Two elements share the same direct parent. One’s bottom margin of 30px touches another’s top margin of 10px. The browser sees the 10px margin exists but doesn’t use it (collapses it), and the two elements share the top element’s 30px bottom margin. If you highlight the two elements in Devtools, the two margins will still show, but the top margin will overlap with the bottom here, rendering it unused.

In the standard CSS box model, width and height affect only the content box

CSS offers two box models: standard and alternate. These two models dictate which parts of the box width and height affect. In the standard, they only affect the content box–the padding and border are added after. In the alternate, the padding and border are considered with the width. To use the alternate box model, set box-sizing to border-box. To make the entire page use the alternate model, modify the html element to use box-sizing: border-box and make all the elements beneath it inherit it:

A browser takes html, makes a DOM tree, then makes a render tree, organizes it, then paints it.

A browser’s rendering engine always uses the same five-step process, potentially with extra steps. To create a webpage from html/css data, the browser takes the HTML, makes a DOM tree, constructs a render tree from the DOM tree, organizes it (lays it out), then paints it. Different browsers have different rendering engines to accomplish this: Trident (IE), Webkit (Safari), Gecko (Firefox), and Blink (fork of Webkit; used by Chrome, Edge(?), and Opera).

Nystatin busts fungal cell membranes

I have oral thrush (mouth fungus… gross). A nurse practitioner saw it and prescribed me a Nystatin “suspension” (liquid), which I’ve been taking four times daily. Learning about it, I see that Nystatin binds to the ergosterol in the fungi’s cell membrane, causing holes which leads to potassium loss then acidification and fungal cell death. Ergosterol doesn’t exist in animals or plants, so the Nystatin is effectively harmless. It can bind a bit to cholesterol though.

You need to go five-levels deep in the shadow-cljs config to specify what function should run at start with shadow-cljs

(Preface: I like shadow-cljs!) shadow-cljs’s config requires :source-paths, :dependencies, and :build values. The :build value should be a hashmap where you’ll specify what should be run and how. The config is more complicated than necessary because it specifies the environment similarly to deps.edn but uses different names for the same things: :deps -> :dependencies :paths -> :source-paths :aliases -> :builds Also just to say “run this function on load” you need to go five levels in: :builds ::modules :main :init-fn.