Python task manager from scratch, part 31: Adding some style

The current phase of development is, roughly, removing (ad hoc) some major annoyances in the actual use of the app (or proto-app).

The main strategic point here is to try to make improvements Hippocratically--that is, without doing harm. I've rushed out many features in the name of making an early draft more usable that unnecessarily complicated later work. A few principles to keep in mind:

1. Do not clutter up essential parts of the code with quick fixes. For example, if I tried to put the tasks in a more intelligent order by bashing some sorting logic into the routed functions in main.py, that would be bad.
2. Work behind interfaces where you can, even if you're doing a silly, temporary hack behind that interface.
3. Sometimes the best alternative to an interim solution with a mature structure but silly implementation is to have the structure be very silly, also.

What I've done here is an example of the silly implementation. I am adding some styling to the app to make it look nice and make sure that other changes I make are compatible with some sort of reasonable display. In the fullness of time, I'll want these to be in .css files and imported properly. For now, because my class names and everything else could easily change, I'm just doing string interpolation, inlining all the styling in the displayed HTML.

If that doesn't make sense, that's fine. CSS is very much not my favorite part of programming. Some things that are useful to know at this stage are:

1. What CSS is.
2. The basic idea of the box model.
3. What a CSS class is.
4. The basic idea of programming by (i) defining a structure on things to be manipulated, (ii) defining a list of rules about what should be done to various subsets of those things, and (if necessary) (iii) having meta-rules about handling conflicts between those rules. (By the way, there's a rich tradition of editing text in this way: see sed, awk, and various parts of Vim.

Defining all our HTML and CSS by doing string interpolation on the fly is not, not, not how large-scale, mature projects work. But if we separate components cleanly enough, it will be fairly painless to migrate to a more mature solution when we need to. (Or, at least, nowhere near as hard as migrating away from a half-baked attempt at using some framework.)

Here's the current commit in the veery/ repository.