Why use a prefix for font awesome?

[stephan-v]

Currently the font awesome font in use by debugbar is font-awesome.min.css in the `resources/vendor/font-awesome/css/' folder.

This file has prefixes like the one below in front of every font awesome class inside that file.

.phpdebugbar-fa-heart:before

Why not simply leaves these classes as is to comply with the regular font awesome classes?

Like so: .fa-heart:before

I don't see why this phpdebugbar- prefix is needed. This decision makes it impossible to swap out the font for a fontawesome cdn because all of the regular fa fa-heart classes will not take effect because of the prefix. You are using all of the regular icons from the icon set. This abstracting seems highly unwanted.

Can this be changed so we can actually swap out for a CDN and gain some flexibility? I would be more than happy to help with this.

[barryvdh]

Why do you need to swap it for a cdn? It's only for dev. They're are namespaced so they don't conflict with font awesome from the app itself, otherwise it could lead to a version mismatch.

[stephan-v]

The problem is that we are not using assetic or other solutions to load our assets this is because we are using a strict Content Security Policy header.

We can not load assets from the vendor folder because obviously you don't want your vendor file publicly available. This already leaves out the generated script and link tags. Because of our Content Security Policy we also can not render any inline CSS or JS. This means we have to grab the list of files and go through it ourselves with file_get_contents().

I think we ended up using something like this function and adding the widget assets to it as well:

JavascriptRenderer::getAssets()

The problem is that neither the dump assets nor this getAssets() list will retrieve the fonts. So the fonts don't get loaded.

This would not be a problem if we could easily swap in a fontawesome font of our own but because everything is prefixed and you actually called the font-family PhpDebugbarFontAwesome we can't even put in our own.

We fixed this by loading the fonts with file_get_contents() and wrapping them in the font-family PhpDebugbarFontAwesome that you have set. This way we can load the fonts from the vendor directory and not have to change anything. This is a big hassle though.

I get that you would want to prevent a version mismatch but then you should at least provide the flexiblity to use your own fontawesome font if you are already using one. That would make a lot more sense than doubling up on fonts.

[barryvdh]

In larave-debugbar I use the base64 encoded font olinline in the stylesheet, to render it on a route (which dumps the assets), could that work for you also, if we do that here?

[stephan-v]

@barryvdh I forgot about this issue so it has been a while ago, but that would probably work a lot better than the current setup.

[james-johnston-thumbtack]

Font Awesome actually provides Sass files that let you customize aspects of Font Awesome:

• Main file: https://github.com/FortAwesome/Font-Awesome/blob/master/scss/font-awesome.scss
• Variables file; notice you can set a custom $fa-css-prefix: e.g. you can set it to phpdebugbar-fa

This almost worked really well and was easy to integrate for our site, where we already have a front-end build process that includes Sass compilation. (To contrast, the debug bar does something really hacky here that we couldn't use: https://github.com/maximebf/php-debugbar/blob/master/build/namespaceFontAwesome.php - we need to also change other Font Awesome Sass variables, like the CDN address for the font files and we weren't really willing to further mess with this search/replace approach - it's too fragile.)

The problem is that you can't use the Sass files to change the font family name to PhpDebugbarFontAwesome. Everything is hard-coded to FontAwesome. I tried to submit a PR request upstream to get that to be a customizable variable too, but they adamantly refused. (Why they would let you namespace the CSS prefix but not the font family name is beyond me!)

• My rejected pull request: https://github.com/FortAwesome/Font-Awesome/pull/10406
• Older rejected issue with similar feature request: https://github.com/FortAwesome/Font-Awesome/issues/6113

Their suggested "solution" is to copy/paste blocks of FontAwesome code into our own source code, e.g. copy/paste contents of _core.scss and change the font family name there. That's pretty much a non-starter solution IMHO.

So yeah, in summary, debug bar using PhpDebugbarFontAwesome font family creates way too much friction for adoption for what should be a simple thing to accomplish and this won't change unless either Fort Awesome relents and accepts my PR, or Debug Bar stops this namespacing.