JavaScripting Opera 7 / Gnome Bucks - WebReference Update - 021212 | WebReference

JavaScripting Opera 7 / Gnome Bucks - WebReference Update - 021212

WebReference Update: December 12, 2002

This week guest author Kenneth Tibbetts explores the new Opera 7 from a JavaScripting perspective. Elsewhere on the web this week don't miss New Architect's profile of Chris Pirillo's Lockergnome, and how he has successfully monetized his content. A nifty free tool, GetContentSize, calculates the signal to noise ratio from your HTML code. How does your site stack up? In Net news this week Google launches Froogle for comparison shopping, just in time for the holidays. A Xerox chip breakthrough, and Microsoft warns of Java flaws.

http://www.webreference.com*- link to us today
http://www.webreference.com/new/*- newsletter home
http://www.webreference.com/new/submit.html*- submit article

New this week on WebReference.com and the Web:

1. FEATURE:  Up to Speed with Opera 7 - Notes for Code Writers
2. OTHER VOICES: 
3. NET NEWS: 

Like what you see? Get our front page e-mailed to you every business day with our HTML newsletter. Just send an e-mail to:

subscribe-html@webreference.com

or for this text newsletter:

subscribe@webreference.com

Spread the word! Feel free to send a copy of this newsletter to your friends and colleagues, and while you're at it, snap a link to WebReference.com.


1. FEATURE: Up to Speed with Opera 7 - Notes for Code Writers

This holiday season brings us the latest version of Opera, Opera 7. Still in beta, and not yet available on all platforms, it looks like a winner to me. Opera has always had a lot going for it - great CSS support, fast rendering speed, and a small footprint on the client machine. The biggest gap between Opera and the major browsers (Mozilla Sea Monkey and Netscape 6+, and Microsoft's Internet Explorer) has been in accessing and scripting document objects. For the most part, a page in Opera could be fast and beautiful, but not especially dynamic. The gap is closing in Opera 7.

After a couple of weeks of road testing I've come up with a short list of gotchas - places where you can get into trouble if you aren't aware of certain Operatic peculiarities. This is not a big list - especially for the first beta. But since writing scripts that will run on Opera 7 is a new deal, it may be helpful to see some of the places where we can go wrong - before the emails from our users and clients begin.

* Basic JavaScript gotchas
* NodeLists
* Style gotchas
* keyPress events
* Display and scrollTo gotchas

1. Basic JavaScript gotchas

The first thing that will get you will probably have something to do with the way Opera 7 handles null, undefined and empty string comparisons. At least for now it seems to be safest to treat those three values as not equal, and test for all three to avoid any problems.

Opera 7 doesn't support regular expression syntax as well as the majors do. Specifically, on look ahead assertions - syntax like:

/\bw*\s*(?=\()/g;

When used in an exec or match, the return should be word strings that are followed by an open parenthesis, without including the parenthesis in the match. Opera found the strings OK, but returned some extra stuff along with the values I was looking for.

2. NodeLists

When you are manipulating a document, adding or removing elements, or changing the order of a document's elements, you often use the NodeList returned from element.getElementsByTagName(tagname). The returned value is like an array, but it is not an array - a NodeList changes as the document changes. The major browsers have returned a NodeList as an object, which could be handled like an object, including enumerating its members. Opera 7 surprised me by failing on such a page. After a bit of querying I realized that the NodeList in Opera was being returned as a Function, and not as the more general Object I was writing for. It may be a small thing, but so is the nut that holds the propeller. It was enough to require some code changes.

3. Speaking of Style

Opera has always done a wonderful job at rendering pages with CSS styles, either inline or from style sheets. It still has a couple of weaknesses - it does not support the cssText property, and it does not allow any reading or writing of the style sheets, or access to the computed style of an element. None of these shortcomings will necessarily break a page, and you can read or write to any element directly through its inline style object. But be careful of the methods you have been calling for the other browsers. Opera will try anything that doesn't have a darn good fence around it.

I needed to block browsers that couldn't handle the CSS2 getComputedStyle method for reading the actual displayed style of an element. I used it mainly to keep out IE, which has its own proprietary method for this (did I mention my other gotcha lists?). I tested for (document.defaultView), figuring that a client wouldn't have this object in its beady brain if it couldn't use its methods. Opera somehow knows that document.defaultView is an object, got past my gate, and had brain failure. So I cobbled in another conditional and managed to keep Opera from hurting itself.

All in all, Opera is very good at rendering CSS and CSS2 the way you want it to. A couple minor points. It does a poor job of changing the appearance of form elements once they are on the page. And Opera has its own idea for the 'auto' size property value. The other browsers will 'cinch up' a positioned element that has its width set to 'auto,' so that it takes only as much room as it needs on the page. If you are not sure of the fonts or resolution of your visitors, it is handy to skip specifying the actual width of an element. Opera will use up all the horizontal space there is unless you give it a definite size. Not a page breaker, but annoying.

And this isn't a style issue, but Opera won't let you effect a change to the disabled attribute of an element from a script.

4. keyPress

Another surprise might come up on pages that use a keypress event. Opera has dozens of built-in keyboard shortcuts, and allows the user to define his own. This makes capturing a keypress on the window or document a very elaborate proposition. The W3C hasn't yet come up with a recommendation for keyboard event handling, so don't hold it against Opera. Except for keyboard events, the code that works in Mozilla/Netscape/Sea Monkey for event handling will also work in Opera.

5. display and scrollTo()

Another page crasher has to do with scrolling the window. Opera 7 tends to crash when I change a display property and then call scrollTo(x,y) in the same function. If I put the scrollTo in a separate function, after the display change, Opera is fine. Several other types of script commands have the same pattern - Opera 7 crashes when I remove a node in the same function that made use of it, or if I insertBefore an element and then change the display of the reference element. So I have some work to do on pages I want to make Opera friendly, by moving calls that affect the display into separate routines.

All the problems I've found so far are fixable or work-aroundable, without doing anything that breaks Mozilla or IE. I expect to find a few more gotchas, but I really do like the new Opera Browser. It is small, it is smart, it makes beautiful pages, and it is really, really fast.

And when it is good, it is very, very good.

# # # #

About the author: Kenneth Tibbetts never stops finding new ways to say "Hello World." He is the creator of the Yankee Web Shop at
http://www.yankeeweb.com/ and can be reached at:
yankee@yankeeweb.com .


2. OTHER VOICES:  The Gnome Knows
Interview: Joe Clark
GetContentSize

3. NET NEWS:  Online Shopping with Google's Froogle
Carbon Chip Breakthrough May Crush Silicon
Microsoft warns of Java flaws

That's it for this Thursday, see you next time.

Andrew King
Newsletter Editor, WebReference.com
aking at jupitermedia dot com



Created: December 12, 2002
Revised: December 12, 2002

URL: http://www.webreference.com/new/021212.html