as a user, I want to be able to do some basic styling on the body element of the report

[hamilton]

example notebook that demonstates the issue. To summarize:

• I can't select only the report css without affecting all other css.
• The only method I have to select the report css is really not intuitive.

[hamilton]

This is higher priority than p3, I think. One way in which iodide will "break" for users if we change this after we tag a release as an MVP is that the CSS will change, so any workarounds or methods they used to create a document will simply not work. Seems like we should have a plan around this, though perhaps not immediately.

[bcolloran]

"should have a plan around this, though perhaps not immediately" sounds like a pretty good definition of p3 to me :-)

MVP functionality need not include supporting advanced css styling at all -- for the MVP, if users can eval code and use MD, we're at parity with Jupyter; something like that is "minimum", and there is much higher priority core workflow stuff still to tackle. advanced styling will be important, but is not doing it perfectly is not core to our initial offering

[hamilton]

I agree that the default report view is not "broken", but css is generally broken in the eval frame right now, and badly enough that we ought to just disallow any styling if we're not going to have a plan before MVP. I can't speak for everyone, but this has been a major rough edge with using Iodide for a large class of real work (dashboarding, actual reports) for me already. Parity w/ Jupyter in this feature doesn't feel like enough here, given my own experience working w/ the DOM in iodide. "changing the font" doesn't feel advanced to me, but it is genuinely difficult, and could be made easier.

[bcolloran]

@hamilton has proposed an idea about using shadowDOM for the implementation of this. @hamilton please feel free to add any additional details along those lines.