Does all javascript (like location.href) require that javascript be declared?
Andrea
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
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.
It is <script type="text/javascript">, btw, the language version is
deprecated.
> 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
<div style="border:1px solid red;">
has inline CSS as value of the style attribute.
> 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
--
Lasse Reichstein Nielsen - l...@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'
alu
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
"Andrea" <ama...@yahoo.com> wrote in message
news:99c59139.03070...@posting.google.com...
Jim Ley
<l...@hotpop.com> wrote:
>ama...@yahoo.com (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.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Andrea
>Re: Does all javascript (like location.href) require that >javascript
be declared?
>From: Jim Ley
>Date Posted: 7/4/2003 10:13:00 AM
>On 04 Jul 2003 17:56:37 +0200, Lasse Reichstein Nielsen
<l...@hotpop.com> wrote:
>ama...@yahoo.com (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...)
Jim -
If you don't declare javascript through the meta tag, do you declare it
anywhere
(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">).
Thanks,
Andrea
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
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.
Stephen
> On 04 Jul 2003 20:27:42 GMT, Andrea <anon...@devdex.com> wrote:
>
>
>>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
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".
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?
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.
That said, note that the HTML 4.01 standard for the <script> tag is that
the "type" attribute is required and takes a content-type as its value
(that is, a "mime-type"; one might also see the term "media-type" for
this kind of thing).
For me, I'd rather use <script type="text/javascript"> and support
getting the UA vendors to recognize this and process it properly. And to
continue to support getting the type recognized in an RFC.
Regards,
Stephen
Jim Ley
wrote:
>Jim Ley wrote:
>> On 04 Jul 2003 20:27:42 GMT, Andrea <anon...@devdex.com> wrote:
>>
>>
>>>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 cock 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! :-)
Stephen
> On Sat, 05 Jul 2003 04:01:58 GMT, Stephen <ssa...@austin.rr.com>
> wrote:
>
>
>>Jim Ley wrote:
>>
>>>On 04 Jul 2003 20:27:42 GMT, Andrea <anon...@devdex.com> wrote:
>>>
>>>
>>>
>>>>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.
> text/css is RFC 2318 btw.
> see
> http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
>
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?
>
>>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.
>
>
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.
>>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 cock 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.
>
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.
>
>>And to continue to support getting the type recognized in an RFC.
>
>
> 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
Jim Ley
wrote:
>Jim Ley wrote:
>> Stephen <ssa...@austin.rr.com> wrote:
>>>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.
>>>And to continue to support getting the type recognized in an RFC.
>>
>> 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.
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.
Andrea
>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
HikksNotAtHome
<anon...@devdex.com> writes:
>>> <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
Try navigating that select list with your keyboard and the inaccessibility
quickly becomes obvious. Accessibility solution? Use a Go! Type button that
when clicked navigates. For non-JS users, have the button submit a form that
when the server gets it, will redirect to the URL specified.
--
Randy
All code posted is dependent upon the viewing browser
supporting the methods called, and Javascript being enabled.
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.