Re: 3d favicons

On Mon, Aug 20, 2018 at 6:27 PM Rik Cabanier <rcabanier@magicleap.com>
wrote:

>
>
> On Sun, Aug 19, 2018 at 10:26 PM Florian Bösch <pyalot@gmail.com> wrote:
>
>> On Mon, Aug 20, 2018 at 5:35 AM Rik Cabanier <rcabanier@magicleap.com>
>> wrote:
>>
>>> On Sun, Aug 19, 2018 at 9:17 AM Florian Bösch <pyalot@gmail.com> wrote:
>>>
>>>> I'd favor making it possible to target the favicon with a canvas
>>>> directly. As in:
>>>>
>>>>> <link id="icon" rel="icon" type="image/png" href="..." animated="True">
>>>>> <script>
>>>>>   window.onload = function(){
>>>>>      var icon = document.getElementById('icon');
>>>>>      var ctx = icon.getContext('3d'); // or 2D
>>>>>      ...
>>>>>   }
>>>>>  </script>
>>>>
>>>>
>>>> That way you can put in anything you want (even video) at any speed you
>>>> want (realtime if so desired, or slower), with any technique you want (2D
>>>> canvas or 3D canvas).
>>>>
>>> How would you make it 3d? It seems that would require script to run...
>>>
>>
>> Correct, a script would need to run.
>>
>>
>>> I don't think this approach will work though as the favicon is not part
>>> of the DOM and can be rendered when the document isn't even loaded (ie for
>>> bookmarks). I suspect such a change will be hard to specify and implement
>>>
>>
>> It's my impression that the majority use-case for an animated favicon is
>> in the tab when the web page is open (running a script also allows the page
>> to interact live with the icon, so that's an additional benefit).
>>
> For use-cases which cannot execute scripts (like bookmarks) they'd use the
>> fallback image provided.
>>
>
> Bookmarks, history, shortcuts, last-used pages, non-browser use. Having
> just a 2D image there would be a big limitation
>

I see it as a far bigger limitation to be locked into a single style of
rendering using mostly static content with some predefined animations and a
fixed rendering pipeline and having scant if any way to interact with the
rendering. That's why WebGL and Canvas2D was created, after all, so
browsers don't have to make those kinds of choices. See also the previous
failures to standardize and/or get used any kind of scene graph technology
(vrml et. al.).

I suppose you'd object to running a script everywhere a favicon can be
>> displayed mainly on performance concerns (who wants to run like say 200
>> scripts on a bookmark overview page or somesuch?).
>>
>
> It's not that I "object" to such a feature. My fear is that this approach
> will have many security implications.
> For instance, what is the context of the script? What is the origin? Do we
> require SSL?
>

Since the script runs on the page when the page is open it's no concern.


>
>
>> But if that is the main objection, then animated 3D favicons everywhere
>> are out no matter how you do them. Unlike static (or even moving) images,
>> which have well defined performance characteristics, 3D content can easily
>> be made to consume any amount of computing resource (for instance make a
>> favicon with 10 million triangles).
>>
>
> Yes, this IS a problem. We might have to work with Khronos on a
> web-friendly version of gltf
>

That's essentially impossible unless you'll lock in rendering to a mostly
static set of content displayed in a fixed pipeline severely restricting
polycounts and forbidding use of shaders shaders (i.e. take all
programmability away). I don't think many would be happy with that (I
wouldn't).