favicons: scriptable or static

[rcabanier]

We proposed to make a small addition to the current favicon specification that just adds support for model files. However, there's a group of people that want a more powerful interface to allow a scripted favicon.

What approach should we take? Or are both approaches viable?

[cwilso]

What would you think of making this the "scriptable favicons" issue, and the other one the "declarative favicons" one? It's probably best to have one track for each, and see which gets more traction, rather than choosing a winner up front.

FWIW, I would choose to go down the declarative route first, much as you have - just have the rel=icon point to a glTF.

[cecilemuller]

My understanding was that the script route is just a pragmatic fallback for browsers that won't support 3D natively ?

[cwilso]

I didn't read that as the intent. I read "more powerful scripted favicon", aka they want more features. If UAs didn't support a 3D format, they can already provide a 2D favicon fallback.

[rcabanier]

@cwilso yeah, that is what I understood too which is why I opened this issue. Are browser vendors interested in exploring the script approach? If so, I will open an issue.

From our perspective, scriptable favicons will be very hard to implement in our environment since they will act as sub-scenes that need to get world events. This will also have security implications because the script will know what the observer is doing.

[cwilso]

On behalf of Google, I'm certainly not pushing for exploring the scripted favicon approach at this time. :)

[TrevorFSmith]

From the email thread, it seemed like there are two paths. @rcabanier has opened an Issue for the static path. If someone else would like to pursue that dynamic favicon path, they should open a new Issue.

I'm going close this Issue and rename @rcabanier's Issue to make it clear that that Issues is for pursuing the static path.