Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple sizes for the Apple Touch icon package #211

Closed
phbernard opened this issue Jan 5, 2016 · 6 comments
Closed

Multiple sizes for the Apple Touch icon package #211

phbernard opened this issue Jan 5, 2016 · 6 comments

Comments

@phbernard
Copy link
Contributor

Currently, RFG creates something like 10 Apple Touch icons:

  • apple-touch-icon-57x57.png to apple-touch-icon-180x180.png (9 icons).
  • apple-touch-icon.png
  • apple-touch-icon-precomposed.png

These pictures are built and declared after Apple specs.

The situation

Pros:

  • The browser finds the right icon for its screen:
    • We can be confident the icon won't be blurred or anything when scaled down. This is especially important when the original picture as a particular style (eg. pixel art -> use something like Nearest Neighbor).
    • It's quicker than scaling down. Well, this shouldn't make much difference...
  • When files are in root: various browsers find what they are looking for at first sight (eg. /apple-touch-icon-74x74.png):
    • Quicker, the user experience maybe be (slightly!) improved.
    • Less annoying 404 errors in the logs.

Cons:

  • There are a lot of files. When in root, they pollute the root directly, which is an issue for the web developer who always has these annoying files in plain sight. This issue can be mitigated (web server configuration to map a touch-icon directory to the root directory, use Gulp/Grunt to move these files at deployment time...).
  • There are a lot of HTML declarations:
    • This is 700+ bytes at the top of each page. Definitely not good, especially for this nice-to-have.
    • This is an issue for the web developer: these declarations are ugly. They hurt my feelings.

Solution

Naive solution: two policies, the "light package" and the "full package". Sounds good. However, this is not that simple. For example, if files are in the root directory, I would like:

  • Only one declaration (I want light HTML).
  • All icons: apple-touch-icon.png, apple-touch-icon-144x144.png, apple-touch-icon-precomposed-120x120.png... after all, these files don't annoy me (I use Gulp to put them in root at the last minute), they will prevent as many 404 as possible...

This leads to two settings:

  • The amount of icons:
    • Only one (apple-touch-icon.png, 180x180)
    • The classic (apple-touch-icon.png, apple-touch-icon-ZZZxZZZ.png and apple-touch-icon-precomposed.png)
    • The full package (apple-touch-icon.png, apple-touch-icon-ZZZxZZZ.png, apple-touch-icon-precomposed.png and apple-touch-icon-precomposed-ZZZxZZZ.png)
  • The amount of declarations:
    • Only one (apple-touch-icon.png)
    • The classic (apple-touch-icon-ZZZxZZZ.png)

These settings depend on the location of the files (root or not) and possibly the scaling algorithm that was chosen by the user of RFG. Some testing must be done in this area.

Note: declaring the precomposed icons is quite useless. It was useful before iOS 7 when you didn't want iOS to manipulate your icon (the gloss effect). RFG doesn't (and won't) let you play with this deprecated feature.

Implementation

The implementation must meet a requirement: all this must be kept as simple as possible. Most users just want icons that work, not tedious choices.

To do this, we add an "Options" tab in the iOS section of the icon editor. In this tab, the default selection matches current RFG behavior, or maybe a lighter package (to be decided after the experiments with the scaling algorithm).

Right now I'm not comfortable with the next steps until I know more about the scaling algorithm issue. So I consider these experiments as the next TODO to go.

@phbernard
Copy link
Contributor Author

Done. Conclusion: you can usually provide a single, 180x180 icon. iOS scaling is fine. The only exception is when the wanted scaling algorithm is particular (eg. Nearest Neighbor). But even in this case, although iOS scaling is not perfect, it's okay.

It's all here: https://realfavicongenerator.net/blog/how-ios-scales-the-apple-touch-icon/

@phbernard
Copy link
Contributor Author

Implemented in branch package_0_13

@phbernard
Copy link
Contributor Author

Deployed yesterday

@ArmorDarks
Copy link

@phbernard Thanks for the efforts!

I've noticed, that not a while ago RFG yielded following:

<link rel='apple-touch-icon' href='/apple-touch-icon.png'>

but recently it started to add sizes='180x180' explicitly to it:

<link rel='apple-touch-icon' sizes='180x180' href='/apple-touch-icon.png'>

I wonder, is it really needed? What reason stands behind that change?

@ArmorDarks
Copy link

@phbernard? Anyone?

@gianpaj
Copy link

gianpaj commented May 10, 2023

@phbernard Thanks for the efforts!

I've noticed, that not a while ago RFG yielded following:

<link rel='apple-touch-icon' href='/apple-touch-icon.png'>

but recently it started to add sizes='180x180' explicitly to it:

<link rel='apple-touch-icon' sizes='180x180' href='/apple-touch-icon.png'>

I wonder, is it really needed? What reason stands behind that change?

looks like this is not needed

When using one image, there is no need to use the sizes attribute.

https://github.com/webhintio/hint/blob/main/packages/hint-apple-touch-icons/README.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants