12715 2011-05-21 06:03:55 +0000 When used to include data blocks (as opposed to scripts), the data must be embedded inline 2012-01-13 06:03:42 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#the-script-element P3 normal --- 1 contributor ian hsivonen ian mike piersh public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 48671 0 contributor 2011-05-21 06:03:55 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/ Section: http://www.whatwg.org/specs/web-apps/current-work/#the-script-element Comment: When used to include data blocks (as opposed to scripts), the data must be embedded inline Posted from: 72.52.65.50 User agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 49457 1 ian 2011-06-10 22:44:00 +0000 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? 53616 2 mike 2011-08-04 05:15:45 +0000 mass-move component to LC1 59573 3 piersh 2011-11-03 17:29:05 +0000 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. :( 59610 4 zcorpan 2011-11-04 06:25:01 +0000 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. 59612 5 zcorpan 2011-11-04 06:32:15 +0000 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? 59637 6 piersh 2011-11-04 20:01:07 +0000 (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>. 59663 7 zcorpan 2011-11-05 23:07:28 +0000 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. 60859 8 ian 2011-12-02 23:13:15 +0000 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? 61108 9 ian 2011-12-07 20:04:44 +0000 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 62278 10 piersh 2012-01-04 18:41:23 +0000 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://) ? 62294 11 hsivonen 2012-01-05 08:13:47 +0000 (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. 62641 12 ian 2012-01-13 01:15:31 +0000 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. 62651 13 piersh 2012-01-13 06:03:42 +0000 > 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...