Better styling

[georgefst]

In a break from tradition, I would strongly recommend not attempting to review this one-commit-at-a-time. At this early stage of the frontend project, it's natural for there to be big sweeping changes, and it's the final state of this PR that's important, with the intermediate states best left as historical curiosities...

Given that we've said styling isn't the most important thing right now, I may have gotten a bit carried away here! But as well as taking us away from messy string concatenation for styles, this work has prompted several more general refactors, leaving the app in great shape for future work. Plus, some of the styling improvements are really about basic usability. For example, when I was working on a proof-of-concept for applying actions a few weeks ago, it was hard to debug without the current selection being indicated. Similarly, the recently-added definition panel buttons were previously way too small and annoying to click on, while simply making them bigger without adding scrollbars would have taken up too much screen space.

I believe I've developed a sensible set of principles for managing CSS, as expressed in 918eb41 (in summary: inline styles with Clay for component functionality, and style.css for pure aesthetics). This has so far been very pleasant to work with, but we may evolve our approach as we scale:

• We've discussed using Clay for what it's actually designed for, i.e. generating stylesheets.
  • Right now, style.css is quite a long way from being interesting or repetitive enough for this to be of much benefit. This might start to change when, for example, we wish to implement the beginner and intermediate mode styles from primer-app.
  • This would require changes to our build script, in order to run the Haskell code which imports Clay. This could be a single-file "cabal script", but I don't know how well these play with Haskell.Nix.
  • We could develop a way to statically ensure that class names and IDs match between Miso and Clay, rather than just making sure we use the same strings. This would require some common local library which both the main app and the Clay script would depend on.
  • Optionally, we could ditch relying on the CSS cascade at all, as we currently do for e.g. node colours, in favour of Haskell abstraction.
• We might choose to embrace Tailwind-style "utility classes".
  • Tailwind itself would probably be annoying to use, given that Miso and Haskell obviously lack the tight integration Tailwind has for React and JS build tools. Anyway, personally, I've become quite fond of CSS as a language and wary of stuff like Tailwind. For one thing, it's really quite nice to ditch all the heavyweight tooling and have something native that's well-supported by editors, browser dev tools, documentation etc.
  • I suspect the Tailwind style may be more useful for ad-hoc styling of basic UI components, whereas so far we've been focussed largely on program trees, which are more bespoke.
• We may wish to move away from a single monolithic stylesheet. CSS has some support for namespaces and scoping, but I don't know much about it.

Finally, note that we aren't yet attempting to perfectly match primer-app. For the trees, we're very close, and better in some ways, but for the definitions panel what we have here is basically the simplest thing that looks somewhat decent. Similarly, using scrollbars rather than a pan-and-zoom-able canvas isn't the best UX, but it's simple.

[georgefst]

Oh, whoops, I've accidentally formatted the README. Just a sec...

[dhess]

Recent Wasm builds on x86_64-linux have been OOM'ing. I'll fix this shortly.

edit: fixed.