[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGLSL Media Type Proposal
On Mon, May 21, 2012 at 10:36 AM, Jeff Gilbert <email@example.com>
This may not be JS-interpreted code, but it is GLSL code. It would be nice to be able to pass this element (or similar) to shaderSource().
What's wrong with document.getElement("shader-vs").textContent? I've seen this in demos and used it myself for quick hacks.
(Not to mention the requirement of a local http server, which most definitely negatively impacts the pick-up-and-hack capabilities of WebGL)
You need that anyway in Chrome if you're loading any textures, since it treats them as not same-origin.
On Mon, May 21, 2012 at 11:38 AM, Thor Harald Johansen <firstname.lastname@example.org>
I'm still tempted to say that the ideal solution would be a <data> tag for sourcing any kind of data in a convenient way. XMLHttpRequest is also a bit of a misnomer these days. Who had the idea of creating a HTTP request API geared specifically toward XML anyway? Putting an XML DOM parser in the network protocol stack is ugly as hell!
Once again, nothing about XHR is specific to HTTP, no more than it's specific to HTTP. The name is purely legacy.
It also makes the assumption that a HTTP request is what you want. I'm not encouraging people to put their data on FTP servers, but the naming is incredibly non-generic, and makes requests for file:// URLs look illegal, even when some browsers allow it.
XHR is *not* an HTTP-specific API. It's perfectly normal practice and completely by design to use it for any URL.
It often won't work for file URLs, but that has nothing to do with XHR; that's a same-origin policy issue which wouldn't be solved by any other API, as it's a lower-level security policy issue.
In any case, I feel that it is necessary for us to devise a convenient, proper way of simply tossing some GLSL code into your document.
No, we don't, because you can already do it with <script>.
<script id=foo type=vertex-shader>