Awesome, thanks for opening this issue!

I changed the approach completely and added a_repr_html_ tobackend_bases.FigureCanvasBase. It gets the default format type and returns that format as HTML. It defaults to png whenever the format is not one of png, svg, jpg, or pdf. I used the<embed> tag for pdfs.

In Figure, the_repr_html_ defers to the canvas_repr_html_ for all cases. I moved the existing code to thebackend_webagg.FigureCanvasWebAgg class under its own_repr_html_.

Made more changes toFigureCanvasBase._repr_html_ to account for retina display.

Currently, when retina is chosen as the figure format with%config InlineBackend.figure_format = 'retina' a png will always be output. This functionality is changed in this pull request to use theget_default_filetype of the canvas.

Thebbox_inches are set to 'tight' whenever%matplotlib inline has not been run. They are set to theInlineBackend.print_figure_kwargs['bbox_inches'] when inline activated.

All backends usercParams['savefig.format'] whenevercanvas.get_default_filetype is not implemented.

Backendnbagg is still interactive (if%matplotlib notebook was run) as it appears that ipython's display formatter gets triggered first which starts the application (I think?).

Ah, I missed the fact that ipython had an additional "retina" format. Ugh.

This seems to pretty much reimplement the Ipykernel inline backend into matplotlib. I'm not convinced that this is the right approach, because it uses the IPython configuration system to determine the right parameters and thereby introduces a dependency on that config system which I don't think should be there.

What about adding aFigure.to_html(**savefigkw) method instead?

@ImportanceOfBeingErnest The point of this is to work with jupyter notebooks whenever a figure is the last line of a cell without the need for%matplotlib inline.

The only reason IPython is accessed is to check whether the display is retina and whatbbox_inches is set to.

If you had ato_html method then you'd have to hook it into ipython somehow, which would use similar code.

I think my problem is really about the two-way dependency introduced here. If IPython/IPykernel decides to introduce a new figure format"SchweineGulasch", is matplotlib expected to take it over as well? If they decide to change the defaultbbox_inches parameter, should matplotlib adapt to it?

But if we don't, then people will complain that the figures they produce with the IPykernel inline backend look different from the ones they create via matplotlib's_repr_html_.

Good point. It would be nice if ipython was made completely independent from matplotlib and dropped all of its code that had to do with it. matplotlib could then handle everything with the importing of pyplot and_repr_html_. Would be a much cleaner approach.

I again agree with@ImportanceOfBeingErnest , the default implementation on the canvas base-class should not special case the inline backend and IPyhon's configuration system (just embedding a png at the native size would be fine). The support for that could be done in a companion PR into IPython to move their logic to the correct place. It seems fair for people who want the fancier controls from IPython have to use the IPython sourced backend.

There will also need to be a companion PR into ipympl so that we correctly defer to their canvas as well.

I am very 👍 on this PR in principle, but the technical interaction between Matplotlib and IPython/jupyter has always been complicated and we need to make sure that we are making it simpler for the devs while making it more streamlined for the users.

Thanks@tacaswell for the feedback. I've changed approaches again and now defer all html output to ipython ifInlineBackend is in theconfigurables list. This greatly simplifies things. (Is there a better way to check for this?)

Otherwise, the default canvas format gets returned as HTML.

Essentially, this method will only be useful for those who don't run%matplotlib and don't import pyplot. As soon as either of those happen, ipython is in full control.

Definitively the separation IPython/Matplotlib is not great, and I'm happy to try to get better behavior on the IPython codebase.

The concern I have with__repr_html__ is that you may end up with duplicated figures if the last line of a cell return a figure. We went to relatively great length to make sure figurer get displayed when they are not the last in the cell; so if you end up having a call at end-of-cell, that happen to also return a fig/ax, then you will risk double display.

I don't like having to special case matplotlib either, and admittedly there is no really good way to know wether we are in inline mode or not. At some points, we likely want to sit-down for a couple of hours list the current behavior and plan for a progressive cleanup over the next few years.

Definitively the separation IPython/Matplotlib is not great, and I'm happy to try to get better behavior on the IPython codebase.

Heh, I'm about to submit a post on the matplotlib discourse stating how great this would be :)

Regarding the double display: Currently, I experience the double display whenever I have aplt.command in the cell along withfig at the bottom of the same cell. This new_repr_html_ would trigger double display if pyplot was imported or%matplotlib run and the last line was aplt.command that returned a figure (or another library that returned a figure using pyplot). I think this would be very rare.

Agreed, the current behavior is pretty convoluted and I think can be greatly simplified.

Closing in lieu of#17891, but feel free to reopen if I've misunderstood...