I create dynamic bottom like this:

formElement = document.createElement('input');
formElement.setAttribute("type", "button");

after this I can see button.
Next code line not working on IE only, why? And where is mistake

formElement.setAttribute("onClick",  "buttonfunction()");

Dani AI

Generated

The IE problem the OP hit is the browser not wiring inline event handlers when you use setAttribute("onclick", ...). As pointed out this has been a long-standing quirk in legacy IE; was right to recommend assigning event properties or using proper event listeners instead of relying on setAttribute. For maintainable code that scales (and to address 's debugging concerns), prefer unobtrusive event wiring and avoid inline handler strings.

A robust, modern pattern is event delegation: attach one click listener to a stable container and dispatch by a small action name stored on each dynamic button (for example, data-action). This avoids per-button setup and keeps logic centralized:

var container = document.getElementById('buttons');
container.addEventListener('click', function (e) {
  var btn = e.target.closest && e.target.closest('button[data-action]');
  if (!btn) return;
  var action = btn.getAttribute('data-action'); // or btn.dataset.action
  var handlers = {
    save: function(b){ /* save code */ },
    cancel: function(b){ /* cancel code */ }
  };
  if (handlers[action]) handlers[action](btn);
});

Troubleshooting tips: inspect the element to see if an HTML attribute was created but the DOM property is unset; use getAttribute vs the property directly to check. If supporting very old IE, fall back to attachEvent and remember to detach handlers and break circular references before removing nodes to avoid memory leaks. For background reading see MDN on setAttribute, addEventListener and event delegation.

This keeps the DOM approach (as noted) clean and gives a simple compromise to 's single-function idea: use a single entry point for events, but dispatch by action name so the code stays readable and easy to extend.

Recommended Answers

All 10 Replies

IE doesn't like setAttribute as already mentioned. A cross browser compatible way of setting the attributes would be to treat them as object properties and modify them directly.

formElement.type = "button";
/* .... */
formElement.onclick = function() {
   someFunction();
}

The only trick is, that:

formElement.type = '?';
//only works in IE before you append the element to the DOM

formElement.onclick = function(){...}
//does work, although you can't append multiple event handlers nicely.  Using a cross browser addEvent() method is a much more desired approach.

This seems to me to be doing things the hard way.

What's wrong with using a simple button object that always calls the same function? Then use if statements in the function to determine what the button should do (including nothing). It seems a lot easier than playing with attributes in the page elements.

Playing with the page attributes for this purpose seems to me like using a 10-ton hydraulic press to crack a peanut out of its shell.

> What's wrong with using a simple button object that always calls the same function?
So what happens when tomorrow the requirement changes and you are told to add five more buttons dynamically? With the approach he is using, he would just have to invoke the function which renders a button five times.

But using your approach, it would mean adding five new blocks to the *ugly* if-else ladder not to mention brining hell to the maintenance programmer just because the logic which you used was not intuitive and obvious.

> Playing with the page attributes for this purpose seems to me like using a 10-ton hydraulic press to
> crack a peanut out of its shell.
Quite the opposite, it lends to a more elegant solution over a kludgey one.

It seems kludgy to me to change the attributes of the page.

It is not at all elegant, and makes debugging harder.

It reeks of self-modifying code.

dom approach has its own beauty.........it has solved many problems..

> It seems kludgy to me to change the attributes of the page.
> It is not at all elegant, and makes debugging harder.
> It reeks of self-modifying code.
Clearly you are ignorant of how professional Javascript code is written. Try to write something useful without *changing the attributes of the page* or writing *self modifying code* and you might just see the light. Not using the higher level abstractions provided by the language / API is just plain foolishness.

Changing page attributes to display something different is one thing.

Changing what function a button calls seems to me to be very hard to debug. This is especially true if you are expecting the button to be calling one function, and it is actually calling another one, due to a page attribute modification you forgot about, or didn't expect to happen.

If you use a global variable and a conditional statement to select what the button does, it's amazingly easy to find the trouble.

The grading policy at the college I work at counts off heavily if someone writes self-modifying code or uses page attribute changes to control program flow.

> The grading policy at the college I work at counts off heavily if someone writes self-modifying
> code or uses page attribute changes to control program flow.
Stifling the creativity/imagination of the kids? Oh my, I pity them.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.