In a recent article by San Oliver on AppleInsider, Kevin Lynch, CEO of Adobe, said that Flash will continue to evolve. According to Lynch, “I know that there are certainly some who are working on HTML5 who are out to kill Flash…” Lynch added that he believes that both can co-exist. “He doesn’t see the push for HTML5 as a move to ‘kill’ Flash. If Flash stayed stagnant, it would certainly go away,” he said. “But it’s not going to stay stagnant. We’re going to keep innovating.”

As a designer and user of Flash and Dreamweaver, I think that as the web continues to move towards HTML 5 and other open standards, Flash will become more of an authoring program for multimedia content in HTML 5, Javascript, and the Scalable Vector Graphics (SVG). Adobe is already doing that with Dreamweaver. Dreamweaver is a front end for authoring HTML, CSS, and implementing Javascript functions. Flash could fulfill a similar function for SVG. However, Jacek Artymiak states in his 2002 article that SVG is a bandwidth hog compared to SWF. Is this still true in 2010? Are Steve Jobs jabs at Adobe Flash warranted? I don’t know. But if Kevin Lynch is true to his word, he’ll keep his finger on the pulse of the web community and allow Flash to evolve with the standards it embraces. In the meantime, the burden will be on the development community to design multiple versions of a project to use different technologies that will play on the myriad number of devices that are out there. That’s nothing new!!

I will be giving a presentation on bringing business partners into the classroom using PBCL (Problem-based Case Learning). The presentation, on 2/21/2010 at 12:00PM will be for the second meeting of the Nashville Instructional Design Users Group. Visit http://www.makinglearningreal.org for more information on PBCL and for connecting with it’s community of practice.

In a rare video that I came across on YouTube.com, Cheng Man Ching discusses the movement of Chi in the body. I had the pleasure of studying Tai Chi for about 12 years with a number of teachers. One teacher that I had several seminars with, Benjamin Lo, was a senior student of Cheng Man Ching.

When beginners are learning web design, events can often be confusing. Are events part of HTML, Javascripts, or the DOM? What are they and how do we use them?

What is an Event?

HTML stands for Hypertext Markup Language. It is a language we use to give instructions to a browser how to structure and present information on a web page. A markup language cannot make decisions, store values, or respond to user choices beyond simple form elements. In order to make a HTML document dynamically responsive to user interaction, we must have a mechanism for the browser to be aware of itself and the different actions that take place. We do that through events.

An event is everything that happens within the scope of a session in a browser window. For example, opening and closing a browser window are events and are tracked by the browser software. Loading and unloading an HTML file are events. HTML elements have events. For example, with hypertext, i.e. links, moving the mouse over a link, off a link, or clicking a link are all events on that element.  We can take advantage of the fact that the browser is aware of every event that happens. We can give a browser instructions to follow when an event occurs and thereby introduce change in the browser in response to user choice. That is how we introduce interactivity.

The Document Object Model (DOM)

The ability of a browser to be aware of the elements it contains and “sense” events that happen is a result of requiring a browser to structure how elements on a page are referenced and organized. That identification and organizing structure is called the DOM or Document Object Model. It organizes elements in a window into a tree-like structure. Through that hierarchy, it knows how to find and address every element on the page.

Is an event part of HTML, Javascript, or the DOM?

Reading the entry on the DOM in Wikipedia can shed some light on that question. Originally, different browsers gave more or less access to the elements on a web page via the scripting agents that were created to control the pages. IE used Visual Basic and JScripting to control pages rendered in IE. Netscape used Javascript to control pages rendered in Netscape.  This proprietary method of controlling page elements was very inefficient and costly in the web design process and often resulted in pages that would not render correctly in multiple browsers. It became apparent after some time that multiple browsers would be used and that if the World Wide Wide was going to work efficiently, a standardized approach was needed.

The W3C brought the major browser vendors together to create a standardized method for allowing all browsers to control the elements on their pages so that code that was written could be predictably rendered on all browsers. In this light, browser agents (Firefox, IE, Safari, Opera, Chrome, etc) give access to page elements to both HTML and Javascript statements by way of the DOM.

How to access an event

It is up to discussion as to whether it is HTML or Javascript that actually “calls” an event. For example, the one of the first tags used in an HTML document is the <html> tag. Once the browser encounters that tag, it knows to render the page according to its understanding of the HTML language. Once it encounters the <script> tag, it knows to interpret the page statements to whatever language is indicated in the <script> tag. Unless you specifically tell the browser that you are using a scripting language, you can assume you are using HTML.

For example, the code…

<a href=”file1.htm” mouseover=”function1()”>link1</a>

… is an example of HTML coding. In this example the anchor tag calls function1(), defined elsewhere on the page in a <script> tag, when the mouse moves over the anchor link. The anchor tag is an HTML tag. The mouseover DOM event is being accessed, through HTML, in the same way a tag attribute is; i.e. the syntax of attribute name = attribute value is an HTML convention. The value of the event call is scripting code. So is the call an HTML attribute or is it a temporary call to a script using the underlying DOM. My guess is that different authors will argue both explanations.

References:

1. HTML event attributes, W3Schools. http://www.w3schools.com/html/html_eventattributes.asp
2. Javascript events, W3Schools. http://www.w3schools.com/js/js_events.asp
3. Document Object Model Events, W3C. http://www.w3.org/TR/DOM-Level-2-Events/events.html
4. Document Object Model. Wikipedia. http://en.wikipedia.org/wiki/Document_Object_Model