EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Could you elaborate? Why is this a bug?

mass-move component to LC1

Is there some reason that this functionality was removed from html?

It seems to me to be a shame to disallow non-inline, non-'text/javascript' script blocks.

I'd like to be able to do this:

    <script id="fragmentShader" type="x-shader/x-fragment" src="fragmentShader.cg" onload="compileShader(this);"/>

But the spec doesn't allow it. Instead I have to jump through XHR hell just to load some text. :(

The use case is supported (search for "data block" in the spec around <script>). However, type="" must contain a valid MIME type, and x-shader/x-fragment is not a valid MIME type. You could mint something like text/x-fragment-shader, or use application/octet-stream which is valid and is guaranteed to not be interpreted as a scripting language by UAs.

Oh wait. "data block" needs the data embedded inline. Having it external with src="" won't work since the script isn't fetched if type is not supported. IIRC, browsers converged on not fetching such scripts for perf reasons. However, I guess a new attribute could be minted to explicitly enable fetching external (but same-origin) data blocks and making them available to scripts for reading, as an alternative to XHR.

Why is XHR not good enough?

(In reply to comment #4)
> The use case is supported (search for "data block" in the spec around
> <script>). However, type="" must contain a valid MIME type, and
> x-shader/x-fragment is not a valid MIME type. You could mint something like
> text/x-fragment-shader, or use application/octet-stream which is valid and is
> guaranteed to not be interpreted as a scripting language by UAs.

I'm sorry, but "x-shader/x-fragment" IS a valid MIME type, and acceptable in this usage, according to

  http://www.w3.org/TR/html5/scripting-1.html#attr-script-type
  http://www.w3.org/TR/html5/infrastructure.html#valid-mime-type
  http://www.ietf.org/rfc/rfc2616.txt, section 3.7


The MIME type is not the issue.

The issue is that for some reason (that isn't given in the spec), external script blocks are only allowed for "text/javascript"

> browsers converged on not fetching such scripts for perf reasons

Doesn't the 'defer' attribute, and 'onload' events cover this? besides, for synchronous cases, separating fetch from parse solves most of the perceived performance issues.

> Why is XHR not good enough?

XHR works, but it's a programmatic one - an ugly one at that.

What I'm suggesting is that if a seemingly arbitrary restriction is lifted (modulo security considerations) then a simple, declarative solution reveals itself.


Imagine if the same restriction applied to <img>.

Reopening to let the editor consider the request.

(In reply to comment #6)
> Doesn't the 'defer' attribute, and 'onload' events cover this? besides, for
> synchronous cases, separating fetch from parse solves most of the perceived
> performance issues.

The problem is that browsers don't want to download a script that won't be run. (Some pages use bogus type="" and don't use it as a "data block", and there it's just wasted bandwidth and time.)

> Imagine if the same restriction applied to <img>.

<img> can't be used for data blocks, so I don't follow.

I don't understand what I'm supposed to be considering here.

Can you restate the problem succinctly? What is the use case?

If the use case is "I want to download some data file to use in my script", then that's what XMLHttpRequest is for, why is it insufficient?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: see commnent 8

why is XMLHttpRequest not sufficient?

1) it only works over HTTP. other URL schemes aren't supported.
2) it is imperative-style, as opposed to declarative.

HTML is a markup language, not a programming language.

the use case is in comment #3
  https://www.w3.org/Bugs/Public/show_bug.cgi?id=12715#c3

consider that simple one-liner compared to the XHR nightmare you have to jump through. what happens if you want to run the content from a non-http url scheme (file://) ?

(In reply to comment #10)
> why is XMLHttpRequest not sufficient?
> 
> 1) it only works over HTTP. other URL schemes aren't supported.

Incorrect. XMLHttpRequest in neither restricted to XML nor HTTP.

> what happens if you want to run the content from a non-http url scheme (file://) ?

In Firefox, if the file:// URL is considered to be same-origin with the document that uses XHR, XHR is allowed to GET the file:// URL.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see comment 11.

The proposal in comment 3 doesn't say how the script would get to the data. I don't see why it would end up being any less code than using XHR.

I also don't see any advantage to this being declarative rather than imperative, since we're talking about ways to get data to a script.

> The proposal in comment 3 doesn't say how the script would get to the data.

the <script> block is a node in the DOM and it's content can be accessed using the DOM API - as was shown in comment #3. The spec, however only allows the use of inline script blocks. All I'm suggesting is that this seemingly arbitrary restriction be lifted, or at the very least justified.

> I
> don't see why it would end up being any less code than using XHR.

Again, please see comment #3. Maybe you missed it because it's so simple. That's the point, somewhat.

This is the entirety of HTML code required to load an external shader definition and call the 'compileShader' function when the load has completed. The 'defer' or 'async' attributes could be used here to control timing.

I'm not going to attempt to post the XHR code. I'd probably get it wrong without any means to verify its correctness.

> I also don't see any advantage to this being declarative rather than
> imperative, since we're talking about ways to get data to a script.

This isn't about getting data to a script. It's about executing script on data.

Why is declarative better than imperative? I dunno, ask Tim. This is htMl after all...