This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
RFC 4329 http://www.ietf.org/rfc/rfc4329.txt does exist since April 2006. It is about "Scripting Media Types" and mandates the mimetypes "application/javascript" and "application/ecmascript" in favour to the as "obsolete" labeled "text/*" mimetypes as well as the text/x-* and application/x-* mimetypes. See also IANA Text Media Types http://www.iana.org/assignments/media-types/text/ and IANA Application Media Types http://www.iana.org/assignments/media-types/application/ . Nevertheless, (X)HTML5 seems to completely disregard this particular RFC 4329, when it comes to scripting media types and still favours and promotes the use of "text/javascript", although RFC 4329 mandates/recommends NOT to do so. Is there any good reason to just ignore that particular RFC and IANA's assign? Why does HTML5 ignore it, whereas relevant software vendors like Mozilla/Firefox, Apple/WebKit/Safari, Opera, Apache/HTTP server don't? As far as I know, all major browser vendors (except Microsoft) have adjusted their browser software to match this RFC 4329 and to comply with IANA. Even Apache.org has adjusted its HTTP server's mime.types file to match RFC 4329 and IANA. Why not (X)HTML5 either? What are the reasons? Is there actually a cogent reason NOT to follow RFC 4329 and IANA?
Not using text/javascript would be silly since text/javascript is what everyone uses.
(In reply to comment #1) > Not using text/javascript would be silly since text/javascript is what everyone > uses. How do one change that habits? Promote it, how to do it better and how to stand to the rules! :-) Your answer, applied to the eligibility and need of HTML5, would be alike: "Using HTML5 would be silly since HTML4 und XHTML 1.x is what everyone uses." :-) Lame argument, Ian, since HTML5 introduces A LOT of new stuff, elements and habits, that go far further compared to HTML 4.x and XHTML 1.x. Fostering these per RFC and IANA specified and recommended script mimetypes in HTML5 is not that challenge compared to the lot of other stuff, that is introduced as "new" in HTML5.
What does application/ecmascript add which text/javascript doesn't have?
(In reply to comment #3) > What does application/ecmascript add which text/javascript doesn't have? Assumed better handling of character encoding compared to text/* top level mimetype, for instance?
As far as I am aware, there is no difference in character encoding declaration. In particular, it's worth noting that browsers ignore the exact MIME type used with scripts; you could use image/png and it would work just as well as far as I can tell.
WONTFIX based on comments
(In reply to comment #6) > WONTFIX based on comments Reopened based on comments. Because of a still missing _cogent and strong_ reason to knowingly disregard a RFC and a decision of IETF, IANA and ISOC. If you don't agree with this particular decision of these authorities concerning RFC 4329, then I propose to go the official way to impeach and revise that decision to make RFC 4329 officially obsolete and invalid. Otherwise, try to comply with it.
The "_cogent and strong_ reason" is "everyone uses text/javascript, text/javascript works, and the other types are pointless". Just because it's an RFC, or a W3C Recommendation, or any other kind of specification, doesn't mean it's correct. Specifications get adopted or dropped on their merits, and in this case the RFC in question simply doesn't match reality. I have no interest in personally chasing up every such problem. HTML5 has a far more cases of willful violations of other specs than just this one -- e.g. we violate HTTP's requirement for honouring Content-Type, we violate CharMod's requirement for honouring encoding names, we violate RFC3986 with respect to base URL handling in certain cases, we violate ECMAScript 3's requirement with respect to the global object having to equal the global scope 'this' object, we violate RFC2046's requirement that text/* line breaks be CRLF only, we violate the URI/IRI specs when it comes to parsing IRIs and when it comes to terminology. In all these cases, the underlying specifications are just wrong, because they ignored some aspect of reality and are thus not usable as written. This is why specifications get maintained and updated. If you want to volunteer to update 4329, or any of those other specs, then please be my guest. In the meantime, I'm not going to make the HTML5 spec refer to a type that nobody understands. It is harmful pedantism.
Unless there's a problem using the "new" MIME types, HTML5 definitively should recommend using them.
The problem is that they are not what people use.
How is that a problem? If they are what the relevant specs recommend, *and* if they work?
What is a specification is for, in your opinion?
(In reply to comment #10) > The problem is that they are not what people use. Put THAT argument to (X)HTML5, Ian, (X)HTML 5 will be pointless. Because many, many people are used to use HTML 4, fever people XHTML 1.0 and even some people use HTML 3.2. And in all that cases excluded the validity issue. So why bother with (X)HTML 5 for all these people? ;-) See Comment #2. You can promote and foster it, Ian! Leading by guiding. This will be the same issue with (X)HTML5. (X)HTML5 will only be a success, if people use it. That presumes, that it will be actively promoted and fostered. Because the human nature is lazy. It's the very same with these new per RFC proposed Media Mime types. Without promotion and fostering, now one will know about it, now one will use it. That is the status quo. (X)HTML 5 will bring a big bunch of NEW things and features. Promoting and fostering these new Script Mimetypes through the HTML 5 Spec and additionally through a possible new/next Acid test, would be a big, big help to make these Mimetypes wider known and used. It's the same with the many new elements of HTML 5, which currently also are only known to a relatively small group of interested persons/parties. Please promote and foster these per RFC recommended new Mimetypes for JavaScript and ECMAScript. At least through the (X)HTML 5 spec, which could be an archetype for doing that. It is not more groundbreaking to do this, than to promote and foster all the other new elements and rules of (X)HTML 5, which will change the habits of the people and developers. If these people and developers have to change their habits and expand their knowledge anyway concerning (X)HTML 5, then adopting these new per RFC/IANA/ISOC introduced Mimetypes will be only a small domino -- a no-brainer -- among many, many other dominos to learn for these people and developers. Leading by guiding. :-)
> So why bother with (X)HTML 5 for all these people? ;-) Because HTML5 introduces all kinds of new features. What do the new JS MIME types introduce? > Promoting and fostering these new Script Mimetypes through the HTML 5 Spec > and additionally through a possible new/next Acid test, would be a big, big > help to make these Mimetypes wider known and used. Why do we want these new MIME types to be more widely known and used? How does the human race benefit from these MIME types? We only have finite resources. We should spend them on features that benefit people.
(In reply to comment #14) > > So why bother with (X)HTML 5 for all these people? ;-) > > Because HTML5 introduces all kinds of new features. What do the new JS MIME > types introduce? At least a new notation for Script-Mimetypes. Like the new (and not always easy to remember because of the plentitude of new elements) notation of some core elements of a (X)HTML 5 document. :-) > Why do we want these new MIME types to be more widely known and used? How does > the human race benefit from these MIME types? > > We only have finite resources. We should spend them on features that benefit > people. Some benefits must have been convincing enough for IETF and IANA to let pass RFC 4329 the long process of getting accepted by these formal institutions, Ian. Only because you personally don't see the reason, why that particular RFC might be useful and has passed that long (several years!) formal process (see for instance http://rfc-editor.org/pubprocess.html), in which more than one expert has reviewed and discussed the request, that does not mean, that this particular RFC is useless, pointless, invalid. Ian, the browser teams of Mozilla, KDE Konqueror, Safari and Opera and even at least the HTTP team of Apache.org did not have such problems like you in accepting and implementing these new Mimetypes of this particular RFC into their software. They simply did it. Whithout questioning the decision of IANA and IETF.
> > Because HTML5 introduces all kinds of new features. What do the new JS MIME > > types introduce? > > At least a new notation for Script-Mimetypes. What benefit does this bring to the user or the author? > Like the new (and not always easy > to remember because of the plentitude of new elements) notation of some core > elements of a (X)HTML 5 document. :-) HTML5 specifically avoids renaming any elements that already exist. We have only added new elements where there was new benefits to be had in doing so. > > We only have finite resources. We should spend them on features that benefit > > people. > > Some benefits must have been convincing enough for IETF and IANA to let pass > RFC 4329 the long process of getting accepted by these formal institutions, > Ian. Only because you personally don't see the reason, why that particular RFC > might be useful and has passed that long (several years!) formal process (see > for instance http://rfc-editor.org/pubprocess.html), in which more than one > expert has reviewed and discussed the request, that does not mean, that this > particular RFC is useless, pointless, invalid. If it's not "useless, pointless, invalid" as you put it, can you tell me what benefit it has?
(In reply to comment #16) > If it's not "useless, pointless, invalid" as you put it, can you tell me what > benefit it has? Read carefully http://www.rfc-archive.org/getrfc.php?rfc=4329 and http://www.rfc-archive.org/getrfc.php?rfc=3023 (to which RFC 4329 points at some parts, because there it is defined and highlighted likewise) especially concerning charset and encoding and the differences and vantages/disvantages of text/* and application/* media types in that particular manner. Apart of that, Ian: I don't want to discuss with you a discussion that has been done by the author of that RFC (Björn Höhrmann, whom you might know well), when he proposed that RFC to the IANA. Should we invite him to this discussion? ;-)
(In reply to comment #16) > > > Because HTML5 introduces all kinds of new features. What do the new JS MIME > > > types introduce? > > > > At least a new notation for Script-Mimetypes. > > What benefit does this bring to the user or the author? > Clarity. For an author who tries to follow specs as best I can, to be faced with two specs where one says "Do A, don't do B" and another spec that says "Do B, don't do A", what am I to do? The HTML5 spec does not live on it's own, but in a environment with all the other specs, and there's no obvious reason why the HTML5 spec should "win" such a conflict. It would at least be easier if the HTML5 spec said "Do A or B, in this context it doesn't matter".
The charset="" stuff is a non-issue, since browsers totally ignore the actual MIME type. You could use image/png and it would work just as well as text/javascript or application/ecmascript. Is there an actual benefit to the spec using the new types? There is a cost to using the new types, it makes the spec harder for people to understand. Unless there is an actual benefit to using these types, we should not jump on the bandwagon just because it's a standard. There are lots of things that get standardised. We still need to evaluate them each time. (In reply to comment #18) > > > > What benefit does this bring to the user or the author? > > Clarity. Not at all, text/javascript is far more widely understood than application/ecmascript by authors. The spec would be _less_ clear if we used the latter type. > The HTML5 spec does not live on it's own, but in a environment with all the > other specs, and there's no obvious reason why the HTML5 spec should "win" such > a conflict. This isn't about HTML5 winning a conflict. It's about us having to decide between the real world, which uses text/javascript, and an obscure RFC that almost no author has ever heard of, which says to use other types despite there being absolutely no real benefit to doing so. If it would help, I don't mind adding the new types to section 4.3.1.1 Scripting languages. I added the following to section 2.2.1 Dependencies: "The MIME type used to refer to ECMAScript in this specification is text/javascript. This is a willful violation of RFC 4329. [RFC4329]"
(In reply to comment #19) > This isn't about HTML5 winning a conflict. It's about us having to decide > between the real world, which uses text/javascript, ... and some other various (partly obscure) mimetype notations which can be found in the wild... (see also section 3 of RFC 4329): 3. Deployed Scripting Media Types and Compatibility Various unregistered media types have been used in an ad-hoc fashion to label and exchange programs written in ECMAScript and JavaScript. These include: +-----------------------------------------------------+ | text/javascript | text/ecmascript | | text/javascript1.0 | text/javascript1.1 | | text/javascript1.2 | text/javascript1.3 | | text/javascript1.4 | text/javascript1.5 | | text/jscript | text/livescript | | text/x-javascript | text/x-ecmascript | | application/x-javascript | application/x-ecmascript | | application/javascript | application/ecmascript | +-----------------------------------------------------+ > and an obscure RFC Maybe obscure for you. Less obscure for some browser and HTTP server vendors and for some web authors, who already use these new mimetypes in practise. > that almost no author has ever heard of How do you know that? Apart of that: wouldn't it be a great chance to widen that wo a broader audience with simply referring and using/promoting it in the HTML 5 Spec instead of concealing and contradicting it? > which says to use other types despite there > being absolutely no real benefit to doing so. Concerning XML and XHTML -- why and for what reason do the application/xml and application/*+xml mimetypes exist, when the text/* domain may also be sufficient? > If it would help, I don't mind adding the new types to section 4.3.1.1 > Scripting languages. I added the following to section 2.2.1 Dependencies: "The > MIME type used to refer to ECMAScript in this specification is text/javascript. > This is a willful violation of RFC 4329. [RFC4329]" Please add at least, WHY you want willful violate RFC 4329. And among that: the user should use "text/javascript", if he uses ECMAScript? You have to explain that: a JavaScript referring Mimetype for a language that isn't JavaScript but ECMAScript? When using/referring to ECMAScript, why not at least "text/ecmascript"? Ian, why not going the same way as the W3C has gone with text/html and application/xhtml+xml for XHTML? Why not use the well known key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" -- and wire text/javascript and text/ecmascript with the keywords "MAY" or better "SHOULD NOT" to comply with RFC 4329 and wire application/javascript and application/ecmascript with the keywords "SHOULD" or "RECOMMENDED" to comply with RFC 4329?
Could you please either give at least a single benefit to authors using these new types or admit that there is no such benefit? > Maybe obscure for you. Less obscure for some browser and HTTP server vendors > and for some web authors, who already use these new mimetypes in practise. It's not obscure to me, I was even consulted in its creation. It _is_ obscure to most Web authors; just go into any Web authoring forum and ask them what the MIME type for JavaScript is. > Concerning XML and XHTML -- why and for what reason do the application/xml and > application/*+xml mimetypes exist, when the text/* domain may also be > sufficient? Because the people who wrote the XML MIME type RFCs thought it was easier to introduce a raft of new types than to fix the underlying MIME RFCs with respect to default encodings. We are still suffering the problems that were caused by this fiasco. However, even this doesn't apply here, since browsers uniformly ignore the MIME type, and only look at the charset parameter, ignoring the defaults that were being worked around by the XML MIME type RFCs. > > If it would help, I don't mind adding the new types to section 4.3.1.1 > > Scripting languages. I added the following to section 2.2.1 Dependencies: "The > > MIME type used to refer to ECMAScript in this specification is text/javascript. > > This is a willful violation of RFC 4329. [RFC4329]" > > Please add at least, WHY you want willful violate RFC 4329. Done. > And among that: the > user should use "text/javascript", if he uses ECMAScript? You have to explain > that: a JavaScript referring Mimetype for a language that isn't JavaScript but > ECMAScript? > When using/referring to ECMAScript, why not at least "text/ecmascript"? You're right, using the term ECMAScript is a bit confusing. I've gone through and changed everything to consistently refer to the language as JavaScript (previously it was a bit mixed). > Ian, why not going the same way as the W3C has gone with text/html and > application/xhtml+xml for XHTML? Why not use the well known key words "MUST", > "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" -- and wire text/javascript and text/ecmascript with the keywords > "MAY" or better "SHOULD NOT" to comply with RFC 4329 and wire > application/javascript and application/ecmascript with the keywords "SHOULD" or > "RECOMMENDED" to comply with RFC 4329? How does using application/ecmascript instead of text/javascript in any way benefit authors? This is not a rhetorical question. It is the crux of the matter. Please can you give a single such benefit? I've added the various RFC4329 types to the list of types that are possible, if that matters.
It seems to me that both text/javascript and application/javascript are conforming type values in HTML5, and that implementations are required to support both. Thus, I do not see the violation of RFC4329. It is true that the spec makes a different suggestion of preferred value. Since neither document conformance nor implementation conformance is in any way affected, this seems like a matter of taste to me, rather than a standards conflict.
The spec says: "The MIME type used to refer to ECMAScript in this specification is text/javascript. This is a willful violation of RFC 4329. [RFC4329]" So it appears you disagree with Ian, Maciej?
(In reply to comment #23) > The spec says: > > "The MIME type used to refer to ECMAScript in this specification is > text/javascript. This is a willful violation of RFC 4329. [RFC4329]" > > So it appears you disagree with Ian, Maciej? > Yes, I disagree with him. I think that remark in the spec is incorrect. I do not see how any conformance criteria of RFC 4329 can be violated by the spec other than by imposing contrary conformance criteria, which it does not do afaict.
I think that most web authors don't really care about which is the MIME type as long as every UA uses the same. It should be enough for the spec to clearly refer what MIME type it uses, as it already does.
Based on these comments I changed the note in the spec to: "Similarly, the MIME type used to refer to JavaScript in this specification is text/javascript, since that is the most commonly used type, despite it being an officially obsoleted type according to RFC 4329. [RFC4329]"
(In reply to comment #26) > Based on these comments I changed the note in the spec to: "Similarly, the MIME > type used to refer to JavaScript in this specification is text/javascript, > since that is the most commonly used type, despite it being an officially > obsoleted type according to RFC 4329. [RFC4329]" Why not also calling the per RFC 4329 recommended Mimetypes per name and saying, what Mimetypes RFC 4329 recommends instead?? What about section 4.3.1.1 Scripting languages (http://www.whatwg.org/specs/web-apps/current-work/#scriptingLanguages) and the whole zoo of mimetypes? Although the Spec-Draft says "User agents may support other MIME types and other languages", where is the note also in that section, that RFC 4329 does make a clear cleanup and recommendation at that point in favour of manageable (and easy to memorizy) 2 Mimetypes? BTW: I've reopened the bug, because you tend to move and make some modifications (and the fact, that there _are_ in fact modifications to the Spec, contradict the Status "RESOLVED WONTFIX" of this Bug). OK for you?
I'm confused. What exactly do you want the spec to say?
Here are the advantage from the new MIME types. In FireFox, you can use different version of JScript. The default one (and the most ECMAScript 3.0 compilent) use text/javascript or application/javascript. application/javascript is originally for internal use in the browser (XUL, ...) and text/javascript was designed for webpages. You also can specify some specific JScript version (using the MIME-Type), to have non-ECMAScript version of the JScript compiler to run. By adding a new MIME-Type "application/ecmascript" that will only be used in NEW webpages, browsers can be sure that using a more recent version of ECMAScript is possible. It's a little like defining a new DOCTYPE for HTML5. Why can't we use the HTML4 doctype ? We're used to ! Because the browser need to know if the page is ready for using the HTML5 render engine. We've the same problem in JScript. Currently, no browser really implement "application/ecmascript", so they can speak about it and be OK to run a specific version of the JScript engine when this header in encountered. You need to let them this change, even if you don't see the advantage as of now.
Changing the type does nothing in practice, user agents ignore (indeed HTML5 requires them to ignore) the actual type. I'm marking this WONTFIX again based on the comments above. I really have no idea why we would want to use a type other than text/javascript in the spec. I recommend raising this with the working group chairmen if this is not satisfactory, unless there is new information that has not already been discussed above. If there is new information, feel free to reopen this bug and let me know what I'm missing. :-)
It seems to me the current spec text is OK and not in conflict with the RFC.
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.
Although I am not very confident with it, I mark this bug as closed. http://www.w3.org/TR/html5/infrastructure.html#dependencies makes a statement about the willful violation of RFC 4329 and a reference to RFC 4329 itself. My hope originally has been, that the HTML5 spec shouldn't intend to freeze common habits (especially bad common habits) and instead give a more _leading line_ to the users. Although not confident with the compromise found all around, I don't want to block the specification process with argueing and discussing. I find it a pity, since RFC 4329 has a well thought, and also the http server Apache as well as nearly all browser makers (except Microsoft with its IE, but that browser doesn't even know of application/xhtml+xml...) have implemented changes in their MIME tables in respect to that particular RFC 4329. HTML5 could be a good cause/motive/trigger to help RFC 4329 be more observed. People do have to learn some/many news stuff around HTML5, anyway. So, I close the bug (a little bit contrited, but overruled) for the time being.
*** Bug 9526 has been marked as a duplicate of this bug. ***
I agree with the above comments. Declaring "application/ecmascript" as the new default does not invalidate any existing sites at all. In the end, HTML5 is just a recommendation anyway. So none of the existing sites will break if this declaration is put straight.
Axel, This bug was moved to status=closed by the commenter who raised it. The HTML WG defines that state as an endpoint in the process for HTML WG bugs: http://dev.w3.org/html5/decision-policy/decision-policy.html The circumstance under which closed bugs should be reopened is if you have information that had not yet been put forward in previous discussions of the bug, which does not seem to be the case here. So I'm moving this back to resolved=wontfix and (re)closing it.
Well, more or less _I_am_ also a commenter who raised this issue, because I have created a so-called Duplicate of this bug. And I believe that the information I have given gives another, an additional, new view on the situation. That's why I believed it is valid to re-open the case. I could have done for my bug issue equally.
(In reply to comment #37) > That's why I believed it is valid to re-open the case. I could have done for my > bug issue equally. Agreed. I think this is a candidate for escalation to a tracker issue.
*** Bug 17436 has been marked as a duplicate of this bug. ***
(In reply to comment #39) > *** Bug 17436 has been marked as a duplicate of this bug. *** After reading more into this it seems that back in 1993 Tim Berners Lee had a similar stance on application/html: http://www.mhonarc.org/archive/html/ietf-822/1993-10/msg00093.html I think it seems pretty unclear on the stance on what "application" actually means, I see its benefit however the inconsistency between: text/html, application/xml, text/css and application/javascript seems to muddy the water a little. The benefit of using application is clear that a user agent could filer out application scripts at a type level rather than subtype would be more efficient. Many other benefits I am guessing could be gained from using the application type however the ambiguity of which type the media is: http://www.iana.org/assignments/media-types/index.html Makes it pretty useless whichever the type is and perhaps subtype should just be used. Until this is resolved I feel now it is a non issue.
*** Bug 27644 has been marked as a duplicate of this bug. ***