IE 8 includes a View Source window that displays a web page's source, complete with syntax highlighting and line numbering (see Figure 5-4). View Source reflects the original document downloaded by IE; changes made through the developer tools are not reflected in the View Source window.

Figure 5.4. The View Source window, introduced in IE 8

Prior to IE 8, IE opened Notepad to display the source of a web page by default; this option could be changed to open source in another external application. Developers wishing to change the default source viewer can do so through the developer tools; as in prior versions, source viewing can be redirected to any external application that supports it.

The File menu offers access to basic developer tools settings. The Undo All command reverts markup, layout, styling, and script changes back to those of the original page. Developers can customize the web page source viewer in the next option; instead of using the View Source window provided with IE, you can set the browser to open an external application. Last, the Exit option closes a Developer Tools session (Table 5-1).

The HTML tab allows for real-time inspection and editing of page markup. Almost all aspects of page markup can be changed, including element attributes, values, and overall markup structure.

Table 5-2 highlights the top-level UI commands.

Table 5.2. HTML Tab Buttons

Button	Shortcut	Description
	Ctrl+B	Navigates to an element's definition in the HTML tab's DOM Explorer when it is clicked in the current web page.
	Ctrl+R	Clears the browser cache for all domains and sessions.
	Ctrl+S	Saves the current markup in the DOM Explorer to a file. This includes edits made within the developer tools.
	F5	Syncs the DOM Explorer's markup to be that of IE's current DOM for a page.
	Ctrl+T	Displays the HTML source hierarchy and applied styles for the currently selected element in a View Source window.
	Alt+E	Toggles the display of a text editor containing the DOM Explorer's current markup.
	Alt+W	Toggles word-wrap for the DOM Explorer's text editor.

When a page is loaded, the hierarchy in the DOM Explorer represents IE's interpretation of a page's markup. This hierarchy is placed into a tree view. Parent elements can be expanded to show their children and element attributes can be edited inline. When an element is selected using Select Element by Click, the tree is expanded to reveal the element within the DOM Explorer hierarchy.

