Copied from #423 (comment)

For pairing Thursday, let's go over alternative paths this could go through. Currently, CellStyle as an interface has a _to_html_style() method, that gets used on render.

Here, it looks like the new behavior to support is this:

• A certain type of style requires setting some initial table-level CSS (once for the importing of fonts)

Currently, the path used for this is:

• in tab_style, detect a particular CellStyleText (e.g. with a google font)
• create import statement for font
• set initial table css for importing font in the additional_css option
• additional css gets included on render

However, this means that if you use tab_style multiple times with google font, etc.., the additional css gets appended multiple times. Moreover, if the person modifies additional_css, they can remove the necessary import.

A second issue is that this exact code is pasted into the opt_table_font() method. We likely don't want to put custom handling for specific CellStyle types (with specific attributes) into these methods.

Repeating code twice isn't necessarily an issue though, so it could be that we map out paths for these kinds of activities, merge, and punt the work to a new issue