Does all javascript (like location.href) require that javascript be declared?

A

Andrea

Hi everyone,

I am in the process of learning javascript and have a question on
location.href. Does javascript always require the <script language =
"javascript">
(or script type="text/javascript">) to run?

I'm asking because the following chunk of code (drop down menu that
goes to different parts of the page) works without declaring anywhere
that it's javascript:

<form>
<select name="Library"
onchange="location.href=this.form.Library[this.form.Library.selectedIndex].value">
<option value="#First">First</option>
<option value="#Second">Second</option>
<option value="#Third">Third</option>
</select>
</form>
<a name="First">First Section</a><br><br><br><br><br><br><br><br>
<a name="Second">Second Section</a><br><br><br><br><br><br><br><br>
<a name="Third">Third Section</a><br><br><br><br><br><br><br><br>

"location.href" is javascript, right?? (I learned it off the
www.dartmouth.edu page in their drop down menu).

I appreciate any help/explanation on this!!

Andrea
 
A

alu

javascript is the default language if none is declared.
however, is no harm in declaring it explicitly, and better safe than
sorry....
just fyi, at some time you may like to look into how declaring the language
version e.g. <script language="JavaScript1.1">
or even language syntax e.g. <script language="JScript">
can be used to run different blocks of code in different browsers.

-alu
 
L

Lasse Reichstein Nielsen

I am in the process of learning javascript and have a question on
location.href. Does javascript always require the <script language =
"javascript">
(or script type="text/javascript">) to run?

No, there are some cases where it is implicit that the content is
Javascript.

btw said:
I'm asking because the following chunk of code (drop down menu that
goes to different parts of the page) works without declaring anywhere
that it's javascript:

<form>
<select name="Library"
onchange="location.href=this.form.Library[this.form.Library.selectedIndex].value">

Yes, the onchage attribute value is *inline* Javascript, just like
I appreciate any help/explanation on this!!

The default script language for inline scripts is javascript in all
browsers. If you want to declare it explicitly, you can use the
Content-Script-Type meta header, either sent by the server or written
inline as

<meta http-equiv="Content-Script-Type" content="text/javascript">
or
<meta http-equiv="Content-Script-Type" content="text/vbscript">

(and similar for Content-Style-Type, if there was any other option
than CSS)

What some people mistakenly do is to write
onchange="javascript:..."
That does not declare the content as javascript, it merely parses
the "javascript:" as a Javascript lable.

/L
 
J

Jim Ley

(e-mail address removed) (Andrea) write:

No, there are some cases where it is implicit that the content is
Javascript.

I don't think there are in any standard, only in de-facto standards of
what's implemented in browsers so far.

e.g. http://www.w3.org/TR/html401/interact/scripts.html says
"Documents that do not specify default scripting language information
and that contain elements that specify an intrinsic event script are
incorrect."

(of course the meta hack is so badly specified, and a bad idea anyway
that I boycott it...)
What some people mistakenly do is to write
onchange="javascript:..."
That does not declare the content as javascript, it merely parses
the "javascript:" as a Javascript lable.

Except in IE where it does declare as javascript... It's also
relatively trivial in IE to configure a different default scripting
language to javascript, I have an IE where perlscript is the default
for example.

Jim.
 
J

Jim Ley

If you don't declare javascript through the meta tag, do you declare it
anywhere

No I don't.... It's potentially wrong, but then there's no registered
mime-type for javascript, I can't use application/x-javascript since
that clearly only applies to JavaScript UA's (and therefore not IE,
opera, konquerer) so even if I wanted to use it, I couldn't really
use a mime-type that actually works, and since no UA's care, it's not
worth the trouble.
(I'm asking specifically for in-line code like
<form>
<select name="Library"
onchange="location.href=this.form.library[this.form.library.selectedinde
x].value">).

Please don't use this construct, it's inaccessible to keyboard users.

Jim.
 
J

Jim Ley

Jim said:
If you don't declare javascript through the meta tag, do you declare it
anywhere


No I don't.... It's potentially wrong, but then there's no registered
mime-type for javascript, [...snip...]

Which is not the same thing as saying there is *no* mime-type for
javascript. There is, and by common usage, the consensus seems to be
"text/javascript". A number of mime-types were in widespread use before
becoming officially registered and recoginzed in an RFC, among them
"text/css".

but that's wrong, and it's a lot more wrong than ignoring HTML
recomendations IMHO, so when it doesn't matter, I'm certainly not
going to promote the breaking of the mime-registration mechanism.

text/css is RFC 2318 btw.
see
http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
Now here's a debate: do we write standard-complient code even if the UAs
don't recognize or render it? Or write to what works in the UAs?

This isn't the question unfortunately, the question is which standard
do we choose to ignore, Internet RFC's or W3 recommendations, I choose
to ignore the recommendations.
Perhaps I tend more toward the standard-complient end, while Jim may be
more pragmatic. The pragmatic approach has a lot going for it: after
all, your code does have to *work* in real-life UAs whether *they*
conform to standards or not.

