<span style="color:navy"><span style="font-family:Prelude, Verdana, san-serif;">Hi Simon,<br><br>These concerns are a part of this proposal, but if we collaborate without dissent, a file format can be chosen/devised, and browser vendors will implement the spec over time, and find different solutions to the same end, I am sure.<br><br>I see it as a case of the chicken or the egg.  If all these perpheral technologies existed, we likely would not be having this discussion because it would be a non-issue.<br><br>Mapping content onto the 3D media is a feature I have thought about also and do need desperately in my design work.  However, that is not appropriate for HTML to handle.<br><br>You'll probably find it in CSS, something to the tune of 'div { map-model: url(sphere.xml) stretch etc etc }' and associated properties.<br><br>Though this is a bit tangential to the goal of this proposal, a definition language for 3D models could define faces which are content mappable.  Speaking totally of-the-cuff for the sake of clarity:<br><br>&lt;face id="content-face" etc etc /><br><br>...and in CSS:<br><br>map-model: url(cube.xml) content-face stretch etc etc;<br><br>-Brian<br><br></span><span id="signature"></span><hr align="left" style="width:75%">Simon Fraser wrote:<br><br>On Nov 2, 2009, at 4:26 PM, Brian Blakely wrote:

<br>

<br>> * Though it does not have properties for clipping, Webkit's proposed

<br>> implementation of 3D CSS does have them for perspective.  Clipping,

<br>> lighting, texture stretching and additional considerations could also

> be a part of that spec, but those are discussions for the CSS WG.

<br>>

> Without a 3D media element, none of that work can be done.

<br>

<br>Implementing your proposal would require that the model and surrounding

<br>CSS-transformed content be implemented via the same 3D engine, sharing

<br>a common coordinate system. That vastly increases the burden placed on

<br>an implementor of 3D transforms: suddenly wafers in space are non longer

<br>sufficient, and you need a new engine with support for all the features

<br>required by your &lt;model /> content (which also needs to be specified  

somewhere).

<br>You can't just glue a 3D-rendered model into an environment with  

<br>CSS-3D-transformed

HTML elements and expect them to share a common 3D space.

<br>

<br>> * This proposal of a model  can be considered a direct 3D analog to a

<br>> PNG, and its height and width could certainly be modified in the X-Y

<br>> axes on which 2D elements live, affecting document flow in that

<br>> fashion.

<br>

<br>A 3D analog for &lt;img /> is a fine goal, but the primary issue is that  

<br>there is

<br>no 3D file format which is accepted as a standard for this kind of  

<br>use. Even

<br>if there were, the analogy breaks down because 3D is structured data;  

<br>the author

<br>wants to be able to address certain objects in the 3D scene in order to

<br>animate them, or do click handling on them, or whatever. There is much  

<br>more

<br>complexity here than there is with images. In this sense, &lt;model> is  

<br>as much

a black box for 3D as WebGL on a &lt;canvas> is.

<br>

<br>A further issue with this proposal is that it doesn't address another  

<br>request,

<br>which is to integrate HTML content into a true 3D scene (e.g. a &lt;div>  

<br>mapped

onto a sphere, with operational hit testing etc).

<br>

<br>> * Webkit's implementation of CSS does not remove 3D-ified elements

<br>> from the document flow, the perspective of that flow is merely changed

<br>> only for the affected elements.  3D and 2D elements can exist

> side-by-side that way as well.

<br>

<br>Simon

<br>

<br></span>