The Edit button (

Figure 5.5. DOM Explorer with editing box

Figure 5.6. DOM Explorer in Edit mode

If the current page makes changes to its own markup (e.g., with script or through Ajax calls), those changes are not reflected in the DOM Explorer. Those changes can be loaded by clicking the Refresh button. Conversely, changes made in the DOM Explorer are immediately applied to the current page. Developers wishing to edit the most recent version of the markup should click the Refresh button before making changes in the DOM Explorer.

The DOM Explorer allows for inline editing of attribute values; however, it does not allow attributes to be added, removed, or renamed. The Attributes pane (Figure 5-7) allows the remaining actions to happen for the currently selected element in the DOM Explorer.

Figure 5.7. Attributes pane and attribute name drop-down

Figure 5-7 shows an example of an element's attributes being edited in this pane. The current element type is shown at the top alongside UI elements for adding and removing attributes. Each attribute on the current element is displayed in the list box. You can change an attribute name by clicking its name and either typing it or selecting an attribute from a drop-down. Values associated with a named attribute can be changed by editing the corresponding entry in the Value column. Changes made to attributes are immediately reflected in the current document.

Locating specific elements on large pages can be hard using the DOM Explorer by itself. The Find, View, and Outline tools help lessen this burden by helping locate, access, and position page elements.

The Find menu (see Table 5-3) offers only one entry: Select Element by Click. This command—also found in the top-level buttons of each developer tool's tab—navigates to any element that is selected in the current web page when activated.

Commands in the View menu (see Table 5-4) provide detailed information about the context of page elements. The first set of view commands are for reporting: developers can overlay class, ID, link path, tab index, and access key information onto elements. Reporting tools in this menu allow developers to correct issues such as incorrect class, ID, and link references. A number of source viewers in this menu display page markup in a number of contexts.

Table 5.4. View Menu Entries

Menu Item	Shortcut	Description
Class and ID Information	Ctrl+I	Overlays class and ID information onto all page elements
Link Paths	-	Overlays link paths on relevant elements
Link Report	-	Generates a new web page with a list of all links found on the current page
Tab Indexes	-	Overlays tab indexes on all elements that have a defined tabindex attribute
Access Keys	-	Overlays access key information onto all elements that have a defined accesskey attribute
Source	-	Displays markup and applied styles for the currently selected element in a new View Source window
Source	-	Displays markup and applied styles for the currently selected element in a new View Source window
Source	-	Displays markup and applied styles for the current page through a new View Source window
Original	-	Displays markup for the original web page or last refreshed source data in the HTML tree in a new View Source window

The Outline menu (Table 5-5) surfaces commands that outline elements based on type or property. Borders drawn by these tools are temporary; they are drawn over the web page, are not added to markup or CSS, and are removed when the developer tools are closed.

Table 5.5. Outline Menu Entries

Menu Item	Shortcut	Description
Table Cells	-	Outlines all table cell elements in the current document.
Tables	-	Outlines all table elements in the current document.
DIV Elements	-	Outlines all <div> elements in the current document.
Images	-	Outlines all image elements in the current document.
Any Element...	Ctrl+O	Displays the Outline Elements dialog. This dialog allows custom elements to be outlined with a custom color.
Positioned Objects	-	Outlines all elements that have relative positioning.
Positioned Objects	-	Outlines all elements that have absolute positioning.
Positioned Objects	-	Outlines all elements that have fixed positioning.
Positioned Objects		Outlines all elements that have float positioning.
Clear Outlines	Ctrl+Shift+O	Clears all outlines.

Figure 5-8 shows the Outline Elements dialog. This figure demonstrates a scenario where <h1> elements are assigned a red border and <h3> elements are given a green one.

Figure 5.8. The Outline Elements dialog

Changes made to markup can be saved to a new file through the Save As icon (

The Joy of Fonts blog is a sample web page for demonstrating markup inspection (see Figure 5-9). The page's CSS layout was constructed using the Yahoo UI Builder; this tool created a page with a header, navigation column, content column, and footer.

Figure 5.9. The Joy of Fonts blog example

The document did not place the content in the right locations—instead of displaying the two-column format the page was supposed to be in, it stacked the parts on top of one another. (For reference, the correct result is shown in Figure 5-12.)

Markup inspection can help to shed light on the offending configuration. Markup can be inspected by opening the developer tools after the page is loaded. An analysis of the markup in the DOM Explorer (shown in Figure 5-10) shows that the main <div> on the web page (the one that contains the header, navigation, content, and footer) omitted the CSS class yui-t1 required by the Y!UI template.

Figure 5.10. Accessing the document <div> using Select Element by Click

The attributes on this element can be edited through the DOM Explorer to determine if this is the root cause. The class attribute on this <div> can be modified by clicking the current attribute value in the DOM Explorer and changing the value through an inline text box. Figure 5-11 demonstrates this inline box and, in this scenario, the addition of the token yui-t1.

Figure 5.11. Inline editing of attributes in the DOM Explorer

The new class value is applied to the <div> as soon as the inline editing box is closed (when you press Enter or change focus). The results are immediately reflected on the current page. Figure 5-12 shows the result of this markup change—the header, navigation, content, and footer are correctly placed.

Figure 5.12. Modified sample web page using markup inspection

Changes made through the developer tools can be saved to disk. The Element Source with Styles tool could be used instead to only save those elements and styles used by the document <div>.

The Style pane (Figure 5-14) lists CSS rules applied to an element. Properties applied to an element are organized by the rule they came from—inherited, inline, or directly from a selector.

Figure 5.14. The Style pane

Properties are displayed alongside a link to their corresponding files. Property values can be edited, enabled, or disabled; changes made to each of these are immediately reflected in the current page. Entries shown with a strikethrough represent those ignored by the browser.

The Style pane is not meant to convey the ordering of rules applied to an element; the Trace Styles pane, described next, is better suited to determining the ordering of rule application.

The Trace Styles pane displays an element's styles based on order and precedence of application. Since an element can inherit styles from its ancestors, multiple (and sometimes conflicting) properties may be applied to an element. Unfortunately, developers cannot easily determine which styles were applied to an element without more information from the browser.

Figure 5-15 shows the traced styles of an example element. Each applied style is shown here, and those styles that have been overridden during the cascade are struck through. The source of each CSS property is shown next to it, and clicking it will navigate to its definition in the Source pane of the CSS tab (described later in this chapter).

Figure 5.15. The Trace Styles pane

The Layout pane (Figure 5-16) displays layout information of elements that occupy space on a page. The offset, margin, border, padding, size, position, and z-index properties are available here.

Figure 5.16. The Layout pane

Developers can edit the layout values displayed in this view by clicking a value and making changes in the edit box that appears. Inline elements (such as <span>) that do not use certain layout properties will show all layout values even though IE's layout engine may ignore some of them.

The Attributes pane, described previously in the "Inspecting Markup" section, is useful for CSS properties as well. The drop-down list of attributes contains both HTML attributes and CSS properties; CSS properties added through the Attributes pane are added to an element's style attribute, as shown previously in Figure 5-7.

The CSS tab displays CSS files used on a page. Its toolbar includes a few commands that let developers access and navigate CSS files loaded by IE; these are shown in Table 5-6.

Table 5.6. CSS Tab Toolbar Buttons

Button	Shortcut	Description
	Ctrl+B	Navigates to an element's definition in the HTML tab's DOM Explorer when it is clicked in the current web page. This will switch focus away from the CSS tab.
	Ctrl+R	Clears the browser cache for all domains and sessions.
	Ctrl+S	Saves all changes made in the CSS tab to a file.
Stylesheet list	-	A drop-down list of files used by the current page that contain styles. Accessing an entry in this list will change the CSS displayed in the source pane of the CSS tab.

The CSS Source pane (Figure 5-17) displays the styles present in the document selected in the Stylesheet list. Styles and properties of a document are shown in a format similar to a stylesheet or <style> tag. All properties are shown under their owner selector (e.g., a tag, class, ID, or other selector type).

Figure 5.17. The CSS Source pane

Each property and selector can be enabled or disabled through a check box, much like the check boxes in the Style and Trace Styles panes of the HTML tab. Each entry in the list may be edited by clicking a targeted item. Changes made to list entries, either through value changes, enabling, or disabling, are immediately reflected in the document. The rules of each file, disabled or otherwise, may be searched and highlighted using the Search CSS box.

The Joy of Fonts blog presented in the "Inspecting Markup" section is built and ready to go from an HTML standpoint, but it lacks visual appeal. CSS styles have been added to spice up the page elements in a way that is fitting for a blog; Figure 5-18 shows the new blog page with styles applied. There are a few problems with the application of these styles; the developer tools are used in the following examples to find and mediate the root causes.

Figure 5.18. The Joy of Fonts sample page with added CSS

The first problem with this page is the font size of the blog entry date. The sample page's date, "November 20th, 2009," is significantly larger than the .9em value set in its entry-date CSS class. Using the Select Element by Click command, the date is clicked and its corresponding markup is shown in the DOM Explorer (shown in Figure 5-18). Trace Styles reveals that this element has inherited the font of the parent element's class, entry-title. Since the em unit is relative to the inherited font size, the font shown on the screen will be larger than intended (since the basis font is that of the parent, not the page). This style is changed to an absolute size of 14 pixels using the inline edit box; the results are shown in Figure 5-19.

Figure 5.19. Modifying the font size of the .entry-date class

The image in the content pane presents the next problem: it is lacking proper padding. Figure 5-18 shows a "Comic Sans saves the day" banner that is pressed up against the content text. Padding can be added to the image through the Layout pane in the HTML tab; Figure 5-20 shows the layout values of the image object in this view. The padding values are changed through inline edit boxes in the layout window; in this case, 10 pixels of padding have been added to each side of the image.

Figure 5.20. Editing padding using the Layout pane

The font color is the only major issue remaining with the Joy of Fonts blog. Figure 5-21 reveals why the blog content has been colored in red, something not intended during design. Select Element by Click and Trace Styles can be used once again to track down the source of the color.

Figure 5.21. Removing the color property overrides with the Trace Styles pane

The Trace Styles value in Figure 5-21 show that there is an !important color style being applied to the element, overriding the color: black style intended for the element. Analysis of the source code in Listing 5-1 reveals that a development artifact was carried over: a duplicate definition for .entry-content exists with a style of !important color, thus it is given precedence (despite the fact that it was declared earlier in the file).

/* Blog Entries */

.entry-content {  /* For Testing */
   font-family: Helvetica, Helvetica Neue, Arial, sans-serif;
   font-size: 1em;
   color: red !important;
}
...
.entry-content {
   font-family: Helvetica, Helvetica Neue, Arial, sans-serif;
   font-size: 1em;
   color: black;
}

Once this reference is removed from the stylesheet, the font displays correctly in black.

These fixes can be exported to a new CSS file through the CSS tab's Save button, or to an Element Source with Style file, as is done in the markup inspection example. Figure 5-22 shows the final result of these changes on the page, including the correct font for the blog entry date, proper padding on the image, and the correct font color for blog content.

Figure 5.22. Joy of Fonts blog after style and layout corrections

Items in the Disable menu (see Table 5-7) do just what you would expect: they disable certain features in IE. Disabling or hiding certain portions of the browser or a web page allows developers to potentially exclude those items as root causes of a bug. Developers may block script and CSS from running through this menu; they also have the ability to toggle the IE Pop-Up Blocker on and off. Images can be disabled as well; this feature is located in the Images menu (discussed in the next section).

Disabling the Pop-Up Blocker is useful when debugging JavaScript. The Pop-Up Blocker's algorithm checks to see if a pop-up was spawned through a user-initiated action. Breakpoints and other debugging steps could cause such checks to fail.

The Images menu provides access to those tools related to images and image management in web pages. They exist to help developers gather the right information (size, description, source location, etc.) for layout and design decisions. Table 5-8 outlines these in more detail.

IE developer tools contain a few extra goodies that don't fit into any major category, yet do provide some useful functionality. There are three such tools that fall into this category: a browser resizer, rulers, and a color picker. Table 5-9 outlines Tools menu.

Table 5.9. Tools Menu Entries

Menu Item	Shortcut	Description
Resize	Ctrl+Shift+1	Resizes the current browser window to 800 pixels in width by 600 pixels in height.
Resize	Ctrl+Shift+2	Resizes the current browser window to 1024 pixels in width by 768 pixels in height.
Resize	Ctrl+Shift+3	Resizes the current browser window to 1280 pixels in width by 768 pixels in height.
Resize	Ctrl+Shift+4	Resizes the current browser window to 1280 pixels in width by 1024 pixels in height.
Resize	-	Opens a dialog containing custom browser size configurations. These custom browser sizes are persisted after the developer tools are closed.
Show Ruler	Ctrl+L	Opens the Ruler tool, allowing ruled lines to be placed on top of an HTML document to measure pixel offsets and distances.
Show Color Picker	Ctrl+K	Displays the Color Picker tool, allowing the reading of onscreen colors and the copying of those colors to the clipboard.

The Resize Browser tool literally sets the IE window to a specific size. This is useful for projects that require support for an exact, minimum, or maximum resolution (e.g., screen sizes on netbooks). The custom size dialog allows for custom window sizes beyond the four preset values, as shown in Figure 5-23.

Figure 5.23. Resize Browser tool

The Ruler (see Figure 5-24) allows elements to be measured with metered lines. The Styles, Trace Styles, and Layout panes provide developers with WYSIWYG functionality in terms of element positioning, but these tools rely upon a developer supplying a value either from a guess or from work done outside of the developer tools.

Figure 5.24. The Ruler tool, and a measurement example

The Color Picker is a simple dialog that displays the current color underneath the mouse cursor. Since the tool is run under the context of a tab (as described in the architecture portion of Chapter 1), it can only pick up colors from locations within the tab: the status bar, the explorer bars, the scrollbars, and the page itself. A selected color can be copied to the clipboard through the "Copy and close" button, as shown in Figure 5-25.

Figure 5.25. The Color Picker tool

The HTML and CSS tools were used in the previous sections to fix layout and styles of the Joy of Fonts blog. This example demonstrates how the IE developer tools' Extended Toolset can be used to finalize the fit and finish of a page.

The Joy of Fonts blog will be given a decorative header. The header used in the preceding two examples consisted of gray text ("The Joy of Fonts—A Blog") with a dark background. The header is modified in this example; the word "Joy" is made to stand out from the rest of the header text—in this case, it will have different CSS styles than the rest of the title (jump ahead to Figure 5-29 to see the result).

Listings 5-2 and 5-3 show changes made to the markup and styles, respectively; the word "Joy" was removed from the header and placed in a <span>. A transparent image file was added to create a space between "The" and "of."

<div class="header">
   <h1>
      The
      <img class="spacer" src="images/spacer.gif" alt="(blank)">
      of Fonts - A Blog
   </h1>
   <span class="deco-text">JOY</span>
</div>

A new <span> is placed in the header to create the intended effect. The CSS z-index property will let the word "Joy" be overlaid atop the existing header, and the image will be resized to create a space between the other header text, making room for the decorative word.

.spacer {
   height: 5px;
}
.deco-text {

position: absolute;
   font-family: Baskerville, Times, Times New Roman, serif;
   font-size: 80px;
   color: white;
   margin: 0;
   padding: 0;
   font-weight: bold;
   font-style: italic;
   top: −25px;
}

Figure 5-26 shows the changes made to the markup. Unfortunately, the <span> is displayed too far left of the intended location.

Figure 5.26. The Joy of Fonts blog with incorrectly positioned decorative text

The Ruler tool can be used here to determine the best positioning values for the new stylesheet entries. Two measurements are made (in Figure 5-27). The first is that of the distance between the start of the word "Joy" and the end of the word "The"; this represents how many pixels the decorative text should be moved to the right. Next is the width of the word "Joy," representing the space it will need to occupy in the header (thus the desired width of the spacer image).

Figure 5.27. Ruler tool being used to measure object size

These two measurements indicate that the span needs to be aligned 60 pixels to the right of its current position and the spacer image needs to be 150 pixels in width.

Figure 5-28 demonstrates the next step in this process: setting the property values with information gathered from the Ruler. The CSS left property for the <span> is set to 60px and the width of the spacer <img> element is set to 150px.

Figure 5.28. Adjusting positioning with the Attributes pane

The text is now in its proper position, and its color is changed to white to blend in with the page background. Figure 5-29 shows the new header with the decorative "Joy"—a very emblematic logo for a font blog.

Figure 5.29. Decorative text placed within the Joy of Fonts sample web page

The Browser Mode menu enables developers to simulate a version of IE: IE 7, IE 8, and IE 8 Compatibility View. This is not browser virtualization; instead, a browser mode tells IE to masquerade as a specific version. Different information is sent back to web sites based on the browser mode chosen through the developer tools:

Each browser mode is associated with a set of document modes (see Table 5-10). The available document modes are the same ones accessible through <meta> tags, HTTP headers, and the browser UI. For instance, IE 8 Standards mode isn't available in IE 7, and thus is not available in the IE 7 browser mode.

The Validate menu links to online services that validate a web page against known standards in markup, styles, and accessibility. For HTML and other forms of markup, specific standards noted in a page's DOCTYPE header will be used during the validation process. Table 5-11 outlines the available validation services in the IE developer tools.

Table 5.11. Validate Menu Entries

Menu Item	Description
HTML	Sends the current URL to the W3C Markup Validation service for HTML validation.
CSS	Sends the current URL to the W3C CSS Validation service for CSS validation.
Feed	Sends the current URL to the http://feedvalidator.org FEED Validator service.
Links	Sends the current URL to the W3C Link Checker validation service.
Local HTML...	Opens a new tab to the W3C Markup Validation service for customized HTML validation runs. No data is sent from the current page.
Local CSS...	Opens a new tab to the W3C CSS Validation service for customized CSS validation runs. No data is sent about the current URL or developer tools data.
Accessibility	Sends the current URL to the HiSoftware Cynthia Says WCAG Checklist service for WCAG accessibility compliance validation.
Accessibility	Sends the current URL to the HiSoftware Cynthia Says Full Reporting service for Section 508 compliance validation. The service is opened in a new web page.
Multiple Validations...	Opens a dialog that allows a developer to load multiple validators for the current URL. Each validator chosen loads in a new web page.

These tools work by sending URLs to online services. Pages located on a local filesystem or a corporate intranet will not work with these tools.

The Script tab, shown in Figure 5-30, consists of command buttons that control the most used features in the debugger, a toggle switch for debugging, a drop-down list that permits access to all JavaScript files loaded for a given document, and a number of panels that expose the UI of the debugger itself.

Figure 5.30. The JavaScript Debugger UI

Developers can also use the search box to search loaded script for matching text. Table 5-12 highlights the commands, buttons, and tabs available.

Table 5.12. JavaScript Debugger Buttons

Button	Shortcut	Description
	Ctrl+B	Navigates to an element's definition in the HTML tab's DOM Explorer when it is clicked in the current web page. This will switch focus away from the Script tab.
	Ctrl+R	Clears the browser cache for all domains and sessions.
	F5	Restarts a script after a breakpoint has been hit, and continues running the script until another breakpoint is reached.
	Ctrl+Shift+B	Pauses script execution immediately.
	Ctrl+Shift+E	Pauses script execution when an error is reached, even if no breakpoint is set. This is on by default when the developer tools are open.
	F11	Executes the next line of script after a breakpoint.
	F10	Executes the next line of script within the current function (steps over script lines that would leave the current function).
	Shift+F11	Leaves the current function and breaks at the next line of script in the function's caller (if any).
Start/Stop Debugging	F5 (Shift+F5)	Starts/stops debugging.
Script list	-	A drop-down list of scripts used by the current page. Accessing an entry in this list will change the script displayed in the source pane of the Script tab.

The panes to the right of the command buttons and drop-down give access to more detailed information regarding script execution and debugging events, such as the console and call stack.

The Source pane, shown in Figure 5-31, displays syntax-highlighted contents of each file containing script loaded in the current page. Developers can switch between files using the Script list in the main Script tab UI. Beyond viewing source, the pane is used to set, modify, and remove breakpoints for running script.

Figure 5.31. The Script tab Source pane

Breakpoints can be set on lines of script (statements, functions, and event handlers) after the JavaScript debugger has been started. When the JavaScript engine encounters a breakpoint, script execution will pause until action has been taken to stop or continue the script. Breakpoints can be set in three ways:

Breakpoints on specific lines of code can be modified through the same context menu used to set them in the Source pane (see Figure 5-32). These can be deleted or disabled, or a condition can be placed on their execution.

Figure 5.32. Existing breakpoint context menu in the Source pane

Conditional breakpoints allow more granular control over when a breakpoint is triggered. Through this same context menu (or through the Breakpoints pane discussed later), logical conditions can be set on a given breakpoint using variables and functions of the loaded script (see Figure 5-33). The next time the JavaScript debugger reaches the breakpoint, the script will only be paused if the condition placed on it evaluates to true.

Figure 5.33. Conditional Breakpoint dialog

The Breakpoints pane displays currently selected breakpoints and their status, and allows users to enable, disable, or remove them. Double-clicking a breakpoint will open the script file associated with that breakpoint and navigate to the statement it was set on. Just like the Script pane, each entry in the breakpoints pane provides a context menu that can be used to manage breakpoints already set for a page (see Figure 5-34).

Figure 5.34. Breakpoints pane context menu

The Locals, Watch, and Call Stack panes allow developers to see activity in functions and variables at a given point in time. The Locals pane displays objects local to a function and their values. The Watch pane displays the same for a list of objects that have been chosen by a developer. The Call Stack pane represents an ordered list of functions called to reach the current statement. To view the call stack, script execution must be paused. Items in the call stack can be added to the Locals and Watch panes while script execution is paused during a breakpoint.

Objects can be added to the Watch list during breakpoints; the context menu for a given breakpoint exposes a command to add a specific object to the list (see Figure 5-35).

Figure 5.35. Active Breakpoint context menu with Add Watch menu option

The Debugging Console pane allows developers to inject single- or multiline JavaScript statements into the current page without the need to modify the original source (see Figure 5-36). It also provides a number of logging functions that can be used to debug scripts running within the web application.

Figure 5.36. Web page running script input in the Debugging Console pane

The context menu on the Debugging Console pane also allows messages to be filtered by types defined in the following functions and UI notification elements.

The Debugging Console pane can be accessed from a web page through the console object in JavaScript. This object handles one-way communication from a page to the console. There are a number of predefined functions that provide different types of console messaging; these functions can be expanded through expandos on the console object itself.

The console object is only available when the developer tools are open, and is not available in IE 7 and earlier releases. This applies to IE 8 and higher; the object may be available in other browsers under different conditions. Scripts using the console object should check for the object's existence before using it.

All console logging functions, save for the clear() function, can accept an arbitrary number of parameters given that those parameters match substitution tokens in the message parameter. This means that the console object can handle type conversion automatically, much like C's printf(), but in a limited capacity. The tokens used in substitutions are

Unlike the substitution style present in printf(), these tokens cannot be modified to convert a substituted value further; for instance, %d cannot be rewritten as %02d to pad the integer value with zeros until it is at least two digits wide.

Listing 5-4 demonstrates the basic usage of the console object.

//  Check if the console object exists
if(window.console) {

   //  Write entries to the console
   console.log("This is a log entry!");
   console.info("This is information!");
   console.warn("This is a warning!");
   console.error("This is an error!");
   console.assert(false, "This is an assert!");

} else alert("Console object does not exist!");

When the code from this example is run, the console will display the messages with their respective icons, as shown in Figure 5-37.

Figure 5.37. Basic console logging and message types

Console messages can be simplified using substitution tokens. The message parameter itself is a String type; thus, some other types might require conversion to place it in the message. Developers can depend on the JavaScript engine for such a conversion by placing a token into the message where data of another type should reside and appending that variable as an additional parameter. Listing 5-5 demonstrates this.

//  Check if the console object exists
if(window.console) {

   //  Define some variables
   var u = 3.14159;     //  Double (Float)
   var v = 8675309;     //  Float
   var x = 42;          //  Integer
   var y = new Date();  //  Object
   var z = "Marmite";   //  String

   //  Write to the console
   console.log("Double: %d", u);
   console.info("Floats: %f %f", v, u);
   console.warn("Integer: %i", x);
   console.error("Object: ", y);
   console.assert(false, "String: %s", z);

} else alert("Console object does not exist!");

This code outputs the result, as shown in Figure 5-38.

Figure 5.38. Console logging using string substitution

Finally, Listing 5-6 is an example of a custom function created to send data to the Debugging Console pane. Developers wishing to create a customized logging function can place that function onto the console object itself. This allows for a single point of conversion from a custom console logging string into one that can be displayed in the Debugging Console pane.

//  Check if the console object exists
if(window.console) {

   //  Create a new method on the console object
   console.debug = function() {

      //  Get all the arguments and concat them
      var concatArguments = arguments.join(" ");

      //  Grab the current date object
      var now = new Date();

      //  Construct a new message format that uses the
      //  "Debug: " prefix and appends a time to the end
      //  of the message
      console.info("Debug: " + concatArguments +
                   " - " + now.toTimeString().split(" ")[0] +
                   " " + String(now.getUTCMilliseconds()) + "ms");

   }

   //  Write to the console
   console.debug("This is a custom method!");
   console.debug("This is a custom method...", "with multiple input parameters");

} else alert("Console object does not exist!");

The code here outlines the creation of a new function on the console object: console.debug(). This function appends a custom message (Debug:) and a timestamp to every string being sent to the Debugging Console pane. Once the final string is concatenated, the function places the new string into the console through the console.log() function. Figure 5-39 demonstrates the result of this, displaying the two calls made into the new function at the end of the code sample.

Figure 5.39. Console logging using custom functions/expandos

JavaScript debugging varies in difficulty based on the size and complexity of a web site. This section uses a web page found on the companion web site to highlight the features of the JavaScript debugger found in the IE developer tools. There's a catch, though: the example won't work right off the bat. This is where the JavaScript debugger comes in.

The code in Listing 5-7 is a buggy script in the aforementioned example. The script has two functions: foo(), which contains a string variable called bar, and displayBar(), which pops up an alert dialog containing the string contained in foo()'s bar variable. When the script is executed, it attempts to show the alert dialog by calling display() (hint: that's the first problem).

<script type="text/javascript">

   //  Create a foo object that contains
   //  a variable bar
   function foo() {

      this.bar = "golden";

   }

   //  A function to display the current value of bar
   function displayBar() {

      try{

         //  Display the value of bar
         alert(foo.bar);

      } catch(exception) { }

   }

   //  Display the bar variable
   display();

</script>

JavaScript debugging is turned on with the Start Debugging button on the Script tab, and the page is reloaded. When the script is run, the debugger throws a balloon on the line of code that encountered an error: the call to display(). The error raised was "Object expected," which is shown both in the information balloon and the console (Figure 5-40).

Figure 5.40. The JavaScript debugger breaking on an error

The error makes sense: there is no function named display() in the script. The script does, however, contain a function called displayBar(), which happens to be the code that call was intended for. Once the error is fixed, the page is reloaded and the debugger won't break on any more critical errors. The problem remains, however: no alert dialog is shown.

Breakpoints can be used to debug defects in script that don't cause breaking errors. The displayBar() function is responsible for showing the dialog. A breakpoint on this function will allow for analysis of what is causing the failure. Figure 5-41 shows this breakpoint.

Figure 5.41. Setting a breakpoint on a line of JavaScript

The displayBar() function is called as the page is reloaded. The JavaScript debugger, upon entering this function, triggers the breakpoint set on the displayBar() call, as shown in Figure 5-42.

Figure 5.42. The JavaScript debugger pausing on a set breakpoint

The call was reached, so the problem may lie within the function. The Step Into command steps into and pauses on the first line of the function. Figure 5-43 shows this pause, and it also displays the offending line of code: a call to an element.

Figure 5.43. Using the Step Into command to pause inside a called function

Stepping through the debugger reveals that alert(foo.bar) didn't work; the debugger didn't break, however, because there was a try...catch statement surrounding the call. This is where the debugger stops working and the developer begins thinking (again, the developer tools are not a catchall toolset). The problem here is with the use of foo.bar to display the string "golden"; foo is the name of a function that is treated like an object, but it can only be used as an object if a new instance of it is created.

The variable myFoo was created and instantiated to be new foo(), a new instance of the foo object. Listing 5-8 shows this code change. After a reload, a dialog pops up with the word "golden," showing that the script errors were fixed correctly and the page is now, in fact, golden (Figure 5-44).

<script type="text/javascript">

   //  Create a foo object that contains
   //  a variable bar
   function foo() {

      this.bar = "golden";

   }

   //  A function to display the current value of bar
   function displayBar() {

      try{

         //  Create a new instance of foo
         var myFoo = new foo();

         //  Display the value of bar
         alert(myFoo.bar);

      } catch(exception) { }

}

   //  Display the bar variable
   displayBar();

</script>

Figure 5.44. A message box emitted from a correctly working script

The profiler collects data on the time spent in each JavaScript function as script executes, and displays a report after it is stopped. It may be started and stopped at any time, and does not require the page to be reloaded (however, since most script runs during page load, it is most effective when profiling during the page load process). There is no minimum time the profiler must run to collect data.

The Profiler tab consists of top-level UI elements (shown in Figure 5-45) that toggle the profiler and enable developers to view reports from profiler runs within the current session.

Figure 5.45. The JavaScript Profiler UI

Table 5-13 outlines the functionality of these elements.

Table 5.13. JavaScript Profiler Buttons

Button	Shortcut	Description
	Ctrl+B	Navigates to an element's definition in the HTML tab's DOM Explorer when it is clicked in the current web page. This will switch focus away from the Profiler tab.
	Ctrl+R	Clears the browser cache for all domains and sessions.
	-	Exports data from a currently selected report to a comma-separated value (CSV) file that can be loaded by most spreadsheet and database applications.
Start/Stop Profiling	F5 (Shift+F5)	Begins or ends the JavaScript profiler session.
Current View drop-down	-	Determines the format profile data should be displayed in.
Current Report drop-down	-	Selects a profile result set to be viewed.

After a profile has been collected, the results can be viewed in the tool itself. There are two main ways of viewing this data: Function view and Call Tree view.

Each view of a profile run displays the same basic information: functions called, the number of calls made, the time it took to run those functions, and metadata such as the resource location and the line number for a specific function in that resource. By default, IE displays the gathered data in Function view (shown in Figure 5-46). Developers can add and remove data points from the display and results may be ordered by any column. The available data points are

Function view displays a list of timing data by function name. Developers looking for raw timing information will find Function view most useful—the functions that are detrimental to performance can be quickly identified.

Figure 5.46. Function view of a profile

Inline blocks are not well represented in the profiler's data. In order to get accurate timing information for a block of code, developers should "name" that block of code by wrapping it in a function call.

Call Tree view, shown in Figure 5-47, contains all the data provided by Function view. Instead of being organized by name, it is organized by functional relationships.

Figure 5.47. Call Tree view of a profile

The call tree format provides insight into the overall performance impact of function relationships.

The Export Data tool (

Figure 5.48. Exported profiler data loaded into Microsoft Excel

The sample web page for this section (on the companion web site) demonstrates how to use the JavaScript profiler to time data flows and function calls (Figure 5-49).

Figure 5.49. Example web page for modeling JavaScript performance

To start the performance demo, a user clicks the Run Function a(...) button at the top of the page. This kicks off a series of function calls (named "a" through "e") and simulated "work" that ultimately result in a set of timing data. While a function is running, its status is reflected on the page as either Idle, Running, or Complete. Once all functions are complete, the time it took to process each function call and the work done by each can be seen in the profiler's report viewer.

There are five worker functions present on the web page, again named alphabetically "a" through "e." Function a() starts a cascade that calls each of the other functions once. All functions except a() are started after a certain delay specified in milliseconds; these delays can be modified in a set of input boxes at the top of the page. Functions c() through e() run some nonperformant tasks a set number of times (the Loop Max input boxes indicate how many times this task is performed by each function).

The flow diagram in Figure 5-50 shows how each function is called.

Figure 5.50. Call graph of the sample web page

When the onclick event of the Run Function a(...) button is triggered, function a() is called by the JavaScript engine. Functions b() and e() are called after their respective delays; function b() proceeds to trigger functions c() and d() after a delay as well. Functions c(), d(), and e() each call a doWork() function (whose code is shown in Listing 5-9) the number of times indicated in the Loop Max input boxes.

//  A function whose sole purpose is to waste time.
function doWork() {
   //  Do some really random, wasteful work.
   var containerDiv = document.getElementById('container'),
   var newDiv = document.createElement("div");
   newDiv.setAttribute('id', "tempDiv" + String(parseInt(Math.random() * 1000000)));
   newDiv.innerHTML = "   ";
   containerDiv.appendChild(newDiv);
   containerDiv.removeChild(newDiv);
}

The raw results from the profile run are shown in Call Tree view in Figure 5-51. The results show that d() ran for the greatest length of time, followed by e(), c(), a(), and b().

Figure 5.51. Results from profiling the sample page

Clearer results can be seen using external tools and charting software. The results here were imported into Excel and placed into a chart (Figure 5-52) showing when each function started and ended.

Figure 5.52. Charted results highlighting each function's running time