Auto-Generating Favicons

[gauntface]

Hey all,

I've been spending some time trying to get the auto-generating favicon task into WSK and hitting a number of issues.

I've committed a few patched to gulp-favicon just to have some better error messages, but there are some fundamental oddities it that would require some more of my time to dig in a figure out the issues.

• At the moment, Chrome Stable, iOS and Windows Phone have issues.
• We can only use it with one html file at a time
• Supporting serve and serve:dist requires the use of .tmp for html files.
• Requires imagemagik and graphicsmagik from brew

One concern I have is that this uses a third party API to generate the content

At the moment I would suggest we stick with what we have and either work on the library with less time pressure or wait for it to mature and include at a later date.

What are peoples thoughts?

Cheers,
Matt

[sindresorhus]

Yeah, I agree.

One concern I have is that this uses a third party API to generate the content

Which API?

[phbernard]

Are we talking about RealFaviconGenerator's API? I'm the author of the service. If there are concerns about it, like "does it work?" or "will it still be available in a month?", I'd be happy to discuss them :)

As an aside, the API does all the image processing. When it is used, there is no need for ImageMagick locally.

[sindresorhus]

The main problem is the requirement on being online. There's also concern of future availability yes.

[gauntface]

It's not concern over whether it works, but it's unclear where problems lie at the moment between gulp-favicons, favicons and real-favicons modules.

Then there is the online requirement and I don't how hard it would be to propose changes should something new come out.

For me, it's essentially an unknown is all.

[sindresorhus]

Pretty sure all this can be done in vanilla JS without an online service or native/binary dependencies.

[gauntface]

Agreed. Just requires someone to maintain the list of required icons etc and in a flexible enough way that people can use it.

[phbernard]

Generating a multi-platform favicon is more than scaling a picture to various resolutions. Each platform comes with its own guidelines and it is important to follow them.

For example, the desktop favicon often uses transparency. But iOS does not support transparency for the Touch icon. When the Touch icon is transparent and the user adds the web site to home screen, iOS fills the transparent regions with black. Clearly not the expected outcome.

Another issue, often combined with the previous one, is the need of margins. The original picture content sometimes "touches" the edges of the picture, as it is the case with Github favicon. Such picture can be used as desktop favicon as is. But on iOS, this generates poor results. Margins must be added around the original picture.

Yet another issue, iOS crops the corners of the Touch icon to create an icon with rounded corners. For some pictures, this leads to poor results, too. For example, in the favicon of the Ruby web site, the tip of the ruby matches the bottom right corner of the picture. Use this picture as is as the Touch icon and the tip is gone once added to homescreen.

This is just for iOS. Each platform comes with its constraints and guidelines. This is what RFG tries to address, by providing limited but sensible settings for each platform.

So there are three issues about RFG:

Obviously, there is nothing to do about the "online" issue. RFG won't help if you're in a plane.

Regarding the availability of the service, I'm willing to make it last. I really want it to be part of every web dev and web designer toolkit (alright, a small part) Yet I'm just a guy and my willingness may not be the kind of guarantee you are looking for :-)

About the various modules, I guess @haydenbleasel and I should talk about it to figure out what should be done.

Of course, I completely understand that each of these issues can be blocking. If so, maybe RFG could be offered as a "plan B"? Just let me know.

[haydenbleasel]

Basically what Philippe said.

@gauntface I'll have a look into supporting multiple HTML files. Also, I'll talk to Philippe about moving Apple Startup Images into the API call so we don't need any local dependencies (IM and GM) anymore.

@sindresorhus Favicons used to produce all icons using just ImageMagick because I couldn't find a pure JS library for resizing images (easyimage, sharp, etc. all require IM or GM). The main reason I switched to RFG though is Philippe does a stellar job keeping everything up to date. I've seen all the guidelines and docs he has to go through for each favicon platform - pretty stringent stuff.

I did toss up a lot before switching to RFG but it just made more sense: outdated icons with little options that doesn't require an internet connection, or bleeding-edge icons with full support that's handled for us but does require an internet connection.

[gauntface]

I know RFG is an awesome source for getting the right icons and up to date icons - please don't think I'm knocking your service, I've used it in the past.

It's just right now it's not a good fit. Tbh I hadn't even considered the offline case until Sindre mentioned it.

I'm also struggling to see how we could handle resizing images without a native binary......

At the moment we've done ok with just the favicons being pre-generated and using sketch it's insanely easy to pump out various sizes and versions, it may be a case we recommend either Sketch with a set-up file or RFG for people wanting to change, which quite a few people aren't doing at the moment.

[sindresorhus]

I'm also struggling to see how we could handle resizing images without a native binary......

https://github.com/nodeca/pica

It will be somewhat slower than native, but can be fixed caching. Having to install dependencies are way worse.