[whatwg] Web Applications and 3D

[Matthew Raymond]

Jim Ley wrote:
> On 4/29/05, Matthew Raymond <mattraymond at earthlink.net> wrote:
>>   The examples I've seen with regard to DirectAnimation are done
>>through an <object> and use an ActiveX control, so standardizing such an
>>interface isn't appropriate. 
> 
> Could you explain why?  ActiveX is just the mechanism windows uses for
> componentisation - WHAT-WG is already standardising things implemented
> as ActiveX in IE.

      Plug-ins are by their very nature optional. Why would we want to
move functionality into <object> elements, which are by definition
external objects like plug-ins? HTML should NEVER specify the
functionality of an external component, regardless of how many machines
that component is installed on. Besides, if UA vendors really wanted to
make DirectAnimation specifically work under their own user agents, they
wouldn't need a WHATWG spec to tell them to do so.

> If you're saying that the creation mechanism for a
> 3D canvas is wrong - there's something wrong with using OBJECT, and we
> need to use CANVAS3D instead, then perhaps you might have a point, I'd
> like to hear a lot more motivation for inventing new elements for
> this, given the problems with new elements highlighted so often by Ian
> and others.  However the creation is one minor part of the 3D API, and
> it's the API I was talking about.

      The <object> element specifically suggests an external component.
Therefore, any semantically appropriate implementation that uses
<object> would be a plug-in, and last time I checked plug-ins were
optional. By contrast, <canvas> (and related suggestions) would be
implemented directly in user agents, ensuring that all user agents that
adhere to the standard have support, regardless of what plug-ins are
installed.

      Some have suggested not limiting the <canvas> graphics APIs to a
single element called <canvas>, but instead allowing the APIs to work on
any element, or a specific set of elements. In either case, the API and
the contexts would be largely the same, so it doesn't matter from the
standpoint of developing the "3d" context.

>>We may want to be able to implement the "3d" context for
>><canvas> on top of DirectAnimation.
> 
> Could you describe why this might be a motivation, what do you see as
> so lacking in the current implementation that it's not takeable as a
> whole?

      Generally, the use of <object> is what I object to. In theory, you
could create a Microsoft-specific "ms-3d-direct-animation" context, for
instance, that you could use with <canvas> to do the same thing as the
use of the <object> element does now. I may try to include parts of the
DirectAnimation APIs in the "3d" context. I'm going to have to research
it first, though.

>>>As always, I'm still waiting to hear the use cases for both 2D and 3D
>>>javascript drawing  - "Quake like games" which is the only example
>>>I've heard so far, may be a use case, but it's not yet been explained
>>>why an HTML document is appropriate for such a game.
>>
>>   I've already suggested the use of 3D for previewing a custom ordered
>>product such as a motorcycle.
> 
> All drawn in client-side javascript?  - remember the use cases I'm
> looking for are not use cases for 3D, but for use cases for a 3D
> canvas in a webpage, that has no state, and relies wholly on all the
> information being drawn by javascript onload or later?
> 
> I do not accept that the above is a practical use case.

     How so? A "3d" context would undoubtedly have functions for loading
complete textures and models from files. Even if you assume the files
are huge and take an enormous amount of time to load, how is using a
plug-in that much better for the user experience?

     Also, there have been suggestions to base much of the "3d" context
on OpenGL ES, which has extensive support for vertex arrays. It is
likely that we will design the context to use arrays extensively. It
won't be a situation where you have to issue a command to draw every
single polygon and specify every color and texture coordinate. Once you
set up some arrays, you'd simply use a "DrawArrays" method or something
like that.

>>Perhaps you
>>want to see a 3D representation of the hotel room you plan to book. Same
>>for real estate. If you're ordering a ticket from a concert, wouldn't it
>>be nice to see what the stage will look like from your seat?
>>
>>   Need I go on?
> 
> Yes, because none of these are being addressed by a 3d drawable canvas
> and a javascript API, the simple creation of any of these is not
> appropriate to a programming language, they are all declaritive, and
> the WHAT-WG individual has made it clear that a declaritive 3D
> mechanism is not on the agenda.  If that is all that we get, then none
> of those use cases will be fulfilled.

    If by declarative you mean like X3D, then WHATWG clearly shouldn't 
add such markup to HTML because it would duplicate the work of another 
group unnecessarily.

    I really don't see where you're going with this, though, since 
DirectAnimation isn't much more declarative than the <canvas> solution. 
While I think, for some purposes, X3D might be better suited, I fail to
see how a 3D drawing API can't fit the listed use cases. After all, at 
some point X3D markup has to be parsed and fed into a 3D API.

> So I'm still searching for what use cases a javascript API to a 3D
> canvas provides, it's been possible in IE since 1997, I've done lots
> with it in that time, yet I've never come across a real wbe situation
> that has used it - I used it once to write some very quick pages that
> were 3D to be used on some notebooks at a trade show, back when
> notebooks having 3D graphics cards was a selling point.

    If I'm reading this right, you're saying that no one uses 
DirectAnimation, and perhaps 3D in general, so why introduce a 
potentially competing standard when there's no real demand for the 
original? Feel free to make a more detailed argument about this, as I'd 
be interested in hearing some information about this, but my point of 
view at the moment is that a lot has changed since 1997 with regards 3D 
APIs and hardware on both the desktop and handheld devices.