By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,738 Members | 1,312 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,738 IT Pros & Developers. It's quick & easy.

script type application or text ???

P: n/a
two possibilities or the attribute type of script :

text/javascript (the one i usually use)
application/x-javascript

what are the differencies between both ?

depends on the html content ?

for example html 4.0.1 versus xhtml 1.1 ???

--
Une Bévue
Feb 19 '07 #1
Share this Question
Share on Google+
12 Replies

P: n/a
Une Bévue wrote:
text/javascript (the one i usually use)
Deprecated
application/x-javascript
Experimental

application/javascript became official sometime last year. It'll be a
while before browser support is there though I suspect, so its
probably wise to continue using text/javascript for the time being.
(Browsers tend to ignore the content type in the HTTP header for
scripts though, so moving to application/javascript on the server is
probably good future planning)

Feb 19 '07 #2

P: n/a
David Dorward <do*****@gmail.comwrote:
Deprecated
application/x-javascript

Experimental

application/javascript became official sometime last year. It'll be a
while before browser support is there though I suspect, so its
probably wise to continue using text/javascript for the time being.
(Browsers tend to ignore the content type in the HTTP header for
scripts though, so moving to application/javascript on the server is
probably good future planning)
OK, fine, clear enough, thanks a lot !!!
--
Une Bévue
Feb 19 '07 #3

P: n/a
VK
On Feb 19, 4:48 pm, "David Dorward" <dorw...@gmail.comwrote:
application/x-javascript

Experimental
application/x-javascript is default Content-Type for .js files on
Microsoft IIS for at least 8 years by now.

Do not mix with application/javascript from RFC #4329 - that is all
another joke.

Neither one is recognized by IE if used as <scriptelement attribute.
It means that inline scripts will be silently ignored - that's a good
reason IMO to never use neither of them.
For linked .js files one can set type="foobar/rulez" or set nothing
at all: type attribute with src set is ignored since Netscape 3.0 - so
roughly since forever.

More details can be found at:
<http://groups.google.com/group/comp....avascript/msg/
39ef46cb24e69a22>

Feb 19 '07 #4

P: n/a
VK <sc**********@yahoo.comwrote:
<http://groups.google.com/group/comp....avascript/msg/
39ef46cb24e69a22>
In particular :

RFC === Request For Comments ;-)
--
Une Bévue
Feb 20 '07 #5

P: n/a
On Feb 19, 8:12 pm, "VK" <schools_r...@yahoo.comwrote:
On Feb 19, 4:48 pm, "David Dorward" <dorw...@gmail.comwrote:
application/x-javascript
Experimental
application/x-javascript is default Content-Type for .js files on
Microsoft IIS for at least 8 years by now.
So? Its taken a while to become standard.
Do not mix with application/javascript from RFC #4329 - that is all
another joke.
No, its finally a standard. Nothing funny about it.
Neither one is recognized by IE if used as <scriptelement attribute.
Yes, I said that.
It means that inline scripts will be silently ignored - that's a good
reason IMO to never use neither of them.
Why not? Support should arrive in time, and there comes a point where
support for older browsers is dropped. We don't worry about browsers
that don't support the HTTP Host header, do we?
For linked .js files one can set type="foobar/rulez" or set nothing
at all: type attribute with src set is ignored since Netscape 3.0 - so
roughly since forever.
I might experiment with that at some point to find out exactly what
browser behaviour is. I wouldn't like to gamble on them error
correcting though.

Feb 20 '07 #6

P: n/a
On Feb 20, 12:22 pm, David Dorward wrote:
On Feb 19, 8:12 pm, VK wrote:
<snip>
>For linked .js files one can set type="foobar/rulez" or set
nothing at all: type attribute with src set is ignored since
Netscape 3.0 - so roughly since forever.

I might experiment with that at some point to find out exactly
what browser behaviour is.
<snip>

Why bother? VK wrote this so the odds were that it was BS to start
with, and it is.

Richard.

Feb 20 '07 #7

P: n/a
VK
On Feb 20, 3:22 pm, "David Dorward" <dorw...@gmail.comwrote:
It means that inline scripts will be silently ignored - that's a good
reason IMO to never use neither of them.

Why not? Support should arrive in time, and there comes a point where
support for older browsers is dropped.
<script type="application/javascript">
document.write("<p>This script will not work for 89% of visitors</
p>");
</script>

So you mean like "No big deal this block will be ignored for the
majority of my visitors. Few years latter it may start working - for
the time being consider it as a page source decoration".

Conceptual... But hardly practical - and definitely not something to
suggest IMO.

P.S. RFC != standard

Feb 20 '07 #8

P: n/a
VK wrote:
On Feb 20, 3:22 pm, "David Dorward" <dorw...@gmail.comwrote:
>Why not? Support should arrive in time, and there comes a point where
support for older browsers is dropped.
So you mean like "No big deal this block will be ignored for the
majority of my visitors
Do you have some sort of difficulty in grasping the concept of doing
something differently IN THE FUTURE? Not now. Not the immediate future. Not
soon. Not until support is there.

--
David Dorward <http://blog.dorward.me.uk/ <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Feb 20 '07 #9

P: n/a
On Feb 21, 1:27 am, "VK" <schools_r...@yahoo.comwrote:
On Feb 20, 3:22 pm, "David Dorward" <dorw...@gmail.comwrote:
It means that inline scripts will be silently ignored - that's a good
reason IMO to never use neither of them.
Why not? Support should arrive in time, and there comes a point where
support for older browsers is dropped.
[...]
>
So you mean like "No big deal..
No, like don't say *never*, because eventually support will arrive -
maybe even for the beleaguered 89% with sub-standard browsers. :-)

