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

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Henrik Gemal]

since:
language="javascript"
is deprecated according to 
http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1 we should use 
type="javascript" in mozilla XUL instead.

Comment 1

[Gilles Durys]

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

Comment 2

[Håkan Waara]

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" ->
type="text/javascript".

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

Comment 3

[Asa Dotzler [:asa]]

Toolkit:XUL looks likethe best component for this one. (at least to start)

Comment 4

[HJ]

Well it should be like this:

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

where x is the selected version!

Comment 5

[Henrik Gemal]

should it be:
<script language="JavaScript" type="text/javascript">
?

I thought that "language" was deprecated...

Comment 6

[Blake Ross]

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...

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Problem is, the MIME type text/javascript is not registered.  This issue has
been discussed before...

Comment 8

[Braden]

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.

Comment 9

[Hixie (not reading bugmail)]

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.

Comment 10

[Hixie (not reading bugmail)]

See bug 7834 for background on a similar change that took place in our tree.

Comment 11

[HJ]

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

[John Morrison]

Leaving aside IANA for now, what is implemented is here:
http://lxr.mozilla.org/seamonkey/source/rdf/content/src/nsXULContentSink.cpp#15
58

Comment 13

[HJ]

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?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[HJ]

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

[Braden]

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

Comment 17

[timeless]

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 
RFCs

Comment 18

[Bradley Baetz]

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"
(http://www.w3.org/TR/SVG/script.html)

Also see http://lists.w3.org/Archives/Public/www-html/2000Sep/0020.html which
doesn't really come to a conclusion either.

Comment 19

[timeless]

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.

Comment 20

[Braden]

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

Comment 21

[timeless]

Attachment: first pass

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

Great stuff!
a=[e-mail]

Comment 23

[timeless]

i collapsed two <script ...></script>'s to <script .../> per kerz. r=kerz

Comment 24

[Blake Ross]

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.

Comment 25

[shrirang khanzode]

this is -absolutely- not my bug(QA). sending back to sairuh....

Comment 26

[timeless]

that's ok. QA: to verify, please wait for all 3 fixes to land, and for mailnews 
perf branch to merge. then use
http://lxr.mozilla.org/seamonkey/search?string=language=
http://lxr.mozilla.org/seamonkey/search?string=text/javascript
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.

Comment 27

[timeless]

Attachment: second pass

Comment 28

[sairuh (rarely reading bugmail)]

bindu, preshant...?

*shrug*

Comment 29

[Keyser Sose]

looks good to me.. (big patch) r=[e-mail]

Comment 30

[Ben Goodger (use ben at mozilla dot org for email)]

a=ben

Comment 31

[timeless]

i think braden would love to qa.

Comment 32

[Blake Ross]

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

[timeless]

Attachment: mail pass

Comment 34

[Fabian Guisset]

r=fabian
trivial indentation problem in messageWindow.xul

Comment 35

[Mark Anderson]

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.

Comment 36

[Mark Anderson]

Fix checked in for trunk on July 9.

Comment 37

[Henrik Gemal]

v 20020222