Mixing HTML and Javascript

[davej]

I was going to reference the window.onload page to someone today, but then I decided not to, because I think it promotes a bad approach by seemingly suggesting that embedding the event into the HTML is the most preferred method.

 

http://www.w3schools.com/jsref/event_onload.asp

 

It is generally a poor, obsolete idea to mix HTML with CSS or Javascript if it can be avoided, but this article seems to suggest that mixing HTML and Javascript is the PREFERRED method.

Edited October 14, 2013 by davej

[Hadien]

I don't see how that article is suggesting that its the preferred method, however...

 

performance-wise: events in general have better performance the closer it is defined to the element it's attaching to. when an event is defined the browser needs to traverse the DOM from where it currently is to get to the element that it affects. so in this respect if the event is defined inside the element, the DOM has the least distance to traverse to assign the event. but as far as onload is concerned thats not as such a big deal since onloads are usually only called once in a pages lifetime that traversal speed is a drop in the ocean.

 

onload via html has more use in graceful-degradation. say that an img tag has an onload to attach another hover event to the image when it loads. the hover event does some special things like affect opactiy. but if the image never loads (bad reference or corruption) then the hover event never needs to get attached.

 

thats not to say its better to write onload events directly into the html tags, just that its another way of doing things. writing all your event handlers like onload into a script tag is fine, and its usually easier for the developer since all that code is consolidated in one place. but its perfectly valid to write directly into tags too, just not as flexible.

[davej]

Is there really performance data to support this? I can certainly see the appeal of embedding Javascript especially when you are applying multiple events to particular elements, and it does offer a certain clarity to the code, but... onload() in the body tag? Where is addEventListener?

[Hadien]

I reread my post, and realise I was saying one thing while thinking of another. the performance hit is not at definition, but at execution. where its defined has an impact on how it's executed. I was specifically talking about event bubbling.

 

for example:

say that you add a onmouseover event to the body tag on a page which has it simulate a "tooltip" div which has a counter showing how many times the event fired. every time you move the mouse over the body it would have to update the counter and move the div to follow the cursor. now if the was on a busy webpage with a ton of elements, the hover event would run alot slower the more nested elements it needs to bubble out of. now if every element in the webpage had the onmouseover event added to it, it would run slightly faster since it doesn't have to bubble all the way up to the body to run the function,

 

the body tag and most other tags have onevent attribute simply because how the internet started out. think back in the old days before chrome/safari/firefox. Back to when there was only netscape and IE. There was no real standard and netscape came up with the ability to run special scripting on certain tags. onload (and other simlar html attributes) came first. attachevent, addevent listener, $.on()... all came later.

 

inline event calling is still a valid part of the current DTD because people still use it and use it as intended. but it shouldn't be, I wonder why it hasn't become depreciated. inline scripting has numerous disadvantages and violates XHTML with the fact that markup, and behavior should be separate from each other.

[Don E]

inline event calling is still a valid part of the current DTD because people still use it and use it as intended. but it shouldn't be, I wonder why it hasn't become depreciated. inline scripting has numerous disadvantages and violates XHTML with the fact that markup, and behavior should be separate from each other.

 

Just a quick question, who exactly determines what's considered bad practice or depreciated when it comes to JavaScript and HTML? I know W3C makes standards but for HTML and JavaScript, is it mostly what's going on in the development communities, meaning good practices, bad practices, are mostly opinions of web developers themselves?

[davej]

 

Just a quick question, who exactly determines what's considered bad practice or depreciated when it comes to JavaScript and HTML?

 

I would say the only real concern is being castigated by your employers, co-workers, peers, or potential customers.