Re: WebUI Fonts

Re: WebUI Fonts

[Derick]

[-- Attachment #1.1: Type: text/plain, Size: 11665 bytes --]

>
> Let’s continue the discussion we had on the call with the list, and see
> if there’s anyone else interested in the topic.
>
> From my understanding, there are two issues here at play in the webui:
>
> 1. Should we be consistent about SVG icons versus font icons?  Which
> should we use?
> My take on this is that we should do whatever is easiest to maintain.
> Today we use both custom SVGs inline in the nav bar, as well as some
> font icons from the glyficons pack.  There were some concerns about
> accessibility on font icons that we should open a bug up on github and
> understand.  I would really like if that bug led to some documentation
> about how we handle accessibility, and what we would like to see from
> patchsets going forward in clear and concise rules, and a patchset to
> make the UI as it stands consistent in this regard.


I have an accessibility audit of our icons on a todo list and I'd love to
create the documentation to help make the
application more inclusive! I just need to prioritize the time with another
project.


>
> The solution I would like to see long term is to pull in a single font
> file, or single svg sprite file, and utilize webpacks built in tree
> shaking to keep it small.


With a single SVG sprite or definition file, tree shaking may not be
needed. Based on
the small number of icons we are using the file after compression should be
relatively
small. We can test that, but the SVG icons have been typically smaller than
font icons.


>
> With that said, my opinions between the two aren't that strong, as I
> believe functionally both options can achieve the same result.  Anyone
> that’s willing to push patches enabling one or another without breaking
> something, or effecting our build stats would be appreciated by me.  I
> could certainly be convinced that inline SVG, using the webpack backend
> was the better option, but I would really like to see some numbers on
> checked-in code size, final rootfs size, or start-up performance
> (preferably all 3).
>
>
I think the SVG sprite of definition option would be simple to implement
and should not
require too much work to implement.


> An example of setting of webpack up for fontawesome font tree shaking:
> https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking
>
> An example of using fontawesome with SVG sprites:
> https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites


The SVG sprite example above is exactly what I'm referring to. And the
icomoon tool (I refer to
that below in point #2 I have been using provides all the code, including
the SVG sprite.


>
> I think the important thing we need to be clear on and document is why
> we're making the change we're making.  Today the webui uses inline svg
> for the navbar icons;  Because the way it's built, those are required at
> initial page load, and we don't want to hold up the initial page load
> while we incur another round trip time to query the BMC for all of the
> icons.  The glyficons are loaded after the user is logged in.  Doing
> this spreads out the BMC load in the most common case, and doesn't incur
> a large payload download for loading the login page.
>
> One thing to be careful of with inline SVG:  Some of the SVG keywords
> will trigger the browsers content security policy.  Because SVG icons
> are read in as XML, things like "style" keywords need to be removed,
> similar to this review.
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949
>
>
I like the idea of using an SVG sprite. Using the <use> element (which
would required a small polyfill for IE 11)
the implementation is as simple as using font icons. We would only have the
icons we needed to use and the file size
(which we can test and evaluate) would be small since we don't need to
include the entire font-awesome library.

Some reasons I prefer the SVG sprite is:
1. It would allow for easy conversion downstream for anyone that wants to
use a different icon set
2. Implementation is consistent and can be easily documented

We can keep the login icons inlined to minimize the load if we think
loading the SVG sprite is too much of a load.


2. Should we allow library icons?
> This one is important to me.  To highlight the importance, let me lay
> out a hypothetical scenario.
> Developer X wants to build a new page on the webui to allow the BMC to
> tweet system failures (side note, this would be an awesome way to
> implement a hosted logger in the cloud for free).  Said developer is not
> a visual designer, nor has the ability to build icons.  They pull in the
> various buttons, textboxes, and forms from throughout the webui to build
> their UI, following the style guide while they do it with the existing
> CSS.  For their navbar icon, they pull in the twitter icon here:
> https://fontawesome.com/icons/twitter?style=brands
> The icon is responsive, uses vector graphics, is properly sized, and
> adds a negligible size to the final rootfs.
>
> Do we reject their code because they didn't create their own icon?
>
> I would advocate the answer is no.  I'm having trouble getting a read on
> this, but it sounds like the answer that is being proposed is that we
> should start enforcing icon style before merge for "consistency", but
> I'm not really following the end goal.  If someone is wanting to remove
> pages because the icon doesn't have a consistent style, that is easy
> enough to do in a config in the per-machine/per-company repositories.


Using an SVG sprite would make it easy to simply update the downstream SVG
sprite without
having to update any code.


>
> If someone wants to make the style more consistent, they can certainly
> push new custom icons to do that.  I think master branch of the webui
> needs to point at a web page that enables as much functionality as we
> can.  Having to create custom icons is one more reason for people to
> fork the codebase and not contribute back, and we want to avoid that as
> much as possible.
>
> Said another way, I would much rather have a first class UI feature with
> a stock icon, than no feature at all.
>
>
I agree with the use of a consistent and open icon set, like font awesome.
I have been using
a great tool called icomoon (free), https://icomoon.io/ to manage my icon
sets. It's fantastic
because we can use font awesome and can import icons if needed. The icon
set can be
saved as a JSON file and even added to the repository if needed, so that
anyone could
import it to icomoon and add or update icons using font awesome or any
number of other
free icon sets and then have an updated SVG sprite generated, as well as
downloading
the updated icon set config.

Derick Montague
* * * * * * * * * * * * * * * *

> From: *Ed Tanous* <ed.tanous@intel.com>
> Date: Mon, Jan 28, 2019 at 1:13 PM
> Subject: WebUI Fonts
> To: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
>
>
> Let’s continue the discussion we had on the call with the list, and see
> if there’s anyone else interested in the topic.
>
> From my understanding, there are two issues here at play in the webui:
>
> 1. Should we be consistent about SVG icons versus font icons?  Which
> should we use?
> My take on this is that we should do whatever is easiest to maintain.
> Today we use both custom SVGs inline in the nav bar, as well as some
> font icons from the glyficons pack.  There were some concerns about
> accessibility on font icons that we should open a bug up on github and
> understand.  I would really like if that bug led to some documentation
> about how we handle accessibility, and what we would like to see from
> patchsets going forward in clear and concise rules, and a patchset to
> make the UI as it stands consistent in this regard.
> The solution I would like to see long term is to pull in a single font
> file, or single svg sprite file, and utilize webpacks built in tree
> shaking to keep it small.
>
> With that said, my opinions between the two aren't that strong, as I
> believe functionally both options can achieve the same result.  Anyone
> that’s willing to push patches enabling one or another without breaking
> something, or effecting our build stats would be appreciated by me.  I
> could certainly be convinced that inline SVG, using the webpack backend
> was the better option, but I would really like to see some numbers on
> checked-in code size, final rootfs size, or start-up performance
> (preferably all 3).
>
> An example of setting of webpack up for fontawesome font tree shaking:
> https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking
>
> An example of using fontawesome with SVG sprites:
> https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites
>
> I think the important thing we need to be clear on and document is why
> we're making the change we're making.  Today the webui uses inline svg
> for the navbar icons;  Because the way it's built, those are required at
> initial page load, and we don't want to hold up the initial page load
> while we incur another round trip time to query the BMC for all of the
> icons.  The glyficons are loaded after the user is logged in.  Doing
> this spreads out the BMC load in the most common case, and doesn't incur
> a large payload download for loading the login page.
>
> One thing to be careful of with inline SVG:  Some of the SVG keywords
> will trigger the browsers content security policy.  Because SVG icons
> are read in as XML, things like "style" keywords need to be removed,
> similar to this review.
> https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949
>
> 2. Should we allow library icons?
> This one is important to me.  To highlight the importance, let me lay
> out a hypothetical scenario.
> Developer X wants to build a new page on the webui to allow the BMC to
> tweet system failures (side note, this would be an awesome way to
> implement a hosted logger in the cloud for free).  Said developer is not
> a visual designer, nor has the ability to build icons.  They pull in the
> various buttons, textboxes, and forms from throughout the webui to build
> their UI, following the style guide while they do it with the existing
> CSS.  For their navbar icon, they pull in the twitter icon here:
> https://fontawesome.com/icons/twitter?style=brands
> The icon is responsive, uses vector graphics, is properly sized, and
> adds a negligible size to the final rootfs.
>
> Do we reject their code because they didn't create their own icon?
>
> I would advocate the answer is no.  I'm having trouble getting a read on
> this, but it sounds like the answer that is being proposed is that we
> should start enforcing icon style before merge for "consistency", but
> I'm not really following the end goal.  If someone is wanting to remove
> pages because the icon doesn't have a consistent style, that is easy
> enough to do in a config in the per-machine/per-company repositories.
> If someone wants to make the style more consistent, they can certainly
> push new custom icons to do that.  I think master branch of the webui
> needs to point at a web page that enables as much functionality as we
> can.  Having to create custom icons is one more reason for people to
> fork the codebase and not contribute back, and we want to avoid that as
> much as possible.
>
> Said another way, I would much rather have a first class UI feature with
> a stock icon, than no feature at all.
>
> -Ed
>
>

[-- Attachment #1.2: Type: text/html, Size: 25085 bytes --]

[-- Attachment #2: Image.15432496725930.gif --]
[-- Type: image/gif, Size: 360 bytes --]

Re: WebUI Fonts

[Ed Tanous]

On 1/29/19 2:21 PM, Derick wrote:
> 
> 
> I have an accessibility audit of our icons on a todo list and I'd love
> to create the documentation to help make the 
> application more inclusive! I just need to prioritize the time with
> another project.
I didn't mean to call you out.  I realize we're all busy :)

> 
> small. We can test that, but the SVG icons have been typically smaller
> than font icons. 
That sounds like a great reason to use SVG over fonts.  If we can show
that in a meaningful way, I'm happy to support moving the UI over to SVG.

> 
> 
> The SVG sprite example above is exactly what I'm referring to. And the
> icomoon tool (I refer to 
> that below in point #2 I have been using provides all the code,
> including the SVG sprite.  
The first hit I get what I search "webpack icomoon" is a link to a stack
overflow with the title "webpack with icomoon does not work".  That's
not a great sign, although I haven't dug into the details yet.

Webpack also has some built-in capabilities for SVG sprites that I
haven't had time to look at.  It sounds like that is the current
best-practice for webpack.
https://github.com/kisenka/svg-sprite-loader

If we're looking at dropping webpack, or doing a two stage build
(icomoon then webpack) that's something that needs a longer discussion.
Alternatively webpack is open source, we could certainly just go fix
icomoon support.

> 
> 
> I like the idea of using an SVG sprite. Using the <use> element (which
> would required a small polyfill for IE 11) 
> the implementation is as simple as using font icons. We would only have
> the icons we needed to use and the file size 
> (which we can test and evaluate) would be small since we don't need to
> include the entire font-awesome library.
> 
> Some reasons I prefer the SVG sprite is:
> 1. It would allow for easy conversion downstream for anyone that wants
> to use a different icon set
> 2. Implementation is consistent and can be easily documented

This is exactly the kind of background I was looking for on why this
change is worth it, as well as trade offs and things that are required.

> 
> We can keep the login icons inlined to minimize the load if we think
> loading the SVG sprite is too much of a load.

I think a single SVG sprite doesn't add too much load.  It's when we're
pulling 12 different icons separately that we need to pay attention.
Today, rendering the initial login page load requires 4 files, one of
which is already an SVG (the openbmc logo), and 276KB of payload.   If
we go to svg sprites, presumably the SVG file just gets bigger, but
we're still requesting the same number of resources.  We should be in
good shape.

> 
> 
> Using an SVG sprite would make it easy to simply update the downstream
> SVG sprite without
> having to update any code.
>  

Say more on this point......  I'm not sure I understand.  Wont people
always have to override some file to update icons?
> 
>  
> I agree with the use of a consistent and open icon set, like font
> awesome. I have been using
> a great tool called icomoon (free), https://icomoon.io/ to manage my
> icon sets. It's fantastic
> because we can use font awesome and can import icons if needed. The icon
> set can be 
> saved as a JSON file and even added to the repository if needed, so that
> anyone could
> import it to icomoon and add or update icons using font awesome or any
> number of other
> free icon sets and then have an updated SVG sprite generated, as well as
> downloading
> the updated icon set config. 


My preference would be to use the built-in webpack sprite loader, under
the assumption that it works better, and will be easier to maintain long
term, but I'm happy to support icomoon if it's a better tool.




Moving the webui to SVG sprites sounds like a positive thing to do, and
has my support.  Looking forward to seeing the patchsets.

-Ed

Re: WebUI Fonts

[Derick]

[-- Attachment #1: Type: text/plain, Size: 5986 bytes --]

>
> The first hit I get what I search "webpack icomoon" is a link to a stack
> overflow with the title "webpack with icomoon does not work".  That's
> not a great sign, although I haven't dug into the details yet.
>

That looks like an icon font issue that we wouldn't have to deal with
if we went the SVG sprite route.


> Webpack also has some built-in capabilities for SVG sprites that I
> haven't had time to look at.  It sounds like that is the current
> best-practice for webpack.
> https://github.com/kisenka/svg-sprite-loader
>
> If we're looking at dropping webpack, or doing a two stage build
> (icomoon then webpack) that's something that needs a longer discussion.
> Alternatively webpack is open source, we could certainly just go fix
> icomoon support.
>

This looks really good. All we need to do is add
the SVGs to a directory and import in order to use it. The
process is much simpler than the icomoon approach and downstream
it's as simple as replacing the SVG to use a different icon.

Say more on this point......  I'm not sure I understand.  Wont people
> always have to override some file to update icons?
>

The svg-sprite-loader handles this well. If someone wants to use a
different Twitter icon, they just replace it downstream. No actual markup
would need to change, which is what I meant when I said no coding
would be needed.

The icomoon approaceh downstream would use a different SVG sprite, but
building and generating with iconmoon is cumbersome compared
to having webpack do the work for us!

My preference would be to use the built-in webpack sprite loader, under
> the assumption that it works better, and will be easier to maintain long
> term, but I'm happy to support icomoon if it's a better tool.
>

Looking at the loader, I think this is the right direction. If we don't
encounter any unforeseen issues
this seems like the simplest approach.

On Tue, Jan 29, 2019 at 4:46 PM Ed Tanous <ed.tanous@intel.com> wrote:

>
> On 1/29/19 2:21 PM, Derick wrote:
> >
> >
> > I have an accessibility audit of our icons on a todo list and I'd love
> > to create the documentation to help make the
> > application more inclusive! I just need to prioritize the time with
> > another project.
> I didn't mean to call you out.  I realize we're all busy :)
>
> >
> > small. We can test that, but the SVG icons have been typically smaller
> > than font icons.
> That sounds like a great reason to use SVG over fonts.  If we can show
> that in a meaningful way, I'm happy to support moving the UI over to SVG.
>
> >
> >
> > The SVG sprite example above is exactly what I'm referring to. And the
> > icomoon tool (I refer to
> > that below in point #2 I have been using provides all the code,
> > including the SVG sprite.
> The first hit I get what I search "webpack icomoon" is a link to a stack
> overflow with the title "webpack with icomoon does not work".  That's
> not a great sign, although I haven't dug into the details yet.
>
> Webpack also has some built-in capabilities for SVG sprites that I
> haven't had time to look at.  It sounds like that is the current
> best-practice for webpack.
> https://github.com/kisenka/svg-sprite-loader
>
> If we're looking at dropping webpack, or doing a two stage build
> (icomoon then webpack) that's something that needs a longer discussion.
> Alternatively webpack is open source, we could certainly just go fix
> icomoon support.
>
> >
> >
> > I like the idea of using an SVG sprite. Using the <use> element (which
> > would required a small polyfill for IE 11)
> > the implementation is as simple as using font icons. We would only have
> > the icons we needed to use and the file size
> > (which we can test and evaluate) would be small since we don't need to
> > include the entire font-awesome library.
> >
> > Some reasons I prefer the SVG sprite is:
> > 1. It would allow for easy conversion downstream for anyone that wants
> > to use a different icon set
> > 2. Implementation is consistent and can be easily documented
>
> This is exactly the kind of background I was looking for on why this
> change is worth it, as well as trade offs and things that are required.
>
> >
> > We can keep the login icons inlined to minimize the load if we think
> > loading the SVG sprite is too much of a load.
>
> I think a single SVG sprite doesn't add too much load.  It's when we're
> pulling 12 different icons separately that we need to pay attention.
> Today, rendering the initial login page load requires 4 files, one of
> which is already an SVG (the openbmc logo), and 276KB of payload.   If
> we go to svg sprites, presumably the SVG file just gets bigger, but
> we're still requesting the same number of resources.  We should be in
> good shape.
>
> >
> >
> > Using an SVG sprite would make it easy to simply update the downstream
> > SVG sprite without
> > having to update any code.
> >
>
> Say more on this point......  I'm not sure I understand.  Wont people
> always have to override some file to update icons?
> >
> >
> > I agree with the use of a consistent and open icon set, like font
> > awesome. I have been using
> > a great tool called icomoon (free), https://icomoon.io/ to manage my
> > icon sets. It's fantastic
> > because we can use font awesome and can import icons if needed. The icon
> > set can be
> > saved as a JSON file and even added to the repository if needed, so that
> > anyone could
> > import it to icomoon and add or update icons using font awesome or any
> > number of other
> > free icon sets and then have an updated SVG sprite generated, as well as
> > downloading
> > the updated icon set config.
>
>
> My preference would be to use the built-in webpack sprite loader, under
> the assumption that it works better, and will be easier to maintain long
> term, but I'm happy to support icomoon if it's a better tool.
>
>
>
>
> Moving the webui to SVG sprites sounds like a positive thing to do, and
> has my support.  Looking forward to seeing the patchsets.
>
> -Ed
>
>

[-- Attachment #2: Type: text/html, Size: 8211 bytes --]

Re: WebUI Fonts

[susan jasinski]

Some additional decisions were made today on IRC:

- Move to the webpack SVG sprite loader
- Guideline is to use the Carbon icon set for upstream build (Carbon
is an open and free icon set created by IBM)
- If a non-Carbon icon is used at some point, the code will NOT be
rejected; anyone can update it with a Carbon icon replacement or leave
it as is

On Tue, Jan 29, 2019 at 9:25 PM Derick <derick.montague@gmail.com> wrote:
>>
>> The first hit I get what I search "webpack icomoon" is a link to a stack
>> overflow with the title "webpack with icomoon does not work".  That's
>> not a great sign, although I haven't dug into the details yet.
>
>
> That looks like an icon font issue that we wouldn't have to deal with
> if we went the SVG sprite route.
>
>>
>> Webpack also has some built-in capabilities for SVG sprites that I
>> haven't had time to look at.  It sounds like that is the current
>> best-practice for webpack.
>> https://github.com/kisenka/svg-sprite-loader
>>
>> If we're looking at dropping webpack, or doing a two stage build
>> (icomoon then webpack) that's something that needs a longer discussion.
>> Alternatively webpack is open source, we could certainly just go fix
>> icomoon support.
>
>
> This looks really good. All we need to do is add
> the SVGs to a directory and import in order to use it. The
> process is much simpler than the icomoon approach and downstream
> it's as simple as replacing the SVG to use a different icon.
>
>> Say more on this point......  I'm not sure I understand.  Wont people
>> always have to override some file to update icons?
>
>
> The svg-sprite-loader handles this well. If someone wants to use a
> different Twitter icon, they just replace it downstream. No actual markup
> would need to change, which is what I meant when I said no coding
> would be needed.
>
> The icomoon approaceh downstream would use a different SVG sprite, but
> building and generating with iconmoon is cumbersome compared
> to having webpack do the work for us!
>
>> My preference would be to use the built-in webpack sprite loader, under
>> the assumption that it works better, and will be easier to maintain long
>> term, but I'm happy to support icomoon if it's a better tool.
>
>
> Looking at the loader, I think this is the right direction. If we don't encounter any unforeseen issues
> this seems like the simplest approach.
>
> On Tue, Jan 29, 2019 at 4:46 PM Ed Tanous <ed.tanous@intel.com> wrote:
>>
>>
>> On 1/29/19 2:21 PM, Derick wrote:
>> >
>> >
>> > I have an accessibility audit of our icons on a todo list and I'd love
>> > to create the documentation to help make the
>> > application more inclusive! I just need to prioritize the time with
>> > another project.
>> I didn't mean to call you out.  I realize we're all busy :)
>>
>> >
>> > small. We can test that, but the SVG icons have been typically smaller
>> > than font icons.
>> That sounds like a great reason to use SVG over fonts.  If we can show
>> that in a meaningful way, I'm happy to support moving the UI over to SVG.
>>
>> >
>> >
>> > The SVG sprite example above is exactly what I'm referring to. And the
>> > icomoon tool (I refer to
>> > that below in point #2 I have been using provides all the code,
>> > including the SVG sprite.
>> The first hit I get what I search "webpack icomoon" is a link to a stack
>> overflow with the title "webpack with icomoon does not work".  That's
>> not a great sign, although I haven't dug into the details yet.
>>
>> Webpack also has some built-in capabilities for SVG sprites that I
>> haven't had time to look at.  It sounds like that is the current
>> best-practice for webpack.
>> https://github.com/kisenka/svg-sprite-loader
>>
>> If we're looking at dropping webpack, or doing a two stage build
>> (icomoon then webpack) that's something that needs a longer discussion.
>> Alternatively webpack is open source, we could certainly just go fix
>> icomoon support.
>>
>> >
>> >
>> > I like the idea of using an SVG sprite. Using the <use> element (which
>> > would required a small polyfill for IE 11)
>> > the implementation is as simple as using font icons. We would only have
>> > the icons we needed to use and the file size
>> > (which we can test and evaluate) would be small since we don't need to
>> > include the entire font-awesome library.
>> >
>> > Some reasons I prefer the SVG sprite is:
>> > 1. It would allow for easy conversion downstream for anyone that wants
>> > to use a different icon set
>> > 2. Implementation is consistent and can be easily documented
>>
>> This is exactly the kind of background I was looking for on why this
>> change is worth it, as well as trade offs and things that are required.
>>
>> >
>> > We can keep the login icons inlined to minimize the load if we think
>> > loading the SVG sprite is too much of a load.
>>
>> I think a single SVG sprite doesn't add too much load.  It's when we're
>> pulling 12 different icons separately that we need to pay attention.
>> Today, rendering the initial login page load requires 4 files, one of
>> which is already an SVG (the openbmc logo), and 276KB of payload.   If
>> we go to svg sprites, presumably the SVG file just gets bigger, but
>> we're still requesting the same number of resources.  We should be in
>> good shape.
>>
>> >
>> >
>> > Using an SVG sprite would make it easy to simply update the downstream
>> > SVG sprite without
>> > having to update any code.
>> >
>>
>> Say more on this point......  I'm not sure I understand.  Wont people
>> always have to override some file to update icons?
>> >
>> >
>> > I agree with the use of a consistent and open icon set, like font
>> > awesome. I have been using
>> > a great tool called icomoon (free), https://icomoon.io/ to manage my
>> > icon sets. It's fantastic
>> > because we can use font awesome and can import icons if needed. The icon
>> > set can be
>> > saved as a JSON file and even added to the repository if needed, so that
>> > anyone could
>> > import it to icomoon and add or update icons using font awesome or any
>> > number of other
>> > free icon sets and then have an updated SVG sprite generated, as well as
>> > downloading
>> > the updated icon set config.
>>
>>
>> My preference would be to use the built-in webpack sprite loader, under
>> the assumption that it works better, and will be easier to maintain long
>> term, but I'm happy to support icomoon if it's a better tool.
>>
>>
>>
>>
>> Moving the webui to SVG sprites sounds like a positive thing to do, and
>> has my support.  Looking forward to seeing the patchsets.
>>
>> -Ed
>>

WebUI Fonts

[Ed Tanous]

Let’s continue the discussion we had on the call with the list, and see
if there’s anyone else interested in the topic.

From my understanding, there are two issues here at play in the webui:

1. Should we be consistent about SVG icons versus font icons?  Which
should we use?
My take on this is that we should do whatever is easiest to maintain.
Today we use both custom SVGs inline in the nav bar, as well as some
font icons from the glyficons pack.  There were some concerns about
accessibility on font icons that we should open a bug up on github and
understand.  I would really like if that bug led to some documentation
about how we handle accessibility, and what we would like to see from
patchsets going forward in clear and concise rules, and a patchset to
make the UI as it stands consistent in this regard.
The solution I would like to see long term is to pull in a single font
file, or single svg sprite file, and utilize webpacks built in tree
shaking to keep it small.

With that said, my opinions between the two aren't that strong, as I
believe functionally both options can achieve the same result.  Anyone
that’s willing to push patches enabling one or another without breaking
something, or effecting our build stats would be appreciated by me.  I
could certainly be convinced that inline SVG, using the webpack backend
was the better option, but I would really like to see some numbers on
checked-in code size, final rootfs size, or start-up performance
(preferably all 3).

An example of setting of webpack up for fontawesome font tree shaking:
https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking

An example of using fontawesome with SVG sprites:
https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites

I think the important thing we need to be clear on and document is why
we're making the change we're making.  Today the webui uses inline svg
for the navbar icons;  Because the way it's built, those are required at
initial page load, and we don't want to hold up the initial page load
while we incur another round trip time to query the BMC for all of the
icons.  The glyficons are loaded after the user is logged in.  Doing
this spreads out the BMC load in the most common case, and doesn't incur
a large payload download for loading the login page.

One thing to be careful of with inline SVG:  Some of the SVG keywords
will trigger the browsers content security policy.  Because SVG icons
are read in as XML, things like "style" keywords need to be removed,
similar to this review.
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949

2. Should we allow library icons?
This one is important to me.  To highlight the importance, let me lay
out a hypothetical scenario.
Developer X wants to build a new page on the webui to allow the BMC to
tweet system failures (side note, this would be an awesome way to
implement a hosted logger in the cloud for free).  Said developer is not
a visual designer, nor has the ability to build icons.  They pull in the
various buttons, textboxes, and forms from throughout the webui to build
their UI, following the style guide while they do it with the existing
CSS.  For their navbar icon, they pull in the twitter icon here:
https://fontawesome.com/icons/twitter?style=brands
The icon is responsive, uses vector graphics, is properly sized, and
adds a negligible size to the final rootfs.

Do we reject their code because they didn't create their own icon?

I would advocate the answer is no.  I'm having trouble getting a read on
this, but it sounds like the answer that is being proposed is that we
should start enforcing icon style before merge for "consistency", but
I'm not really following the end goal.  If someone is wanting to remove
pages because the icon doesn't have a consistent style, that is easy
enough to do in a config in the per-machine/per-company repositories.
If someone wants to make the style more consistent, they can certainly
push new custom icons to do that.  I think master branch of the webui
needs to point at a web page that enables as much functionality as we
can.  Having to create custom icons is one more reason for people to
fork the codebase and not contribute back, and we want to avoid that as
much as possible.

Said another way, I would much rather have a first class UI feature with
a stock icon, than no feature at all.

-Ed