Finding and fixing problems with JavaScript and CSS
Not all browsers are created equal. As users, we probably have our favourite browser – but webmasters do not have that luxury.
Not all browsers are created equal. As users, we probably have our favourite browser – but webmasters do not have that luxury – their sites should work with all the mainstream browsers. While there are many browsers in existence, four of the best known and most used are Microsoft’s Internet Explorer, Mozilla’s Firefox, Apple’s Safari, and Opera. The latter three function, from a webmaster’s viewpoint, fairly similarly. Internet Explorer though, despite many improvements in version 7, still lags behind somewhat.
As websites become more complicated and embrace the new technologies that are available, the demands on the browser increase. Complex websites rely heavily on Cascading Style Sheets (CSS) and JavaScript (JS) in addition to HTML and other media/graphics. The latest versions of Firefox, Safari, and Opera are mostly standards compatible – they all pass the Acid 2 test (http://acid2.acidtests.org/) which examines browser rendering of a select set of commonly used CSS 2 styles. Neither Firefox 2 nor Internet Explorer 7 passes the Acid 2 test. Currently, none of the browsers mentioned above pass the Acid 3 test for, the yet to be finalized, CSS 3.
While it is important to know the capabilities of different browsers, as a webmaster, little can be done about them. Instead, one must do their best to design a site that renders correctly in each browser and degrades gracefully if the desired functionality is not present. The two browsers with the largest market share are Internet Explorer and Firefox – and those will be the focus of this article. Since Firefox is more standards compatible than Internet Explorer (especially the beta of Firefox 3), has a significant market share (although, not nearly as large as that of IE), and has many available add-ons, it would be advisable to design a website for it and subsequently work on Internet Explorer compatibility as opposed to vice versa. Standards provide a level playing field and a direction for the future – and you get compatibility with (at least) three browsers for the price of one. So the question is – how can you find out where the problem is on your site? The best tool I have found so far is Firebug. Firebug: http://www.getfirebug.com/
Firebug provides JavaScript debugging, DOM inspection, style information, and page requests. When errors occur, Firebug identifies them in its console. It displays an error count in the status bar, showing additional information on the error, and takes you to the line/function that caused the exception; it can display the current states of variables, allows watches to be added to variables, and allows the use of breakpoints and stepping in JavaScript debugging. Breakpoints can also persist across page refreshes and can be triggered by issuing a ‘debugger()’ call in your script.
In HTML view, a side pane is visible in Firebug, which presents, not only additional DOM information, but also one of my favourite features – its ability to display style and layout information. It will identify the applicable styles for an element, show their inheritance, provide a breakdown of an element’s position (offset, margin, border, padding), and draw boxes (both in Firebug and on the page itself) to visually display each attribute.
Another handy feature of Firebug is its list of page requests. It identifies all the requests made by the page, how large the response was (and keeps a running total), how long the request took (and keeps a running total), and how much data was cached, as well as providing the response (body/content), response headers, and image previews – and it displays all the time information on a timeline.
Despite all these great things, there is always room for improvement. It should be noted that there are some indications that Firebug together with the latest beta of Firefox 3 crashes more often than either Firebug with Firefox 2 or Firefox 3 on its own – and it has been suggested that this may arise from a JavaScript stack overflow. Firebug, however, can be disabled or enabled for specific sites, which greatly reduces the effect of this potential issue.
Overall, Firebug is a must-have tool for any web developer. It makes simple work of identifying an erroneous line of code, and allows one to identify problematic constituents of load time. Another add-on ‘YSlow’ by Yahoo! works with Firebug to provide suggestions for load time optimizations.
Web Developer Toolbar: http://chrispederick.com/work/web-developer/
Web Developer is another useful add-on for Firefox and comes in the form of a toolbar. It is primarily geared towards providing information and identifying elements, however its features do extend beyond that. It provides information about JavaScript, CSS, and cookies – it allows one to disable individual style sheets or add external style sheets, as well as to edit the existing CSS; it enables one to view/add cookies; and will provide a single page listing of all the CSS or JavaScript used by the page.
Unfortunately, it does not appear to take this from the DOM, so classes added by JavaScript are not displayed. Web Developer can show information about each element (with outlining capabilities) – its features are often grouped by element (e.g. forms, images, etc) however, one can specify custom elements to be outlined as well.
This add-on includes links to validation sites (which can be customized), enables inline HTML editing, and provides a wide variety of other miscellaneous information (response headers, page colours, etc). Most of the information that the Web Developer Toolbar provides, is for a site overall – for instance, it can identify all the images on a page and their dimensions (with the information displayed on the page itself) – which can be considerably quicker than looking up the information for each element individually.
Due to its nature, this add-on is well suited for testing a site under (a limited set of) different circumstances (screen size, CSS disabled, etc). Additionally, it can be of use in a basic security audit of the site – it reveals hidden fields, allows one to bypass character limits on fields, and alter other (HTML based) client side restrictions put in place. It can also be an asset if you are trying to get a quick idea of how a site works. While there is a lot of overlap between the capabilities of Firebug and Web Developer, the latter does provide some features that Firebug does not, and provides shortcuts for many others functions.
Unfortunately, a website rendering properly in Firefox, Opera, and Safari, does not say anything for how it will render in Internet Explorer, however the latter is not a browser one can ignore. While, at one point, debugging complex websites in Internet Explorer was little more than wishful thinking, it is now very much a reality.
Internet Explorer Developer Toolbar: http://tinyurl.com/4955be Last year (2007), Microsoft released the Internet Explorer (IE) Developer Toolbar, a plugin for IE, which provides many of the capabilities of Firebug and the Web Developer toolbar in Internet Explorer. The IE Developer Toolbar allows for disabling of JavaScript and CSS, viewing DOM source (including generated CSS classes), outlining of elements, image information, some control over the cache, and validation links.
As with Firebug, the IE Developer Toolbar can be pinned to the browser window or function as a separate window. At the top, it has a menu with much of the same functionality as the Web Developer toolbar. However, it lacks the editing features that Web Developer offers – you cannot add cookies and it doesn’t provide direct methods for editing CSS, HTML, or form elements. It does have a handy ruler, magnifying glass, and colour picker – but those probably aren’t what will draw you to this plugin.
The real functionality lies in its ability to show the attributes and style information for a selected element – it also has the option to show read-only properties and default (i.e. unaltered) styles. While it will show style and element source for a single element, it does not narrow the styles to only those applicable – e.g. border is not inherited but it will list the border of the parent element.
Although it is not possible to directly edit the page source, the IE Developer Toolbar will allow for the addition (and editing) of attributes and styles on a per element (node) basis.
The IE Developer Toolbar provides many useful features, however, it does not have JavaScript debugging capabilities. This can be somewhat overcome using an external debugger (e.g. Microsoft Script Editor), which needs to be enabled from IE’s Advanced Options (uncheck ‘Disable Script Debugging (Other)’). Of course, it isn’t really a toolbar either – although it does add a button to your toolbar – but that is just semantics.
DebugBar: http://www.debugbar.com/?langage=en
Another useful plugin for debugging in IE is DebugBar. Unlike the IE Developer Toolbar, this is a side pane and cannot be unpinned, it also adds a toolbar to IE – although its real features are not to be found there. The side pane allows for browsing the DOM and identifying elements, as well as displaying element source and style. (For those of us who are real geeks – you can actually use the DebugBar to see the nodes that the IE Developer Toolbar adds in when it outlines elements.)
Despite many similarities to the IE Developer Toolbar, DebugBar does have a few features that are lacking from the former. It will display the computed style of an element, a visual representation of the layout (offset, margin, border, padding), and a list of the requests made by the page. For the computed style, it considers inheritance and displays the actual applicable style of the element. For each page request, it shows the response headers, content, timing, and size/cache information.
DebugBar does have some basic JavaScript display functionality (it will show the source of some functions and has a JavaScript console), however it does not have any useful level of JavaScript debugging (breakpoints, stepping, etc). Furthermore, while it does provide a good amount of information, it lacks the ability to make live edits to the page.
For web developers creating complex pages, the IE Developer Toolbar is an essential tool. DebugBar is also a useful addition as it offers information not available through the IE Developer Toolbar, both can be used together, and, as with Firebug and the Web Developer Toolbar, are free for personal use (DebugBar is the only one that is not free for commercial use as well).
As the complexity of web pages increases and web developers increase the level of interactivity present on their sites, finding the problems becomes increasingly harder. Now however, the tools are available to pinpoint the problems and the rest is limited only by one’s creativity.
Relevant Software Information:
Mozilla Firefox 3.0 beta 5Firebug v.1.1.0 beta 12Web Developer Toolbar v.1.1.5
Internet Explorer 7.0.5730.11DebugBar v.5.0.2Internet Explorer Developer Toolbar v.1.00.2188.0
Opera 9.50 beta (Build 9656)Apple Safari 3.1 (525.13)
Operating System: Windows XP Pro (32 bit) SP2
Chris Pinto is Biology major and teacher in Ontario (Canada), with a passion for computers. Currently, Chris is involved in development on sites such as www.ficcity.com and www.teachingcity.com. He will be contributing articles to The Tech Herald on topics related to website design and system setups. He can be reached via this website.
There are currently no comments for this article. Be the first to comment!
Advertising
There are currently no comments for this article. Be the first to comment!