<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
<br>> be a part of that spec, but those are discussions for the CSS WG.
<br>>
<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  
<br>somewhere).
<br>You can't just glue a 3D-rendered model into an environment with  
<br>CSS-3D-transformed
<br>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
<br>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
<br>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
<br>> side-by-side that way as well.
<br>
<br>Simon
<br>
<br></span>