WebUI Fonts

[Derick]

>
> 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 at intel.com>
> Date: Mon, Jan 28, 2019 at 1:13 PM
> Subject: WebUI Fonts
> To: openbmc at lists.ozlabs.org <openbmc at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190129/f26431bf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image.15432496725930.gif
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190129/f26431bf/attachment-0001.gif>