Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: improve internals of using google_font() helper #457

Open
rich-iannone opened this issue Sep 23, 2024 · 0 comments
Open

refactor: improve internals of using google_font() helper #457

rich-iannone opened this issue Sep 23, 2024 · 0 comments

Comments

@rich-iannone
Copy link
Member

rich-iannone commented Sep 23, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant