W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

[Bug 12715] When used to include data blocks (as opposed to scripts), the data must be embedded inline

From: <bugzilla@jessica.w3.org>
Date: Fri, 04 Nov 2011 20:01:08 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RMPwq-0008U7-V0@jessica.w3.org>

--- Comment #6 from piersh@hotmail.com 2011-11-04 20:01:07 UTC ---
(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.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

Imagine if the same restriction applied to <img>.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 4 November 2011 20:01:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:08 UTC