Insure fontawesome V4 compatibility in navbar

[cderv]

This aims to fix #1991. The issue is that fas is now the default prefix instead of deprecated fa prefix, so we used that in #1967. However, rmarkdown was previously taking care of adding fa prefix to icon in navbar.
And it was working because fontawesome as shims for V4 compatibility (in v4-shims.css). For example, this was working:

navbar:
  right:
  - icon: fa-github
    href: https://github.com/xxx/yyy

because fa was added leading to fa fa-github which is taking care of by the V4 shims compatibility layer.
Our change would lead to add fas in this case, leading to fas fa-github which is wrong as it should be fab fa-github

As we don't really have a way to know if fas or fab should be added without parsing the list of icons, I think it is enough we no more add any prefix in icon in navbar for fontawesome 5.

This means :

• prefix + name needs to be passed for fontawesome 5 icons, like for new brand icons fab fa-r-project (original issue in Support for Font Awesome 5 glyphs in navbar #1554)
• fa-<iconname> will always be prefixed with fa (fa fa-<iconname>) not fas. This will insure V4 compatibility. All the more because it seems that in V5, fa can still be used even if the default is fas now.
• If for some reason some pass fa fa-<iconname> directly, don't duplicate the prefix and keep it that way.

I think this should be good now.

[jdblischak]

@cderv A small request: would you be able to add a bullet to NEWS.md to document this change? And if possible, it would be ideal if you could add a bullet to the 2.6 release to note that a change regarding Font Awesome was made. I heavily rely on NEWS.md to help keep workflowr up-to-date with the latest changes to rmarkdown. Great work by the way. It's awesome that you're now part of the official rmarkdown development team.

[cderv]

I already added the NEWS for previous change b71f9b0

and yes I'll add one here - usually I do that before merging but I should do earlier to not forget maybe. Thanks !

[cderv]

@jdblischak I may rethink this in the future (and it is part of why this is not merged).
I think there is something we can do (like shiny) to avoid providing a prefix and add the correct one if missing.
tracked in #2042

[jdblischak]

@cderv Thanks for the update. My current workaround is to explicitly add the "fab" prefix for rmarkdown >= 2.6. Will this continue to work even if you add the feature to automatically add "fab"? My reading of your description in #2042 is that "if needed" means my workaround will continue to work.

# Get Font Awesome icon for a brand
#
# Decide between Font Awesome 4 and 5
# https://github.com/rstudio/rmarkdown/issues/1991
get_fa_brand_icon <- function(brand) {
  if (utils::packageVersion("rmarkdown") < "2.6") {
    # Font Awesome 4: rmarkdown adds preceding "fa"
    return(sprintf("fa-%s", brand))
  }

  # Font Awesome 5
  return(sprintf("fab fa-%s", brand))
}

[cderv]

Yes if a prefix is added I believe we should not touch it and leave as-is.

But this also would mean if we follow this road that you may not need this workaround anymore as that it what rmarkdown would do for you.

[yihui]

On second thought, I tend to merge this PR for now instead of waiting for the fontawesome package to get rid of its heavy dependencies. BTW, depending on a completely new CRAN package means its binaries won't be available for older versions of R, which could be a trouble for Windows users, so I'd wait for even longer before we use fontawesome in rmarkdown (perhaps after three or five new versions of R have been released).

Anyway, I'll let you decide on this one. Thanks!

[cderv]

I'll merge this as this is an expected fix and I do not know when I'll work on adding direct fontawesome package support. Thanks @yihui.