The mark-up I create aims to be valid in SGML terms, if it's not, it's
a **** up, not a decision, however badly specified meta hacks for
specifying a script type which requires me to use mime-types I
shouldn't.
For me, I'd rather use <script type="text/javascript"> and support
getting the UA vendors to recognize this and process it properly.

I fully agree with this, the type attribute is the only one required,
you shouldn't use language, what I choose not to use is the meta
content-script-type, for various reasons.
And to continue to support getting the type recognized in an RFC.

You'll be lucky! :)

Jim.
 
S

Stephen

Jim said:
Jim said:
If you don't declare javascript through the meta tag, do you declare it
anywhere


No I don't.... It's potentially wrong, but then there's no registered
mime-type for javascript, [...snip...]

Which is not the same thing as saying there is *no* mime-type for
javascript. There is, and by common usage, the consensus seems to be
"text/javascript". A number of mime-types were in widespread use before
becoming officially registered and recoginzed in an RFC, among them
"text/css".


but that's wrong, and it's a lot more wrong than ignoring HTML
recomendations IMHO, so when it doesn't matter, I'm certainly not
going to promote the breaking of the mime-registration mechanism.

I simply disagree that this is wrong. The construct "text/javascript" is
perfectly consistent with the standard way of forming media-type names,
does not conflict with any existing usage, and does not break anything.
It is in use (and recommended) by many members of the internet community.

The argument seems to be: "text/javascript" is not an
officially-recognized mime-type, so don't use it. I think having an
officially recognized javascript mime-type is desirable; but lacking
this, I'm willing to accept an informal de facto mime-type that is
formed consistently with recognized usage. I believe our failure to use
"text/javascript" works against eventual adoption of this as a standard.

True, using a type not formally recognized by the IETF carries some
degree of risk. "text/javascript" could be registered to relate to some
content-type that is not javascript, and this *would* break a bunch of
things. But this is even less likely than eventually obtaining official
recognition for its current meaning and usage.


Yes; I reviewed both these documents before my last post. In the case of
the latter, I wanted to be sure that "text/javascript" still had not
made the official list. In the case of the former, I wanted to make sure
my memory was correct about "text/css" being a mime-type in general
usage well before becoming recognized in an RFC. The "Abstract"
paragraph of 2318 clearly states this. The case of "text/javascript" is
no less worthy than "text/css". Why, then, expect "text/javascript" to
achieve RFC recognition before using it?
This isn't the question unfortunately, the question is which standard
do we choose to ignore, Internet RFC's or W3 recommendations, I choose
to ignore the recommendations.

Good clarification.
I guess I would follow W3C recommendations and behave in a way that is
also consistent with current RFC practice, even though that behavior is
not (yet!) officially blessed by the IETF. Practice often precedes
formalization.

The mark-up I create aims to be valid in SGML terms, if it's not, it's
a **** up, not a decision, however badly specified meta hacks for
specifying a script type which requires me to use mime-types I
shouldn't.


I fully agree with this, the type attribute is the only one required,
you shouldn't use language, what I choose not to use is the meta
content-script-type, for various reasons.


This may be the crux issue--the meta-script-specifying mechanism. No
argument that some specs are "badly specified", making difficult choices
necessary. And this meta-script-specifying mechanism may be one. And
maybe this particular construct *should* be ignored -- but because it's
a poor specification, not because it requires "text/javascript". To
reiterate, there's plenty of precedent for usage-prior-to-formalization.


You'll be lucky! :)

