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

Switch from fontawesome webfonts to SVG + JS #1619

Merged
merged 1 commit into from
Dec 10, 2020
Merged

Conversation

notriddle
Copy link
Contributor

By submitting this pull request, I confirm the following:

  • I have read and understood the contributors guide, as well as this entire template.
  • I have made only one major change in my proposed changes.
  • I have commented my proposed changes within the code.
  • I have tested my proposed changes.
  • I am willing to help maintain this change if there are issues with it later.
  • I give this submission freely and claim no ownership.
  • It is compatible with the EUPL 1.2 license
  • I have squashed any insignificant commits. (git rebase)
  • I have Signed Off all commits. (git commit --signoff)

What does this PR aim to accomplish?:

There are several problems with icon fonts. My biggest problem is that I see a box with F104 in it where there ought to be a picture, because I have web fonts disabled (for the same reason I use Pi-hole; most of the time, web fonts are a waste of time and they're in the critical path for rendering the page). Other people disable web fonts because they're dyslexic and want to have custom fonts used all the time, which is a far more important reason to make sure your site is usable without web fonts.

Web fonts are also anti-aliased as fonts, which can look ugly. Basically, using fonts for icons results in a bunch of stuff not really treating them correctly.

https://discourse.pi-hole.net/t/use-svg-for-icons-instead-of-font/40166

https://speakerdeck.com/ninjanails/death-to-icon-fonts

How does this PR accomplish the above?:

It uses Font Awesome's SVG + JS configuration. Since the Pi-hole dashboard already requires JavaScript to work at all, and it's very close to being a total drop-in replacement for the older CSS + Web Font setup, it seemed like the best choice with the least impact on the rest of the code. It's also supported by FontAwesome, and they have other nice features built into it.

The biggest downside is that it's a non-async JavaScript. If I had made it async, or loaded the script at the bottom of the page instead of the top, you'd have gotten a bit of jank when the script finished loading. The way to avoid both jank and avoid forcing the icons to load before the page becomes visible by inlining the icons or by using the plain SVG sprite, but that would have been a more invasive change to the AdminLTE code. At least this way, it only loads one file (a giant JavaScript file) instead of two (the CSS and the Web Font).

Before:

image

After:

image

What documentation changes (if any) are needed to support this PR?:

This should have no user-visible changes, except making things work in configurations where they used to be broken.

@dschaper
Copy link
Member

dschaper commented Nov 6, 2020

Thank you for the submission and the detailed explanation why it's needed. I'm not much of a JS guy so I can't attest to the code itself, but I like the concept.

@PromoFaux PromoFaux requested a review from XhmikosR November 8, 2020 15:28
@PromoFaux
Copy link
Member

@XhmikosR Can you take a look over this, please? This seems in your wheelhouse.

@XhmikosR
Copy link
Contributor

XhmikosR commented Nov 8, 2020

I'm not sold on the benefits of this, personally. I still use fonts and I have no issue with this approach.

That being said, this change should be made upstream too so that it reaches a bigger audience and more people benefit. Last time I checked, AdminLTE 3.x used the CSS. But if this is accepted upstream, one more reason to go with it here too.

Assuming all instances are changed, and someone tests this, it's your call, at the end. I don't have a lot of time to test this myself.

@XhmikosR
Copy link
Contributor

XhmikosR commented Nov 8, 2020

Also, the less JS, the better. I haven't measured this at all nor how much it affects the page size, but JS needs to be parsed and executed.

Just my 2 cents :)

@dschaper
Copy link
Member

dschaper commented Nov 8, 2020

I agree with XhmikosR that this should be a change at the upstream level. But in this case, we are the upstream since we've forked.

The vue node package is moving to SVG+JS and has noted no bad effects. https://www.npmjs.com/package/@fortawesome/vue-fontawesome#learn-about-our-new-svg-implementation

@notriddle
Copy link
Contributor Author

Last time I checked, AdminLTE 3.x used the CSS. But if this is accepted upstream, one more reason to go with it here too.

They added support for it already.

ColorlibHQ/AdminLTE#2920

Copy link
Member

@DL6ER DL6ER left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upstream AdminLTE already has this in master as well as v3.1.0-rc. As there were no other objections, we can merge this. Thanks a lot for your contribution!

@DL6ER DL6ER merged commit ad5679a into pi-hole:devel Dec 10, 2020
@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/use-svg-for-icons-instead-of-font/40166/7

@PromoFaux PromoFaux mentioned this pull request Dec 23, 2020
@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-core-web-v5-2-2-and-ftl-v5-3-3-released/41998/1

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

Successfully merging this pull request may close these issues.

6 participants