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

Discussion in 'Javascript' started by Andrea, Jul 4, 2003.

  1. Andrea

    Andrea Guest

    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
    Andrea, Jul 4, 2003
    #1
    1. Advertising

  2. Andrea

    alu Guest

    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



    "Andrea" <> wrote in message
    news:...
    > 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].v
    alue">
    > <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
    alu, Jul 4, 2003
    #2
    1. Advertising

  3. (Andrea) writes:

    > 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 -
    Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Jul 4, 2003
    #3
  4. Andrea

    Jim Ley Guest

    On 04 Jul 2003 17:56:37 +0200, Lasse Reichstein Nielsen
    <> wrote:

    > (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/
    Jim Ley, Jul 4, 2003
    #4
  5. Andrea

    Jim Ley Guest

    On 04 Jul 2003 20:27:42 GMT, Andrea <> 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, 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.
    --
    comp.lang.javascript FAQ - http://jibbering.com/faq/
    Jim Ley, Jul 4, 2003
    #5
  6. Andrea

    Jim Ley Guest

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

    On Sat, 05 Jul 2003 04:01:58 GMT, Stephen <>
    wrote:

    >Jim Ley wrote:
    >> On 04 Jul 2003 20:27:42 GMT, Andrea <> 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! :)

    Jim.
    --
    comp.lang.javascript FAQ - http://jibbering.com/faq/
    Jim Ley, Jul 5, 2003
    #6
  7. Andrea

    Stephen Guest

    Re: Does all javascript (like location.href) require that javascriptbe declared?

    Jim Ley wrote:
    > On Sat, 05 Jul 2003 04:01:58 GMT, Stephen <>
    > wrote:
    >
    >
    >>Jim Ley wrote:
    >>
    >>>On 04 Jul 2003 20:27:42 GMT, Andrea <> 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
    Stephen, Jul 5, 2003
    #7
  8. Andrea

    Jim Ley Guest

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

    On Sat, 05 Jul 2003 15:41:48 GMT, Stephen <>
    wrote:

    >Jim Ley wrote:
    >> Stephen <> 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.

    Jim.
    --
    comp.lang.javascript FAQ - http://jibbering.com/faq/
    Jim Ley, Jul 5, 2003
    #8
  9. Andrea

    Andrea Guest

    >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

    *** Sent via Developersdex http://www.developersdex.com ***
    Don't just participate in USENET...get rewarded for it!
    Andrea, Jul 6, 2003
    #9
  10. Andrea

    Jim Ley Guest

    On 06 Jul 2003 18:17:54 GMT, Andrea <> wrote:

    >>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.
    --
    comp.lang.javascript FAQ - http://jibbering.com/faq/
    Jim Ley, Jul 6, 2003
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JohnZing

    declared or not declared ?

    JohnZing, Feb 5, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    1,584
    Jon Paal
    Feb 5, 2006
  2. CRON
    Replies:
    24
    Views:
    200,701
    Adrienne Boswell
    Jun 20, 2006
  3. saiho.yuen
    Replies:
    3
    Views:
    421
    kaeli
    Sep 14, 2004
  4. Replies:
    2
    Views:
    461
  5. Alex Bird
    Replies:
    3
    Views:
    179
    Thomas 'PointedEars' Lahn
    May 9, 2008
Loading...

Share This Page