javascript function doesn't work when link is clicked

Question

I have a fairly simple page with a sidebar nav and an iFrame in which to load content.

I want to change the content of the of the iFrame by clicking on links in the sidebar nav. I'm using the javascript to change the source (.src) of the document.element.

I've read numerous articles (StackOverflow) and the code should work, but is simply doesn't.

The code below is the html page I've created and it includes the JS in a tag.

<head>
<meta charset="UTF-8">
<title>Untitled Document</title>
<link href="css/default.css" rel="stylesheet" type="text/css">

<script type="text/javascript">
    function getContent{

        document.getElementById("contentFrame").src="LoremIpsum.html";  

    }
    </script>


</head>

<body>
<div class="sidebar"><h1>Technical Documentation</h1>
<ul>
    <li>Configuration Guides</li>
    <li>API Guides</li>
    <li><a href="" onclick='getContent()'> LoremIpsum</a></li>
</ul>
<!-- <button onclick="getContent()">Lorem Ipsum</button>    -->

</div>


<iframe class="content"  id="contentFrame" src="dummy.html">
</iframe>

</body>

Try adding parentheses to the js function declaration. Instead of 'function getContent{' use 'function getContent() {'. — mrkd1991, Apr 17 '17 at 21:30
Look at the console, and you will see that you have a syntax error — Ibu, Apr 17 '17 at 21:31

Scott Marcus · Answer 1 · 2021-05-11T20:27:50.583

25

Your problem was that you forgot to add () after your function name.

Beyond that, there are a few other things to correct:

Don't use inline HTML event attributes (onclick, onmouseover, etc.) as they:

Create "spaghetti code" that is difficult to read and debug.
Lead to duplication of code.
Don't scale well
Don't follow the separation of concerns development methodology.
Create anonymous global wrapper functions around your attribute values that alter the this binding in your callback functions.
Don't follow the W3C Event Standard.
Don't cause a reference to the DOM event to be passed to the handler.

Even MDN agrees

Instead, do all your work in JavaScript and use .addEventListener() to set up event handlers.

Don't use a hyperlink when a button (or some other element) will do. If you do use a hyperlink, you need to disable its native desire to navigate, which is done by setting the href attribute to #, not "".

// Place this code into a <script> element that goes just before the closing body tag (</body>).

// Get a reference to the button and the iframe
var btn = document.getElementById("btnChangeSrc");
var iFrame = document.getElementById("contentFrame");

// Set up a click event handler for the button
btn.addEventListener("click", getContent);

function getContent() {
  console.log("Old source was: " +  iFrame.src);
  iFrame.src="LoremIpsum.html";  
  console.log("New source is: " +  iFrame.src);
}

<div class="sidebar"><h1>Technical Documentation</h1>
<ul>
    <li>Configuration Guides</li>
    <li>API Guides</li>
</ul>
<button id="btnChangeSrc">Change Source</button>

</div>

<iframe class="content" id="contentFrame" src="dummy.html"></iframe>

edited May 11 '21 at 20:27

answered Apr 17 '17 at 21:33

Scott Marcus

60,351
6
44
64

2

If using inline HTML event attributes is so bad - then tell me: why all modern frameworks like angular, react, vue etc... are designed to use inline events in their HTML templates? For small pure JS projects using inline HTML events is acceptable (because their are small and simple, and easy to control), for bigger project is better to use some modern framework instead pure js. – Kamil Kiełczewski Sep 26 '19 at 05:33
5

@KamilKiełczewski Your point has been brought up over and over again in many forums. It stems from a fundamental misunderstanding and false equivalency. A framework has to have "hooks" into the native code, so they come up with inline ways of doing that, but the ***rendered*** code does not contain these inline hooks. I am not discussing frameworks, I am discussing native code that doesn't get transformed into anything else. Your statement that small projects make inline events OK is not a "thing". Inline event handlers are bad... at any scale. – Scott Marcus Sep 26 '19 at 05:37
But begginers who start with pure js small project and use inline html events can very easy learn how to properly use frameworks templates. But begginers who dont use inline events develop very bad habbits and is hard for them to use framework in proper way (they focus on js part instead of template part and produce very unclear nad hard to maintain code) and need a lot of time (and usually luck and teacher) to break that habbits – Kamil Kiełczewski Sep 26 '19 at 05:42
Yes - not using inline event is bad habbit (taken from pure js experinece) in frameworks world - I see this offten in begginers 'frameworks' code - and this habbit is very hard to break for them. – Kamil Kiełczewski Sep 26 '19 at 05:50
5

Well, that's your opinion and you are entitled to it. After teaching this stuff since it was invented and some 20,000+ students later, my opinion is that as long as you understand what a framework is and how it accomplishes what it does, there is no problem at all in understanding that coding a framework takes a different approach than coding in native JS. The bad habit that I see is poor training that skips over this topic and dives right into coding without differentiating between the two. It's not rocket science to understand best practices to each. – Scott Marcus Sep 26 '19 at 05:57
1

