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

Representing Spatial Icons for WebApps #763

Closed
raviramachandra opened this issue Apr 26, 2019 · 10 comments
Closed

Representing Spatial Icons for WebApps #763

raviramachandra opened this issue Apr 26, 2019 · 10 comments

Comments

@raviramachandra
Copy link

As a part of immersive-web group, there is a proposal to use spatial / 3D favicons for immersive-web pages/apps. See explainer here: https://github.com/immersive-web/spatial-favicons/blob/master/explainer.md

WebApps manifest today has "icons" member in the manifest, but is restricted to "Image Resources" as per spec. Our initial idea was to "re-use" this member to spatial icons as well, except that the mime type will be a non-image mime type and the sizes will have additional dimension. But the WebApp manifest explicitly says: "Image Resources" and there is an associated algorithm to handle intelligent fetching on need basis.

There are couple of approaches:

  1. Extend the "icons" member to include Non Image Resources.
  2. Introduce a new "spatial-icon" member to avoid any confusion and let the "platform"/ User Agent make an appropriate decision on which resource to use.

We are open to other ideas and hoping to get some feedback from WebApp manifest spec authors.

@marcoscaceres
Copy link
Member

I think 1 should be sufficient:

{
      "src": "icon/some-3d.format",
      "type": "application/some.3d.format"
}

The type can differentiate... the sizes don't matter.

@raviramachandra
Copy link
Author

raviramachandra commented Apr 26, 2019

@marcoscaceres a followup question: Should we add some kind of Note that the "icons" array may contain non-image resources for Immersive Web usecases ?
"sizes" is an important requirement that immersive web community had brought up. Since 3D assets have order of magnitude higher file size, the "sizes" attribute would serve as a reference to the platform/UA to download an appropriate asset for the usecase.

This is how we intended to use that:

{
    "src": "asset/high-lod.glb",
    "type": "model/gltf-binary"
    "sizes": "60x60x60"
},
{
    "src": "asset/medium-lod.glb",
    "type": "model/gltf-binary",
    "sizes": "30x30x30"
}

@marcoscaceres
Copy link
Member

ok, so we would need to modify sizes to support a third dimension. The sizes processing algorithm is deferred to HTML link rel icons sizes attribute... could HTML pages also use 3D icons?

@cwilso
Copy link

cwilso commented Apr 29, 2019

yes, HTML pages could use 3D icons too.

Also - Ravi, I seem to recall we discussed that "sizes" was really "detail level", and maybe an arbitrary XYZ bounds wasn't the right way to capture that?

@marcoscaceres
Copy link
Member

We discussed this at TPAC. The starting point would be to file a bug with the HTML spec:

You need to get HTML to support "XxYxZ", then Web Manifest will just work based on what HTML does.

@christianliebel
Copy link
Member

You need to get HTML to support "XxYxZ", then Web Manifest will just work based on what HTML does.

Related definition: https://html.spec.whatwg.org/multipage/semantics.html#attr-link-sizes

@kenzkiran
Copy link

kenzkiran commented Sep 19, 2019

@marcoscaceres @christianliebel I will open an issue on HTML spec.
@cwilso Yes, sizes analogous to quality (or LOD). We can resolve that here:
immersive-web/spatial-favicons#5

@fallaciousreasoning
Copy link
Collaborator

fallaciousreasoning commented Sep 20, 2019

The results of the discussion are here. As this is going to be discussed in the HTML spec, shall we close this?

@aarongustafson
Copy link
Collaborator

I feel like it’s ok to leave this for now and we can migrate it to the ImageResource repo so (once it lands in HTML) we can include an example spatial icon.

@aarongustafson
Copy link
Collaborator

Closing in favor of w3c/image-resource#27

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

7 participants