WebUI Fonts

[Derick]

>
> 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190129/ca02184f/attachment.html>