dceec76b19
This adds the favicon (and associated variants and metatadata) to the root of the site. At this point, modern browsers do support serving most (if not all) of this out of alternative paths. The advantage of serving them from the site root is: * Subpages can get the favicon (and possibly some windows/apple desktop icons) without any added HTML. This means our doc builds will automatically have favicons. The disadvantages are: * It's messy. * The preview builds don't show the changes. * If we ever change the icons, we may need to force refreshes in clients by adding more HTML tags anyway, including to the doc builds. The single advantage seems worth it to me at the moment, however. I could easily be swayed the other way. Change-Id: I1e6ca4e5e424540047265c194c6dba000aad195c
20 lines
434 B
JSON
20 lines
434 B
JSON
{
|
|
"name": "Zuul",
|
|
"short_name": "Zuul",
|
|
"icons": [
|
|
{
|
|
"src": "/android-chrome-192x192.png",
|
|
"sizes": "192x192",
|
|
"type": "image/png"
|
|
},
|
|
{
|
|
"src": "/android-chrome-512x512.png",
|
|
"sizes": "512x512",
|
|
"type": "image/png"
|
|
}
|
|
],
|
|
"theme_color": "#ffffff",
|
|
"background_color": "#ffffff",
|
|
"display": "standalone"
|
|
}
|