[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 1:39 PM, Thor Harald Johansen <email@example.com>
Really? Well, somebody should fix that then, basically. I don't believe the HTML standard requires documents to be served with HTTP
You need that anyway in Chrome if you're loading any textures, since it
treats them as not same-origin.
The protocol doesn't matter. The issue is that the Chrome folks don't want a script in "~/foo.html" to be able to read the contents of any other files in the same directory (eg. ~/.mypasswords). They extend this to all files, whether they're loaded with <img> or XHR or anything else. (I disagree with this policy, but they've made up their mind.)
(Note that this doesn't mean you can't use <img> locally in HTML; you can, of course. What it means is that you can't do anything which would allow scripts to see its contents. The only way to prevent WebGL from doign that is to prohibit loading images like this into textures at all.)
It has evolved to be that way. Should've been designed for it from the get-go. I like how nobody thought a platform API might need a way of, you know, loading files? :p Then again, hindsight is 20-20.
(As web API cruft goes, this hardly registers on the scale...)
Well, so long as these policies stay the same, XHR isn't useful in this scenario, is my point.
The point is that *no* API is going to fix this. If you added a way for <script> to load GLSL scripts, it would be prohibited in this scenario just as much as XHR. This isn't something we can "fix", because it's by design.
At one point, somebody expressed, in a manner that sounded quite authoritative, that no, we're not meant to do it that way, because a GLSL script is not meaningful to the browser in any way.
I disagree. It's harmless, and it's guaranteed to work per spec as long as you use a @type attribute that the browser won't treat as a supported script. (It might be nice to have standard MIME types for this--as the OP suggested--but it's not terribly important.)
On Mon, May 21, 2012 at 1:57 PM, Gregg Tavares (社用) <firstname.lastname@example.org>
I don't think anyone has the authority to dicate how you structure your code. People have opinions. Some like 1 class per file. Some like related classes in the same file. Some like one giant file. Some like hanging braces, some like braces on a separate line. Some like CamelCase, some_like_underscores. Some like one var statement per function. Some like 1 per variable. Some like them declared at the top of the function. Some like them declared near first use.
Not really: some uses of HTML tags are genuinely wrong. I don't think this particular use is, but it's not merely a style choice.
For example, it would be wrong--and I hope at least *this* is uncontroversial--to stash scripts in <div hidden id=script>...</div>.
On Mon, May 21, 2012 at 2:13 PM, Thor Harald Johansen <email@example.com>
"When used to include data blocks (as opposed to scripts), the data must be embedded inline, the format of the data must be given using the type attribute, the src attribute must not be specified, and the contents of the script element must conform to the requirements defined for the format used."
So, HTML5 basically approves of using SCRIPT tags for including data blocks. If anybody ever discourages this usage from now on, I'll just refer them to that paragraph.
Note that HTML saying "this particular construct must work in this way" doesn't necessarily mean that it's also correct to do so. There are tons of uses which HTML prohibits, but which also have defined behavior. These are conformance requirements--you can ignore them if you want, as the behavior if you do so is (usually) well-defined, but most of the time you shouldn't.
(I don't know if there are any conformance requirements that advise against doing this--this is just a caution.)
2. Thus, you can't work with the assumption that XMLHttpRequest will work when documents and resources reside on the local file system.
Again, this has nothing at all to do with XHR. This is a low-level security policy. You can't introduce a new API to try to work around it, because any such API in Chrome is going to follow the same policy.
5. XMLHttpRequest thus implicitly requires documents and resources to be served via HTTP, as the real-world practical situation is today.
This is an odd conclusion. You can use any supported protocol, eg. HTTPS or SPDY. You seem determined to blame XHR for something that's not its fault. There are no workarounds at this level, because "workaround" means bypassing a security policy that Chrome implementors have instituted intentionally.