And, as my post above lays out, this is not just a matter of style or preference. There are real negative implications for your code in JS if you use inline event handlers - - that's the real reason to stay away from them. The very bad habits you talk about truly do manifest in JS itself when you use them. – Scott Marcus Sep 26 '19 at 05:59
"#6 Don't follow the W3C Event Standard" is weak to me, as it seems to me the authoritative domain for this is the HTML spec: https://html.spec.whatwg.org/multipage/webappapis.html#event-handler-content-attributes – wtr Jul 02 '21 at 20:23
@wtr There are two HTML standards, W3C and WHATWG. W3C is the more authoritative. – Scott Marcus Jul 03 '21 at 16:06
That's useful to know! Thank you. (Interestingly, your #6 w3.org link redirects to WHATWG, so to match, my previous link ought to be: https://www.w3.org/TR/html/multipage/#event-handler-content-attributes) – wtr Jul 03 '21 at 23:14
Ultimately I'm saying #6 in this context seems to mildly imply this is against standards, but it's listed within section 8.1.7.1 of (both) html spec(s). Saying it's missing from the DOM standard, to me, is like saying the HTML tag isn't specified in the DOM standard; it's technically true, but it's effectively out of jurisdiction, and as it seems misleading it undermines my faith in the rest of your points. (I still appreciate you as a human being though, and thank you for sharing your insights! :) – wtr Jul 03 '21 at 23:28
Wow- as I've continued researching the meme of "EHCA's are bad practice" I keep finding that this post is referenced in _many_ other stack overflow posts on the topic as a definitive list of badness. Given the influence of this post, can we have a chat, @ScottMarcus? I have a seemingly unpopular opinion that I believe needs to be heard as legitimate use cases of EHCA's, and with claims being thrown around (not by this post) of EHCA's being deprecated, there's danger of a misguided mob that this SO post has indirect but substantial influence over. Requesting some assistance and understanding. – wtr Jul 04 '21 at 02:41
@wtr The redirect to WHATWG talks about “DOM Events”, which are standardized by the W3C. And if you read that spec. (in either document), it discusses .addEventListener, not inline event handlers. There really is no valid use case for inline handlers in native JavaScript. They are simply a relic from a time before there were standards and, while they are still supported (for legacy purposes), they have real world negative implications. – Scott Marcus Jul 04 '21 at 13:39
https://html.spec.whatwg.org/multipage/webappapis.html#introduction-11 "Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to: [...] Event handlers, whether registered through the DOM using addEventListener(), **by explicit event handler content attributes,** by event handler IDL attributes, or otherwise." Emphasis added. EHCA's don't belong in the DOM spec; they belong in the HTML spec, so pointing at DOM Events is directly irrelevant and borderline misleading (as stated previously). – wtr Jul 04 '21 at 17:19
"They are simply a relic" – I respect this as your opinion. I just happen to disagree with it completely. Replacing declarative with imperative code is, in this author's opinion, not _always_ a good idea (as you apparently insist). I _am_ surprised that you seem to not allow for that possibility, given your vast experience & _age-refined_ wisdom. Regarding relics, some things get better with age. – wtr Jul 04 '21 at 17:55
@wtr I’ve had this conversation many times over the years, and no disrespect intended, it’s usually with less experienced and knowledgeable coders. Inline handlers are in fact relics, in the most literal sense. That is not an opinion, it’s a fact. They are not included in the current specs. and only supported for legacy compatibility. If you had been working with these languages since their inception as I have, you would understand how and why code has evolved. The only reason these don’t die the death they deserve, is because of the continued use by uninformed coders, hence my post. – Scott Marcus Jul 05 '21 at 15:34
Thanks for the respectful chat. For future visitors, there are additional voices that have a different take than @ScottMarcus's; please take these into consideration: https://stackoverflow.com/a/26439633/1302400, https://softwareengineering.stackexchange.com/a/225013/143891, https://stackoverflow.com/questions/5871640/why-is-using-onclick-in-html-a-bad-practice/5871830#comment7046688_5871830, https://stackoverflow.com/questions/12627443/jquery-click-vs-onclick/12627478#comment25122933_12627478, https://stackoverflow.com/questions/6941483/onclick-vs-event-handler/6941663#comment8274445_6941663 – wtr Jul 06 '21 at 00:05
@wtr I really think you should read through the original comments in this thread. The additional voices you are describing are conflating inline HTML event attributes for native JavaScript events with inline handlers with various frameworks, which is completely different because those frameworks compile that syntax down to native JavaScript. This is a subtle but important distinction. And, as I mentioned, new coders don’t fully understand this nuance and just lump it all together, when they should not be. – Scott Marcus Jul 06 '21 at 17:44
Maybe we're talking past each other. Let's check. When you say "inline HTML event attributes," do you mean the "event handler content attributes (EHCA)" that I've been referring to, linking to, and deriving quotes about? (e.g. the `onclick` in `` from the stack overflow question) – wtr Jul 06 '21 at 21:29
@wtr Yes, although no one calls them EHCA. The alternate voices you linked to were not actually discussing that. They were making a false equivalency between inline HTML event attributes used in “vanilla” JavaScript with inline event handlers in frameworks like Angular, where they are required as part of the framework syntax. I’m those applications, you have no choice and that custom code is compiled down to vanilla JavaScript in the background. – Scott Marcus Jul 06 '21 at 23:08
I started calling them EHCA's in this comment thread because it's an 87% reduction in characters in a character-limited comment box. – wtr Jul 07 '21 at 00:20
@wtr Sure, but it’s best to use terms and abbreviations that people understand. And since you asked for clarification that we were talking about the same thing, I felt it important to let you know. – Scott Marcus Jul 07 '21 at 00:36
Of the five links discussing the utility of EHCA's, I notice the one you picked merely references Angular's syntax as an example of similarity of form, with which you then A) "lump up" the meaning of his _entire_ post into that and B) "lump up" all five links into the idea that all 5 of them "were not actually discussing [the utility of EHCA's]". I think it was Scott Marcus the Wise that once said (6 hours ago) "new coders don’t fully understand this nuance and just lump it all together, when they should not be." – wtr Jul 07 '21 at 00:43

