<div dir="ltr"><div dir="ltr"><div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">Let’s continue the discussion we had on the call with the list, and see</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">if there’s anyone else interested in the topic.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">From my understanding, there are two issues here at play in the webui:</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">1. Should we be consistent about SVG icons versus font icons?  Which</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">should we use?</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">My take on this is that we should do whatever is easiest to maintain.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">Today we use both custom SVGs inline in the nav bar, as well as some</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">font icons from the glyficons pack.  There were some concerns about</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">accessibility on font icons that we should open a bug up on github and</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">understand.  I would really like if that bug led to some documentation</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">about how we handle accessibility, and what we would like to see from</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">patchsets going forward in clear and concise rules, and a patchset to</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">make the UI as it stands consistent in this regard.</span></blockquote><div><br></div><div>I have an accessibility audit of our icons on a todo list and I'd love to create the documentation to help make the </div><div>application more inclusive! I just need to prioritize the time with another project.</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">The solution I would like to see long term is to pull in a single font</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">file, or single svg sprite file, and utilize webpacks built in tree</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">shaking to keep it small.</span></blockquote><div><br></div><div>With a single SVG sprite or definition file, tree shaking may not be needed. Based on</div><div>the small number of icons we are using the file after compression should be relatively</div><div>small. We can test that, but the SVG icons have been typically smaller than font icons. </div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">With that said, my opinions between the two aren't that strong, as I</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">believe functionally both options can achieve the same result.  Anyone</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">that’s willing to push patches enabling one or another without breaking</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">something, or effecting our build stats would be appreciated by me.  I</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">could certainly be convinced that inline SVG, using the webpack backend</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">was the better option, but I would really like to see some numbers on</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">checked-in code size, final rootfs size, or start-up performance</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">(preferably all 3).</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"></blockquote><div><br></div><div>I think the SVG sprite of definition option would be simple to implement and should not</div><div>require too much work to implement.</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">An example of setting of webpack up for fontawesome font tree shaking:</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><a href="https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking" rel="noreferrer" style="font-family:Verdana,Geneva,sans-serif;font-size:14px" target="_blank">https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking</a><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">An example of using fontawesome with SVG sprites:</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><a href="https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites" rel="noreferrer" style="font-family:Verdana,Geneva,sans-serif;font-size:14px" target="_blank">https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites</a></blockquote><div><br></div><div>The SVG sprite example above is exactly what I'm referring to. And the icomoon tool (I refer to </div><div>that below in point #2 I have been using provides all the code, including the SVG sprite.  </div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">I think the important thing we need to be clear on and document is why</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">we're making the change we're making.  Today the webui uses inline svg</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">for the navbar icons;  Because the way it's built, those are required at</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">initial page load, and we don't want to hold up the initial page load</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">while we incur another round trip time to query the BMC for all of the</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">icons.  The glyficons are loaded after the user is logged in.  Doing</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">this spreads out the BMC load in the most common case, and doesn't incur</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">a large payload download for loading the login page.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">One thing to be careful of with inline SVG:  Some of the SVG keywords</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">will trigger the browsers content security policy.  Because SVG icons</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">are read in as XML, things like "style" keywords need to be removed,</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">similar to this review.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><a href="https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949" rel="noreferrer" style="font-family:Verdana,Geneva,sans-serif;font-size:14px" target="_blank">https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949</a><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"></blockquote><div><br></div><div>I like the idea of using an SVG sprite. Using the <use> element (which would required a small polyfill for IE 11) </div><div>the implementation is as simple as using font icons. We would only have the icons we needed to use and the file size </div><div>(which we can test and evaluate) would be small since we don't need to include the entire font-awesome library.</div><div><br></div><div>Some reasons I prefer the SVG sprite is:</div><div>1. It would allow for easy conversion downstream for anyone that wants to use a different icon set</div><div>2. Implementation is consistent and can be easily documented</div><div><br></div><div>We can keep the login icons inlined to minimize the load if we think loading the SVG sprite is too much of a load.</div><div><br></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">2. Should we allow library icons?</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">This one is important to me.  To highlight the importance, let me lay</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">out a hypothetical scenario.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">Developer X wants to build a new page on the webui to allow the BMC to</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">tweet system failures (side note, this would be an awesome way to</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">implement a hosted logger in the cloud for free).  Said developer is not</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">a visual designer, nor has the ability to build icons.  They pull in the</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">various buttons, textboxes, and forms from throughout the webui to build</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">their UI, following the style guide while they do it with the existing</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">CSS.  For their navbar icon, they pull in the twitter icon here:</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><a href="https://fontawesome.com/icons/twitter?style=brands" rel="noreferrer" style="font-family:Verdana,Geneva,sans-serif;font-size:14px" target="_blank">https://fontawesome.com/icons/twitter?style=brands</a><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">The icon is responsive, uses vector graphics, is properly sized, and</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">adds a negligible size to the final rootfs.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">Do we reject their code because they didn't create their own icon?</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">I would advocate the answer is no.  I'm having trouble getting a read on</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">this, but it sounds like the answer that is being proposed is that we</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">should start enforcing icon style before merge for "consistency", but</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">I'm not really following the end goal.  If someone is wanting to remove</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">pages because the icon doesn't have a consistent style, that is easy</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">enough to do in a config in the per-machine/per-company repositories.</span></blockquote><div><br></div><div>Using an SVG sprite would make it easy to simply update the downstream SVG sprite without</div><div>having to update any code.</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">If someone wants to make the style more consistent, they can certainly</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">push new custom icons to do that.  I think master branch of the webui</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">needs to point at a web page that enables as much functionality as we</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">can.  Having to create custom icons is one more reason for people to</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">fork the codebase and not contribute back, and we want to avoid that as</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">much as possible.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">Said another way, I would much rather have a first class UI feature with</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><span style="font-family:Verdana,Geneva,sans-serif;font-size:14px">a stock icon, than no feature at all.</span><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"><br style="font-family:Verdana,Geneva,sans-serif;font-size:14px"></blockquote><div> </div><div>I agree with the use of a consistent and open icon set, like font awesome. I have been using</div><div>a great tool called icomoon (free), <a href="https://icomoon.io/" target="_blank">https://icomoon.io/</a> to manage my icon sets. It's fantastic</div><div>because we can use font awesome and can import icons if needed. The icon set can be </div><div>saved as a JSON file and even added to the repository if needed, so that anyone could</div><div>import it to icomoon and add or update icons using font awesome or any number of other</div><div>free icon sets and then have an updated SVG sprite generated, as well as downloading</div><div>the updated icon set config. </div><div> </div></div><div dir="ltr"><div><div dir="ltr" class="m_-1169918046772013318gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="font-family:arial;font-size:small">Derick Montague</span><div style="font-family:arial;font-size:small">* * * * * * * * * * * * * * * * </div></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-1169918046772013318gmail-m_2816826239589601285socmaildefaultfont" dir="ltr" style="font-family:Verdana,Geneva,sans-serif;font-size:10.5pt"><div dir="ltr"><div dir="ltr">From: <strong dir="auto">Ed Tanous</strong> <span dir="ltr"><<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>></span><br>Date: Mon, Jan 28, 2019 at 1:13 PM<br>Subject: WebUI Fonts<br>To: <a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a> <<a href="mailto:openbmc@lists.ozlabs.org" target="_blank">openbmc@lists.ozlabs.org</a>></div><br><br>Let’s continue the discussion we had on the call with the list, and see<br>if there’s anyone else interested in the topic.<br><br>From my understanding, there are two issues here at play in the webui:<br><br>1. Should we be consistent about SVG icons versus font icons?  Which<br>should we use?<br>My take on this is that we should do whatever is easiest to maintain.<br>Today we use both custom SVGs inline in the nav bar, as well as some<br>font icons from the glyficons pack.  There were some concerns about<br>accessibility on font icons that we should open a bug up on github and<br>understand.  I would really like if that bug led to some documentation<br>about how we handle accessibility, and what we would like to see from<br>patchsets going forward in clear and concise rules, and a patchset to<br>make the UI as it stands consistent in this regard.<br>The solution I would like to see long term is to pull in a single font<br>file, or single svg sprite file, and utilize webpacks built in tree<br>shaking to keep it small.<br><br>With that said, my opinions between the two aren't that strong, as I<br>believe functionally both options can achieve the same result.  Anyone<br>that’s willing to push patches enabling one or another without breaking<br>something, or effecting our build stats would be appreciated by me.  I<br>could certainly be convinced that inline SVG, using the webpack backend<br>was the better option, but I would really like to see some numbers on<br>checked-in code size, final rootfs size, or start-up performance<br>(preferably all 3).<br><br>An example of setting of webpack up for fontawesome font tree shaking:<br><a href="https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking" rel="noreferrer" target="_blank">https://fontawesome.com/how-to-use/with-the-api/other/tree-shaking</a><br><br>An example of using fontawesome with SVG sprites:<br><a href="https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites" rel="noreferrer" target="_blank">https://fontawesome.com/how-to-use/on-the-web/advanced/svg-sprites</a><br><br>I think the important thing we need to be clear on and document is why<br>we're making the change we're making.  Today the webui uses inline svg<br>for the navbar icons;  Because the way it's built, those are required at<br>initial page load, and we don't want to hold up the initial page load<br>while we incur another round trip time to query the BMC for all of the<br>icons.  The glyficons are loaded after the user is logged in.  Doing<br>this spreads out the BMC load in the most common case, and doesn't incur<br>a large payload download for loading the login page.<br><br>One thing to be careful of with inline SVG:  Some of the SVG keywords<br>will trigger the browsers content security policy.  Because SVG icons<br>are read in as XML, things like "style" keywords need to be removed,<br>similar to this review.<br><a href="https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949" rel="noreferrer" target="_blank">https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-webui/+/16949</a><br><br>2. Should we allow library icons?<br>This one is important to me.  To highlight the importance, let me lay<br>out a hypothetical scenario.<br>Developer X wants to build a new page on the webui to allow the BMC to<br>tweet system failures (side note, this would be an awesome way to<br>implement a hosted logger in the cloud for free).  Said developer is not<br>a visual designer, nor has the ability to build icons.  They pull in the<br>various buttons, textboxes, and forms from throughout the webui to build<br>their UI, following the style guide while they do it with the existing<br>CSS.  For their navbar icon, they pull in the twitter icon here:<br><a href="https://fontawesome.com/icons/twitter?style=brands" rel="noreferrer" target="_blank">https://fontawesome.com/icons/twitter?style=brands</a><br>The icon is responsive, uses vector graphics, is properly sized, and<br>adds a negligible size to the final rootfs.<br><br>Do we reject their code because they didn't create their own icon?<br><br>I would advocate the answer is no.  I'm having trouble getting a read on<br>this, but it sounds like the answer that is being proposed is that we<br>should start enforcing icon style before merge for "consistency", but<br>I'm not really following the end goal.  If someone is wanting to remove<br>pages because the icon doesn't have a consistent style, that is easy<br>enough to do in a config in the per-machine/per-company repositories.<br>If someone wants to make the style more consistent, they can certainly<br>push new custom icons to do that.  I think master branch of the webui<br>needs to point at a web page that enables as much functionality as we<br>can.  Having to create custom icons is one more reason for people to<br>fork the codebase and not contribute back, and we want to avoid that as<br>much as possible.<br><br>Said another way, I would much rather have a first class UI feature with<br>a stock icon, than no feature at all.<br><br>-Ed<br></div></div>
<br>
</blockquote></div></div></div>