- From: <bugzilla@wiggum.w3.org>
- Date: Thu, 02 Apr 2009 00:15:52 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6684 --- Comment #20 from Sierk Bornemann <sierkb@gmx.de> 2009-04-02 00:15:51 --- (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? -- 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 Thursday, 2 April 2009 00:16:06 UTC