[...]
P.S. RFC != standard
No one suggested it was - a fact pointed out by Une Bévue. However, a
great deal of standardisation on the web is based on RFCs.
--
Rob

Feb 21 '07 #10

P: n/a
VK
Do you have some sort of difficulty in grasping the concept of doing
something differently IN THE FUTURE? Not now. Not the immediate future. Not
soon. Not until support is there.
"In those days came John the Baptist, preaching in the wilderness of
Judaea,
And saying, Repent ye: for the kingdom of heaven is at hand."

OK, I'm grasping this concept. But who the hell Bjoern Hoehrmann is to
make the whole Internet community to follow and to obsolete 8 years of
practice as "praying to wrong gods"? I may grasp the concept that back
in 2001 he had a vision on the wall: "Behold and perceive: there is no
type but application/javascript". I may also grasp that ever since he
was harassing IETF with I-Ds (expiring every year by protocol) until
finally they gave up on RFC for him. I'm still not grasping though why
a desire of a single person should override everything. I have nothing
against of Bjoern Hoehrmann personally - shall be health and
prosperity on him. But technically he did not invent anything publicly
useful for a normal RFC like "here is the new stuff, if you like it
then better to use it in this way". Instead he just came to say that
"all what you were doing is wrong, here is the right way to do it
because I'm saying so". And as no one can find his name in the book,
anyone is in right to ask this simple question: "Who the hell you are,
Mr. Hoehrmann?"

Yes, historically type="text/javascript" has nothing to do neither
with Content-Type response header nor with <scriptelement. It was
introduced in Netscape 4.0 for <styleattribute together with the
proposed dual CSS structure. It is out of use for many years by now so
I'm reminding that in Netscape 4.x one could use two syntax for style
rules:
1) the regular (now) CSS syntax:
<style type="text/css">
a {
font-weight: "bold";
text-decoration: "none";
}
</style>

2) JavaScript-like syntax:
<style type="text/javascript">
tags.A.fontWeight="bold";
tags.A.textDecoration="none";
</style>

It had nothing to do with <scriptwhere "language" attribute remained
with important distinction of values "JavaScript" and "JavaScript1.2".
It had nothing to do neither with Content-Type of any kind: "type"
attribute was of the same kind as "type" in form controls. The second
syntax did not fly and it was not in extensive use even during the
Browser Wars. The reason is the same as in many other Netscape 4.x
troubles: inability to manipulate style rules at runtime. In either
case it was applied once and forever on page load. The idea itself of
using script capabilities in style rules was good: Microsoft
implemented it later in IE5 using expressions. There are still content
generating libraries in use with dual CSS support for Netscape 4.0
inside. Because careless admins did not go away neither :-) from time
to time one may notice strange types on served pages like <style
type="text/javascript"The most "sound" from recent ones is Google
front page last year. That's getting OT though...

Anyway, when W3C were preparing HTML 4.0, they were on "typization"
campaign: each element has to be typed. In W3C everything seems go by
compain: "everything with type, everything in XML, everything has to
start with X in its name". :-)
"text/javascript" was not related with <scriptelement but i) it was
still related with JavaScript as such and ii) it was known to public.
So the choice was made for <script type="text/javascript"in the
final Recommendation. At the same time meaning transfer was made: it
was stated that element's "type" attribute corresponds to Content-Type
response header - which it never did neither before nor after.

As of now - year 2007 - things are as they are, and who cares what did
something mean to ancestors? For us it means that and we are reading
it in this way. Good enough.

Feb 22 '07 #11

P: n/a
On 22 Feb 2007 10:48:12 -0800, "VK" <sc**********@yahoo.comwrote:
>. And as no one can find his name in the book,
anyone is in right to ask this simple question: "Who the hell you are,
Mr. Hoehrmann?"
He's quite easy to find, and whilst somewhat elusive to meet in
person, I've bought him a beer...

I think you're confusing the registration of javascript mime-types as
some how related to HTML, it's not, it's to make sure that the HTML
mess doesn't continue with other uses...

Jim.
Feb 23 '07 #12

P: n/a
VK
. And as no one can find his name in the book,
anyone is in right to ask this simple question: "Who the hell you are,
Mr. Hoehrmann?"


He's quite easy to find, and whilst somewhat elusive to meet in
person, I've bought him a beer...
I might buy him whisky - Bay Area's bud'-water can be taken as an
insult rather than a friendly gesture :-)
As I stated before it is not a personal attack but a technical need
question.
I think you're confusing the registration of javascript mime-types as
some how related to HTML, it's not, it's to make sure that the HTML
mess doesn't continue with other uses...
It is now all related: type attribute, MIME string and Content-Type -
because of the decision made back in April 1998 by W3C to announce
type attribute as Content-Type representation.
To separate the issues first one has to announce type attribute and
Content-Type as two unrelated chunk of information. I see neither
technical possibility nor any visible need to enforce it almost eight
years later Web-wide.

The treatement of external javascript sources is well established and
supported by all existing UAs. It is context based with strong
distinction of contextual request and context-free request.

1. contextual request happens from HTML page while resolving script
src. In such case Content-Type for resource is irrelevant and
disregarded. The response is treated as CDATA text stream which is
either parsed or leads to syntax error.

2. context-free request happens then you directly type in javascript
file URL into address bar. In this case Content-Type has the regular
effect (known-unknown, display-prompt, safe-unsafe).

There is no confusion in the current system AFAICT But it may be a
huge one because of the time-endorsed association "type attribute ==
Content-Type" and the need to keep "text/javascript" support for N
amount of time even if everyone jumps on application/javascript right
now. I expressed some of my doubts once at
<http://groups.google.com/group/mozil...ne/browse_frm/
thread/93f705444dd4acc5>

Feb 23 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.