language="javascript" should be type="application/x-javascript"

VERIFIED FIXED in mozilla0.9.3


UI Design
18 years ago
14 years ago


(Reporter: Henrik Gemal, Assigned: Mark Anderson)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



18 years ago
is deprecated according to we should use 
type="javascript" in mozilla XUL instead.

Comment 1

18 years ago
Even more, I'd say type="text/javascript"


18 years ago
Summary: language="javascript" should be type="javascript" → language="javascript" should be type="text/javascript"

Comment 2

18 years ago
I agree. What we need to here is to create some kind of batch-script to go
through everey .xul file we have and edit language="Javascript" ->

This shouldn't be Browser-general component, should it?

Comment 3

18 years ago
Toolkit:XUL looks likethe best component for this one. (at least to start)
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets: XUL
QA Contact: doronr → jrgm

Comment 4

18 years ago
Well it should be like this:

<script language="JavaScript" type="text/javascript">
<script language="JavaScript1.x" type="text/javascript">

where x is the selected version!

Comment 5

18 years ago
should it be:
<script language="JavaScript" type="text/javascript">

I thought that "language" was deprecated...

Comment 6

18 years ago
I guess I'll take this since I've been doing it in files I touch anyways...

This isn't a toolkit problem, it really spans every component...
Assignee: trudelle → blakeross
Component: XP Toolkit/Widgets: XUL → Browser-General
QA Contact: jrgm → doronr
Problem is, the MIME type text/javascript is not registered.  This issue has
been discussed before...

Comment 8

18 years ago
Registered or not, Mozilla has to support it as a defacto standard (and I'm
pretty sure we do), the same way we support "application/x-javascript". And
using that type would be at least as worthy a replacement for "language=JavaScript".

I think the current party line is that it's Not Our Fault that no type is
registered for ECMAScript. A *while* back I proposed registering a vendor type
for JavaScript, but that really wouldn't contribute to making the world a better
place in this regard.

The fact that no MIME type is registered for ECMAScript hasn't been a hindrance
for the use of the "type" attribute in lieu of "language" in HTML; I see no
reason why the situation should be different for XUL.


18 years ago
Component: Browser-General → XP Apps
Keywords: helpwanted
QA Contact: doronr → sairuh
It's not like the IANA is going to register text/javascript for some other 
document type, like, say, a text-based coffee-related font family description
language, is it now.
See bug 7834 for background on a similar change that took place in our tree.

Comment 11

18 years ago
Interesting, because the type attribute must be used for HTML. But then the MIME
is not registered. So why not use a deprecated attribute, because it's not
obsolute, in combination with the required type attribute?

Comment 12

18 years ago
Leaving aside IANA for now, what is implemented is here:

Comment 13

18 years ago
John, that's even more interesting starting from line 1582. If type= specified,
then Mozilla looks for version=. But after looking at the W3C specs, I can't
find an attribute called 'version='! I'm missing something, can you help me out?
That's because the MIME type that we'd propose if we got around to proposing
it would have an optional version parameter.  (And, BTW, that code only
applies to XUL.)  Since there's no registered MIME type, you can't say that
the registered MIME type doesn't allow a version...

Comment 15

18 years ago
Exactly, that's something I missed. Thank you for your clarification. I just
didn't know about that proposing stuff, but now I do.

BTW, W3C is using text/javascript very much in there examples, in a way this
must be a sort of standard already.

Comment 16

18 years ago
This bug appears to be rehashing a good deal of well-trodden ground. Folks,
please read bug 27912.

Comment 17

18 years ago
after sparing w/ braden and brendan, it seems that we should be using 
application/x-javascript which we support and which is in less violation of the 
Summary: language="javascript" should be type="text/javascript" → language="javascript" should be type="application/x-javascript"

Comment 18

18 years ago
I'm going to be a pain and point out that the SVG specs define a script element
whose type attribute has a default of "text/ecmascript"

Also see which
doesn't really come to a conclusion either.

Comment 19

18 years ago
not a pain at all, i've already encountered those, but i failed to use that as 
an arguement for using text/xul instead of registering, so i don't think it's 
relevant.  application/x-javascript is relatively compliant w/ RFCs especially 
when you compare it to the various violations committed by w3.


18 years ago
Depends on: 70439

Comment 20

18 years ago
Bradley: Quite simply, the W3C is not an authority on this issue.

Comment 21

18 years ago
Created attachment 27384 [details] [diff] [review]
first pass

Comment 23

18 years ago
i collapsed two <script ...></script>'s to <script .../> per kerz. r=kerz
Assignee: blakeross → timeless

Comment 24

18 years ago
It is a common courtesy to:

* ask a person before you take a bug from them
* ask a person if they've already patched all the files before you do it 
(duplicated effort, and all that)
* at least cc the person if you're going to take the bug
* announce when you're touching lots and lots of files somewhere (especially at 
a time when some of us have large xul syntax changes in our trees waiting to 
land in three days)

I appreciate the patch (!), just wish that the first time I heard about this 
wasn't on Bonsai.
QA Contact: sairuh → shrir

Comment 25

18 years ago
this is -absolutely- not my bug(QA). sending back to sairuh....
QA Contact: shrir → sairuh

Comment 26

18 years ago
that's ok. QA: to verify, please wait for all 3 fixes to land, and for mailnews 
perf branch to merge. then use
any non 'test' xul file turning up means this bug is not fixed.

we'll have to consult ben, braden or brendan about test files, html files and 
xml files.

I might change some cpp files, but some of them will always contain language 
and text/javascript because they are support for the rest of the world.
Keywords: helpwanted

Comment 27

18 years ago
Created attachment 27510 [details] [diff] [review]
second pass
bindu, preshant...?

QA Contact: sairuh → bsharma

Comment 29

18 years ago
looks good to me.. (big patch)

Comment 31

18 years ago
i think braden would love to qa.
QA Contact: bsharma → braden

Comment 32

18 years ago
I would like to ask why you checked in another patch to this bug after I 
specifically requested that you wait until those of us who have had mass xul 
syntax changes in our tree for two weeks land or, at the very least, let us know 
first.   Mark and I told you yesterday that this caused us many conflicts.  We'd 
like to land these changes immediately after .8.1 branches and freezes 
(3/14-3/16, since we couldn't before that point); your touching 55 xul files in 
the interim certainly isn't going to help, and nothing about this patch is so 
critical that it had to be checked in immediately.

Comment 33

18 years ago
Created attachment 28462 [details] [diff] [review]
mail pass

Comment 34

18 years ago
trivial indentation problem in messageWindow.xul

Comment 35

17 years ago
timeless asked me to pick this one up.  Targeting to 0.9.3 and reassigning to 
myself.  See bug 70857 for details and a patch.
Assignee: timeless → andersma
Target Milestone: --- → mozilla0.9.3

Comment 36

17 years ago
Fix checked in for trunk on July 9.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 37

17 years ago
v 20020222
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.