[whatwg] <model/>: A 3D Equivalent to <img/>

[David Workman]

I'm in perfect agreement regarding the rational behind having a model tag as
I agree with having more semantic tags in HTML. However, I don't think a
model tag would work as described as it would provide no real extra benefits
and would just confuse document authors.

The reason I feel this is basically down to the fact that 3d models don't
have a visual representation in the same way that images do. A 3d model file
is just a list of data that needs rendering into a 2d image for display.
There isn't really a standardised way to do this (not in the same way as
with images, with standardised png, jpg, bmp, etc. as well known and
commonplace formats with commonplace methods of display), and on top of that
it isn't a 3d model you a displaying, but a 2d representation (i.e. an
<img>). If the representation is static, it isn't really a 3d model as it's
just a 2d image, and if it isn't static then you need scripting support,
drawing support, rendering and the whole host of items that require
javascript hooks and would logically make such a model more suited to a 3d
canvas (which I believe is to be supported eventually under a normal
<canvas> tag). As such, I don't see a place for a <model> tag in the current
environment as a merely semantic element, and adding more than just
semantics to the tag would be overlapping it with other efforts.

David W.

2009/11/2 Brian Blakely <anewpage.media at gmail.com>

> Perfectly aware Simon, hence the proposition; a 3D model element is not an
> attempt to erase, but complement current efforts.
>
> Let me take this opportunity to clarify.  <model/> is neither redundant nor
> trampling current efforts, but filling an essential gap in the spec.
>
> This is why:
>
> 1) O3D and Khronos/Mozilla's efforts are JavaScript-based hooks into
> OS-level rendering APIs.  They are akin to <canvas/>, providing a
> non-semantic "viewport" into content.  This is good, but a new element is
> still necessary, even if you were to draw all 3D content into a <canvas/>.
> The reason is JavaScript.
>
> 2) You should not have to write JavaScript to embed 3D content.  Imagine if
> you had to set up a <canvas/> viewport every time you wanted to display an
> image.  As it is in today's flatworld, developers should be able to convey
> content with only HTML and CSS knowledge.
>
> 3) X3D is a 3D equivalent to <svg/>, not <img/>, as I am proposing.
> <model/> does not define how your 3D content will look (how <font/>-like!
> <svg/> is already flying too close to that sun).  It provides a hook into
> CSS, as well as granular, semantic control of content.  The expectation is
> that it would link to a 3D model as defined in the "src" attribute, no
> further code required.  This source could be in X3D format, or 3DS, MA,
> etc.  Whichever the vendors eventually decide to support (hopefully the same
> format :)
>
> -Brian
>
>
>
> On Sun, Nov 1, 2009 at 8:31 PM, Simon Fraser <smfr at me.com> wrote:
>
>> On Oct 30, 2009, at 6:09 PM, Brian Blakely wrote:
>>
>>  To ensure HTML remains semantic as the web makes its gradual transition
>>> to 3D rich interfaces and content, I am submitting a proposal for WHATWG's
>>> consideration.  The below examples contain HTML as it exists now, the
>>> current working standard, and finally, a combination of both concepts.
>>>
>>>
>>> Please lend your thoughts and let's discuss a more semantic and
>>> accessible use of 3D.  The fictional HTML and CSS above are just proposals,
>>> and I am not at all asserting these ideas are the best possible solution,
>>> only that there is a very real problem.
>>>
>>
>> Are you aware of the X3D and O3D efforts?
>>
>> <http://www.web3d.org/x3d/specifications/>
>> <http://code.google.com/apis/o3d/>
>>
>> Simon
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091102/b7fdeb8d/attachment-0002.htm>