ready and complete events/Promises for responding to source file availability etc

[zachernuk]

Irrespective of where it goes in the future, a V1 element should obtain its contents through an asset file. In order for an author to construct a compelling experience, they'll need to know both:

• when the bytes of an asset file are loaded,
• and when whatever parsing process has concluded, such that the is ready to represent a 3D object.

These would be useful to be available both as Promise-based moments in the lifecycle of the object, as well as events that can be listened to. We have the byte-stream moment exposed as complete and the first renderable moment as ready. Is this adequate coverage? Are the names the most web-appropriate?

[zachernuk]

/agenda

[Yonet]

Apologies for adding this issue late to our meeting agenda. For anyone interested, meeting minutes for the discussion are available here.

[marcoscaceres]

Related also whatwg/html#10077

Note that this can't really deviate too much from what's in HTML already with respect to <source> selection.... thought we are looking to update that algorithm for media elements (#13).

[zachernuk]

/agenda
Now that we've got multiple folks planning an implementation, we should check back in on this!
Tentatively, I think we need some signaling from the element about four major moments:

• Model is parsed and renderable,
• Model has hit some failure preventing it from becoming renderable,
• Environmentmap is parsed and renderable,
• Environmentmap has failed to become renderable.

These could be promises with an await/catch, or events (or both).

If we wanted to pursue a CSS-based mechanism for specifying an environment map, would that change the recommended presentation of the environment map states?