score 2 · Answer 2 · answered Apr 17 '17 at 21:36

2

This is a syntax error. Parenthesis are required no matter the parameters of the function. However, it is a good practice to place script tags at the bottom of the body tag.

answered Apr 17 '17 at 21:36

lazar0169

21
2

score 1 · Answer 3 · answered Apr 17 '17 at 21:31

1

You have a syntax error in your function declaration (missing parenthesis):

function getContent {
   document.getElementById("contentFrame").src="LoremIpsum.html";
}

Should be:

function getContent() {
   document.getElementById("contentFrame").src="LoremIpsum.html";
}

You also need to prevent the default event for the link

<head>
<meta charset="UTF-8">
<title>Untitled Document</title>
<link href="css/default.css" rel="stylesheet" type="text/css">

<script type="text/javascript">
    function getContent(event) {
       event.preventDefault();
       document.getElementById("contentFrame").src="LoremIpsum.html";
    }
    </script>


</head>

<body>
<div class="sidebar"><h1>Technical Documentation</h1>
<ul>
    <li>Configuration Guides</li>
    <li>API Guides</li>
    <li><a href="#" onclick='getContent(event)'> LoremIpsum</a></li>
</ul>
<!-- <button onclick="getContent()">Lorem Ipsum</button>    -->

</div>


<iframe class="content"  id="contentFrame" src="dummy.html">
</iframe>

</body>

answered Apr 17 '17 at 21:31

Rob M.

33,381
6
50
46

To prevent the link navigation, you can just set the `href` to `#`. No JavaScript needed. – Scott Marcus Apr 17 '17 at 21:38
Fair enough, I tend to steer clear of inlining javascript like this and prefer to use `event.preventDefault()` – Rob M. Apr 17 '17 at 21:40
Setting the value to `#` is not inlining JavaScript. There's no JavaScript at all with that. – Scott Marcus Apr 17 '17 at 21:41
I'm aware of that, I was referring to `onclick='getContent(event)'` – Rob M. Apr 17 '17 at 21:41
Yes, agreed (and I discuss that in detail in my answer). But, your reply to my comment was not about what my comment was about in the first place. – Scott Marcus Apr 17 '17 at 21:42
Yes, it was - though perhaps I wasn't being clear enough: I avoid using inline event handlers, therefore I don't set `href="#"` in links and instead rely on `event.preventDefault()` – Rob M. Apr 17 '17 at 21:46
Not to go round and round on this, but that takes me back to my original point. If you don't use inline event handlers (as we both agree you shouldn't), you don't need to add `event.preventDefault()` at all, as long as you set the `href` to `#`. In other words, setting the `href` is independent of whether or not you use inline event handlers. Or, as I suggest in my answer, avoid using `a` elements for operations such as this in the first place. – Scott Marcus Apr 17 '17 at 21:48

score 0 · Answer 4 · answered Apr 17 '17 at 21:47

0

You can use javascript:void(0).

    <a href="javascript:void(0)" onclick='getContent(event)'> LoremIpsum</a>

Or return false on javascript

     <script type="text/javascript">
function getContent(){

    document.getElementById("contentFrame").src="LoremIpsum.html";
    return false;

}
</script>

answered Apr 17 '17 at 21:47

Niladri

169
1
5

1

Oh no, please don't advocate `javascript:void(0)` (it's not 1997)! Also, **if** you were going to do this, adding `return false` to the function wouldn't be enough. You'd also need the `onclick` attribute to look like this: `onclick="return getContent()"` and the `event` argument wouldn't be passed to `getContent`, it would wind up being passed to the anonymous global wrapper function that wraps it. See my answer for more details on why this is bad. – Scott Marcus Apr 17 '17 at 21:50

javascript function doesn't work when link is clicked

4 Answers4

Even MDN agrees

Linked