Well, things have changed a lot since Steve Crocker issued RFC 1, when
this really was a "request-for-comment" rather a
"pontification-from-on-high". There seems to be much more politics
involved now, not to mention more people/companies/special-interests
involved. RFC 2318 had Bos & Lie (primary authors of css) and the W3C
behind it. We've not had such heavy-weight support for "text/javascript"
as yet. Doesn't look like the ECMA is particularly behind an effort to
formalize this. About a year or year-and-a-half ago (I'm sure you know)
there was an internet-draft posted, but it expired without action by
IETF. This draft was posted by an individual rather than by an IETF
working-group or an organization such as ECMA. And there are HUNDREDS of
individual-posted drafts at any given time. Most seem to expire without
action. I haven't noticed that this javascript draft was ever
resubmitted, even though its author had indicated an interest in
resubmission.

Yes, we may be lucky, but it's not an impossible mountain to climb. In
the mean time, encourage rather than discourage using "text/javascript".
Eventually, widespread common usage carries weight in adoption of standards.

Regards,
Stephen
 
J

Jim Ley

Jim said:
Stephen said:
Jim Ley wrote:
No I don't.... It's potentially wrong, but then there's no registered
mime-type for javascript, [...snip...]

Which is not the same thing as saying there is *no* mime-type for
javascript. There is, and by common usage, the consensus seems to be
"text/javascript". A number of mime-types were in widespread use before
becoming officially registered and recoginzed in an RFC, among them
"text/css".

but that's wrong, and it's a lot more wrong than ignoring HTML
recomendations IMHO, so when it doesn't matter, I'm certainly not
going to promote the breaking of the mime-registration mechanism.

I simply disagree that this is wrong. The construct "text/javascript" is
perfectly consistent with the standard way of forming media-type names,
does not conflict with any existing usage, and does not break anything.

However the attempt at registering it failed, which suggests far from
being consistent, and not breaking anything people are very against
it, not least javascript being a trademark and only licenced to
certain implementators who have a different implementation to the rest
(if I used watch for example I would rightly label it as being
JavaScript, but it's not ECMAScript.)
The argument seems to be: "text/javascript" is not an
officially-recognized mime-type, so don't use it. I think having an
officially recognized javascript mime-type is desirable; but lacking
this, I'm willing to accept an informal de facto mime-type that is
formed consistently with recognized usage.

RFC's say you must not do this, (unless an x. type, which you should
not use either in the general web, and vnd. or prs. trees are better.)
I believe our failure to use
"text/javascript" works against eventual adoption of this as a standard.

It's already failed to become registered, in any case, I'm only saying
I don't use it in the META hack, I do use it (and text/ecmascript in
SVG) I just don't like doing so, and MIME-types are one of the biggest
process failures of the W3.
In the case of the former, I wanted to make sure
my memory was correct about "text/css" being a mime-type in general
usage well before becoming recognized in an RFC.

Because text/css did it wrong (and the W3 are notoriously bad at
mimetypes) doesn't mean that we should bless everyone else doing it
wrong too.
Why, then, expect "text/javascript" to
achieve RFC recognition before using it?

Because it's simply wrong, the IETF only asks for 2 interopable
implementations, to get to REC status the W3 requires that, there is
no reason that any W3 recommendation should not have a registered
mime-type. The organisation is simply flawed in this respect.
Well, things have changed a lot since Steve Crocker issued RFC 1, when
this really was a "request-for-comment" rather a
"pontification-from-on-high". There seems to be much more politics
involved now, not to mention more people/companies/special-interests
involved. RFC 2318 had Bos & Lie (primary authors of css) and the W3C
behind it. We've not had such heavy-weight support for "text/javascript"
as yet.

Can you see the W3 getting behind it? They'd be stepping on ECMA's
toes, and you have the JavaScript/ECMAScript problem, with their
reluctance to get anything registered.
Doesn't look like the ECMA is particularly behind an effort to
formalize this.

It seems to me TC39 have been very waylaid into CLI and C#
standardising, leaving js in the wasteland.

About a year or year-and-a-half ago (I'm sure you know)
there was an internet-draft posted, but it expired without action by
IETF. This draft was posted by an individual rather than by an IETF
working-group or an organization such as ECMA.

Bjoern had some good support for the draft AIUI, what killed it as far
as I'm aware was the fact that agreement would not have been possible,
the various interested parties weren't there, and the argument against
text/* at all for the language.
Yes, we may be lucky, but it's not an impossible mountain to climb. In
the mean time, encourage rather than discourage using "text/javascript".
Eventually, widespread common usage carries weight in adoption of standards.

No, that's the way to bad standards, for example it looks like we may
be stuck with image/svg+xml despite the fact it clearly should not be
an image/* format (just like JS should not be a text/* one.)

Anyway, yep use text/javascript in HTML, and text/ecmascript in SVG,
it's wrong, but hard luck - you want something that works.

What I'm most interested in is ensuring that the W3 doesn't get away
with this behaviour in future.

Jim.
 
A

Andrea

From: Jim Ley
Date Posted: 7/4/2003 3:23:00 PM
(I'm asking specifically for in-line code like
<form>
<select name="Library"
onchange="location.href=this.form.library
[this.form.library.selectedinde
x].value">).
"Please don't use this construct, it's inaccessible to >keyboard users."

Jim.

Jim - Could you please clarify. What construct? Is there a better way
to write out the code? Thanks, Andrea
 
J

Jim Ley

From: Jim Ley
Date Posted: 7/4/2003 3:23:00 PM
(I'm asking specifically for in-line code like
<form>
<select name="Library"
onchange="location.href=this.form.library
[this.form.library.selectedinde
x].value">).
"Please don't use this construct, it's inaccessible to >keyboard
users."

Jim - Could you please clarify. What construct? Is there a better way
to write out the code? Thanks, Andrea

The onchange event fires as you move through the list with the
keyboard, either via the arrow keys, or via 1st letter navigation,
both are the easiest way to the use select boxes. If you change the
location onChange, I'll never actually be able to get to what I want
with your menu, I'll end up on the wrong page.

Jim.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top