You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
Currently, the path used for this is:
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
The text was updated successfully, but these errors were encountered: