- 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