* Update FontAwesome to v5.0.6
* Adapt DiscussionListItem-count icon to match FontAwesome 5 syntax
* Change icon name to match FontAwesome 5.0.6 fas icon
* Add font type prefix parameter to icon helper
* Add Enable Icon Prefix to show icon in Extension Page
* Fix invalid icon behavior
* Change icon name to match FontAwesome 5.0.6 far icon
* Use iconPrefix property on component
* Use full icon class name
* Update icon helper docblock
* Full icon class syntax
* Added type search to search bar (forum)
* Added CSS `box-sizing: inherit` to search <input> because bootstrap styles mess up the search box
* Added type color to both color settings in appearance (admin)
If install flarum in the site's root directory, it seems nothing
is wrong because the server software will trim the path, but if
install flarum in a sub directory, the font file of fontawesome
will not load correctly.
Closes#268. Not going to bother with a preview SVG or anything fancy for now – we can think about that as part of #746. Right now it's just good to finally get this functionality in!
Also need to think about apple-touch-icon, msTile stuff, and social sharing image. Not sure if this is all too much for core, but it's definitely too much for the current Appearance page layout. Again, something to think about as part of #746.
Code is a bit rough around the edges, but figured there's not much point in using the command bus properly since #870.
- Fix jank in shrinking animation when search box loses focus after overlapping forum title.
- Use solid colors instead of transparent whites/blacks for colored header controls so that search box isn't transparent when it does overlap forum title.
- This also simplifies colored header variables, making them more analogous to the non-colored header variables, and allowing for the removal of some conditional CSS in the notifications dropdown button.
Some more radical changes to header layout (flexbox?) may be made when we implement the new mobile design (#867), but for now this is an acceptable fix.
Allowing headStrings to be named is a bit of a stopgap solution. Really ClientView needs to be given much more power with headStrings and footStrings as separate objects, similar to the ItemList in the JS app.
