Description
This is not an immediate priority, but I wanted to capture some of my thoughts in case anyone has any feedback.
Our report CSS is somewhat fine if you want to just write a simple report, but there are places where our design choices break down:
(1) I slapped together some weird ways of both allowing a centered-body content paradigm but also allows for other sizing for certain elements. It is most certainly the worst way of doing this. Having recently worked on a content layout project utilizing css grids, it's clear to me that there is a much easier, sturdier way of doing what we're doing now that allows for greater flexibility and control.The way forward on this end seems very clear to me, since a grid layout solves numerous issues all at once. The outcome for most standard reports is things will look mostly the same (perhaps some style improvements for flow and readability), but weird edge cases (like matplotlib plots rendering on the far side of a page) won't happen nearly as often.
(2) the way we're manifesting the default css makes it difficult to tweak properties. We need to reverse the cascade so that user-entered css overrides the stylesheet, not vice-versa. (#1497)
(3) we have no good way to tweak the overall content css (such as body color) without also clobbering other panes. Perhaps this will be fixed when we move some things out of the iframe, but ultimately we need to do a better job of protecting the other panes from css, since that's not really the intended use-case of the css cell.
(4) it's been noted that using a Github-style system font stack in the report view is probably not optimal (#1422), & perhaps it'd be better if we stuck to a web font that looks great, a la Medium. I'm more or less in favor of that, but I should note that I do think Distill is a better model for what we're doing than Medium, and they actually DO use a system font stack for all of their reports. This to me is less of the concern, since typefaces can easily be swapped out and experimented, but the underlying css layout is the critical piece here.
(5) "what about widgets?" html input elements like sliders and text boxes actually work pretty well, and we could stand to also provide some simple formatting to make them work more nicely. This is less an issue now and more an idea for the future.
At any rate, those are my thoughts on the matter. Would be thrilled to have further feedback. For me, one of the great use-cases of Iodide is in translating a simple data exploration into a presentation. We need to set things right on the style front so users who want to do just a tad bit more than what the standard report does doesn't have to suffer as much as they do now.