Open Buzut opened 7 years ago
Agreed. Thank you for reporting.
I need to test this thoroughly in order to upgrade the editor.
Thx to you! It's of great help (I discovered your tool via your article on Putain de code 💯)
Putain de code? But alors you are French? :)
Indeed! Je suis Français ;)
I don't think either of these tags fall into what RealFaviconGenerator is trying to do – they're more specifically for web apps which are intended to be pinned to the home screen. apple-mobile-web-app-capable
, for example, doesn't have any effect except for if the page is pinned, but when the page is then opened from the home screen it will have no browser chrome.
Some apps do want this behaviour, but I would expect if you're building that kind of app (usually using features like local workers, HTML5 app manifests etc) then you'd be able to find these tags yourself. If you're not explicitly doing this, it would break the expected UX.
Sure it goes beyound the simple favicon matter, but don't we also have a configuration for splash screens on Android? That seem to be app related too…
That's why having these Apple tags looks sensible to me. Nevertheless, I agree that it should be an opt-in function.
My opinion is that there are two approaches:
"Add to home screen" on Android Chrome is supported by the WebApp manifest, clearly intended for apps. Google says nothing different: "Since Chrome 31, you can set up your web app to have an application shortcut icon added to a device's homescreen". App again.
However, RFG has been systematically generating a web app manifest for two years. It is used by beginners (eg. WordPress admins with no HTML knowledge) and seasoned web developers. And I think I never got a feedback such as "Manifest is for app only, stop doing this". My understanding is that web devs are happy to have the right icons and to choose the status bar color, whatever they are coding a shiny new app or a plain old web site.
As an aside, RFG takes the "app" aspect of the manifest into account by patching an existing manifest with the icon stuff, leaving the rest to the developer (see existing_manifest
). There is an example of this for the Google Web Starter Kit.
So in the end, and even if one can argue that it is definitely not their primary role, I think it is legit for a site to use apple-mobile-web-app-capable
and friends for aesthetic purpose. Regarding RFG in particular, that would just make iOS consistent with Android Chrome.
My concern would be that (as far as I can tell) on iOS setting these parameters will cause iOS to assume you want to run the site as a separate 'app', with its own presence in the task switcher distinct from Safari.
If there is an option, it would have to have "do not set these things at all", as opposed to explicitly setting them to a false value.
On 12 Jan 2017, at 11:12, Philippe Bernard notifications@github.com wrote:
My opinion is that there are two approaches:
App only As you mention @jacksonj04 , these markups are app-related and RFG has nothing to do with apps. Using them suggest a kind of UX (eg. offline capabilities) classic web sites do not provide. Mere UI settings We are talking about showing the status bar or not, and its color. Nothing fancy. "Add to home screen" on Android Chrome is supported by the WebApp manifest, clearly intended for apps. Google says nothing different: "Since Chrome 31, you can set up your web app to have an application shortcut icon added to a device's homescreen". App again.
However, RFG has been systematically generating a web app manifest for two years. It is used by beginners (eg. WordPress admins with no HTML knowledge) and seasoned web developers. And I think I never got a feedback such as "Manifest is for app only". My understanding is that web devs are happy to have the right icons and to choose the status bar color, whatever they are coding a shiny new app or a plain old web site.
As an aside, RFG takes the "app" aspect of the manifest into account by patching an existing manifest with the icon stuff, leaving the rest to the developer (see existing_manifest). There is an example of this for the Google Web Starter Kit.
So in the end, and even if one can argue that it is definitely not their primary role, I think it is legit for a site to use apple-mobile-web-app-capable and friends for aesthetic purpose. Regarding RFG in particular, that would just make iOS consistent with Android Chrome.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Sure! I almost never played with these options. So the first step will be to test the various settings and find out what is the most sensible default. "Nothing at all" sounds like a good plan :)
There are several Apple related meta tags that are missing from the output. Namely
apple-mobile-web-app-capable
andapple-mobile-web-app-status-bar-style
.These tags and their usage are to be found on Safari Web Content Guide.