CLN/API: implemented to_html in terms of .style

Implement to_html / notebook repr based on .style.

prob need to expand this to take a use argument (to select the style, needs to be ‘classic’ for a while, to replicate the current .to_html one).

[attack68]

You’re right if it is certain that HTMLFormatter can be completely removed. Is that the case? It seems not, guessing from @toobaz’ comment.

@moi90 If the goal is to replicate all of the functionality from DataFrame.to_html() then yes it can be done and a lot has already been done in my wip pr. Not all though, because I wanted to raise the issue about simply blindly replicating a function which in some cases produces deprecated HTML, and instead consider the merits of making some changes perhaps with a view to pandas 2.0.

While your attempt in master…attack68:latex_styler_mvp is cool, I suspect the complexity will increase quite a bit once we start supporting formatting (which won’t use stuff like css), to the point that what jinja2 actually delivers is only a small part of the task of formatting to LaTeX.

@toobaz I progressed the MVP to state where it now has a lot of general conditional styling capability for latex tables. See my response here I still want to be able to add some table level styles like column colouring or odd/even colouring but these are quite easy extensions.

I would be happy to be proven wrong though. How difficult would it be, in #40312, to run the test suite with DataFrame.to_html() replaced with the jinja2 implementation, just to see what breaks?

Quite easy, just need to redirect the method, when I push it I will ping you to take a look at test results.

[attack68]

In #45382 I’m proposing changing the signature of DataFrame.to_latex to:

DataFrame.to_latex(hide, format, format_index, render_kwargs)

and this will perform the following:

DataFrame.style.hide(**hide).format(**format).format_index(**format_index).to_latex(**render_kwargs)

This has the advantage of:

• converting the method to use Styler implementation
• not require updates to the arguments signature of DataFrame.to_latex since it passes the kwargs through
• allows a structured deprecation cycle where all the existing args can be restructured into this format as documented.

Is this reasonable and would it be appropriate to aim for something similar with to_html for v2.0?