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