-
-
Notifications
You must be signed in to change notification settings - Fork 790
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
Upgrade to FontAwesome 5 #2535
Comments
I think we should target this upgrade for 1.6.0. I'm open to using SVG as long as it doesn't require any additional local files. One of the main reasons we introduced font-based icons was to allow icons to be used without having to lug around other files. I'm not stuck on the font-based part. So if we can offer the same experience, I'm all for SVG. We also need to find a way to allow them to be colorized. |
No, as far as I know we just need to use a JavaScript to convert <head>
<!--load everything-->
<script defer src="https://use.fontawesome.com/releases/v5.0.4/js/all.js"></script>
</head>
<body>
<!--user icon in two different styles-->
<i class="fas fa-user"></i>
<i class="far fa-user"></i>
<!--brand icon-->
<i class="fab fa-github-square"></i>
</body> Having said that the JavaScript file may load more external ressources.
Sound fair enough.
Yes we can: <i class="fas fa-circle" style="color:Tomato"></i> |
It would be nice to be able to do "server-side" rendering in Asciidoctor.js: https://fontawesome.com/how-to-use/on-the-web/other-topics/server-side-rendering |
Is there an option to see which version of Font Awesome is currently used? I already tried
|
We are on Font Awesome 4 because Font Awesome 5 is basically a different library. |
I see, thanks for link. |
FWIW I would much prefer continuing with a pure-CSS instead of a JS solution. Server-side SVG rendering would be even better. |
Hopefully if we get an extension point you would be able to implement it client-side with CSS (+font), JS or server-side. If we just want to upgrade then I think we should keep using CSS + font.
I didn't do a complete review but if we stay on CSS + font the migration seems straightforward no? |
I'm not opposed to updating to FontAwesome 5. It just has to be handled very carefully so as not to break existing users. There are a lot of people who rely on this feature. If we handle it badly, it won't be pretty. And it definitely calls for a major version.
That's what I'm most concerned about. We did make this transition in Asciidoctor PDF, so we already have some understanding of what needs to happen.
We can't have a cavalier attitude about this, so nothing is "the only thing you really have to do". This is going to be a challenge no matter how you look at it. |
That's probably the right transitional step.
I still stand behind this statement. What FontAwesome did by renaming all the icons was to alienate their existing users. It was a huge mistake IMO. |
That's why they provide the v4 compatibility shim, which I suggested. It really is that easy if you want minimum effort. |
It's good to know that the compatbility shim does provide that drop-in replacement. Even with the shim, the icons have completely changed, so it still warrants a major version. (And from the feedback we've received on Asciidoctor PDF, not everyone is happy with the new look). |
@OrangeDog even though there is a compatibility shim it's not compatible with the solid icon set
In the above code, you have to either remove |
@bric3 it works for me, using |
@OrangeDog For me this does not work as expected, because the rendered asciidoc, is used in a page with FA5 that rely on element subsitution (with JS). So this is interpreted because there's the
If I don't use the js files, this work, but the rest of the page is broken. |
To aid with compatibility, we might consider allowing the icon-based font provider to be configured via an attribute. That would allow the continued use of Font Awesome 4 while also providing a path to use Font Awesome 5. It would be a bit more work, but it could help resolve this impasse we find ourselves at. |
We should be careful to not lock ourselves if we want to support alternative font icon sets and/or introduce a pluggable adapter for integrating icons libraries (similar to what we done for syntax highlighter). My point is to choose wisely how to configure the icon-based font provider. |
I agree entirely with Dan and Guillaume points here 🖤💛 Providing the ability to use version 5 and the upcoming 6 one while keeping a way to use version 4 how it is already now will both avoid breaking compatibility in existing documents and giving people the choice to use newer versions or even alternative font icon sets. Until the compatibility shim of the upgrade is figured out this is the way to go. As of now, those users who want to use Font Awesome 5 already need to know that it's possible to do it by using a head docinfo file as in the User Manual. In order to do this, one needs to use a |
@mnrvwl can you please add this section to the documentation please? Thank you ! |
Reading the comments it looks as if the upgrade Font Awesome 5 was never made. Font Awesome 6 is now latest with even more useful icons. What are your thoughts on using it? |
Any new thoughts on this topic? |
Font Awesome 6 does not appear to have changed any existing icon names. Therefore the v4-shims still work. |
We should decide if we want to use SVG icons with JavaScript or stick with Web Fonts.
Useful links:
The text was updated successfully, but these errors were encountered: