Patron-only: stage 3 prototype (Patreon)

This time you get a Bard! I was hoping to get this one posted a week ago, but fiddly CSS stuff held me up.

As before, there are a shedload of caveats, that mostly boil down to: it's a prototype, not a real thing.

Here's the stage 3 prototype. 

This is the stage where it's all created using render functions rather than flat HTML. This forces me to use regular, repeatable elements each time, rather than hand-coding exceptions. Except I had to hand-code a couple of exceptions anyway, because life is like that.

Cover page

I'm trying out different things on the cover page. This time I borrowed Lem's backstory wholesale. Of course most characters won't (and, according to everyone who's ever GM'd for me, shouldn't) have a massive backstory like that, but it's a different 

I'd like the cover page to stay relatively clean and simple, not full of too much detail. It also shouldn't contain anything that isn't present elsewhere, so if you throw it away or decide not to print it, you haven't actually lost anything.

Learning

For each of these early stages I start with a blank slate each time, put a different structure in place, then borrow liberally from the bits of the previous stage. That can be a little disheartening, and it's why there's a big gap between the stages, but I'm doing it that way so I can learn important things about the nature of the project and apply them next time.

This time I learned that every render function needs to have a set of defaults, so that's something I'll bake in, saving myself from checking lots of "does this have a width set?" special cases. I also learned that the context in which a render function is called affects that. For example, the skills table as a whole defines properties that affect all the fields within it.

I learned that the render functions allows me to write much more regular structures for simple-seeming things. For example, every field now has a nested structure that makes it easier to hook the CSS onto, separating the outer part that has the label on it from the inner part that has the inputs.

I learned that the HTML5 <output> element is a pain in the neck and life is easier if I just stop using it entirely.

Browsers and CSS

Not everything I learn is positive. I've learned this time that even modern browsers can have a lot of subtle differences in how they handle the newer bits of CSS. I'm making heavy use of two relatively new parts of CSS called Grid and Flexbox, and the interactions between them aren't as tidy as I'd like.

Cue me screaming "FIREFOX DOES FLEX-BASIS FOR GRIDS JUST FINE, WHY IS CHROME BEING STUPID ABOUT IT?!?". I haven't even opened Internet Explorer, but I expect it would make me cry.

The result is that there's some jankiness in pretty much every browser. For example, if you print (to PDF) in Firefox, you get a blank page first. Why? I don't know.

Also, as I said in my previous stage, I'm getting closer to the time that I have to abandon fixed-content pages in favour of ones that are built by having various things added to them by feats, by archetypes, etc. That'll mostly be stage 5, but I need to be ready for it.

So I need to take a step back and think about the shape of the outmost layout element, the page itself, and how things get laid out.

Next step

The next step is a data-driven layout. Instead of calling the render functions directly, it'll start with a JSON tree describing the desired elements, and it'll run a visitor function over those to call the render functions.

But first, I should turn back to my rewrite of the website. There are things in the pipeline, like Starfinder archetypes, that probably deserve some love.