Archive for the ‘opera’ Category

Background on html

Monday, March 24th, 2008

There’s a paragraph in the CSS specification regarding the background property that states the following:

For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the ‘background’ property for the HTML element is different from ‘transparent’ then use it, else use the value of the ‘background’ property for the BODY element. If the resulting value is ‘transparent’, the rendering is undefined.

This might lead to a surprise when trying to add a background on top of what you have on the body element – when you add a background property to the HTML element everything will shift. You can observe this in most browsers on the links below.

Before:

html {}
body {background:#fcc;}

After:

html {background:#ccf;}
body {background:#fcc;}

It seems you really have to add a semantically meaningless element…

No more Navigator

Sunday, December 30th, 2007

Adactio is calling you an adversary, but I always thought of you as a friend. It’s been some time since we last met, I know work with your cousin and am flirting with a Norwegian girl that’s gotten a promising makeover. You’ll be remembered

Switching to Opera? Not just yet…

Monday, November 5th, 2007

After the latest update (2.0.0.9) and an update to the del.icio.us add-on I’ve become an expert in debugging Firefox. I really hate that.

I’m thinking about Opera more and more. I like a lot of things in the latest Opera (9.5 Alpha), but hate that I haven’t found all that I need in a browser. So I’m going to list it here (in hopes that somebody from Opera sees this list and does something about it):

  • Firebug
  • Web developer toolbar
  • HTML Tidy
  • Del.icio.us toolbar

The first three are obviously the result of me being a web developer. The last one is pretty obvious.

Use Array.join instead of concatenating strings?!?

Thursday, September 6th, 2007

I read this article at Usable Type and said to myself – true, true, true, true, WTF?

So I did a quick test:

  1. Concatenating 3 long strings: without ~135ms (45ms) [25ms] {33ms}, with ~220ms (120ms) [40ms] {65ms}
  2. Concatenating 12 shorter strings: without ~215ms (190ms) [85ms] {90ms}, with ~470ms (180ms) [105ms] {165ms}

The tests were done on my laptop on Windows Vista in Firefox (IE7) [Safari3] {Opera 9.2}, the function was repeated 10000 times. It seems that you’re better off without using array.join(), though it might be an option for huge joins in IE.

I wonder what sparked the idea – I’ve seen the use of arrays for string operations in Flash – string.split(old).join(new) for replacing until a proper method was available. I’ve never thought about abusing JavaScript that way…

On a side note – have you noticed that Firefox was significantly slower than others?

Update: I created a test page so you can test your browsers and post a comment

Firefox and Opera statistics are underrated

Wednesday, September 5th, 2007

While testing browser behavior regarding inline JavaScript evaluation and the back and forward buttons I found a very interesting thing. When a script is included in the HTML to execute on parsing (not on load but inline) Internet Explorer (7 on Vista tested) and Safari 3 for Windows will re-execute the script when a user returns via the back button. In my mind this is the correct behavior, since you actually visited the page twice.

The thing is that Firefox (2.0.0.6 on Vista tested) and Opera (9.20 on Vista tested) don’t agree with me. Well maybe they do and don’t live by their beliefs. What they do is nothing. You come back and no scripts are executed. Not even one request is sent to the server in Firefox.

This “feature” is sometimes a great thing – all the AJAXy stuff and all the JavaScript enhancements are already there and don’t need to be rendered again in turn saving power and time. At other times it’s a pain in the a** since some stuff does return to its default state and some doesn’t. This problem is most often observed with dynamic/advance forms that lose their default values/states. Since even onload is not fired this can get annoying…

Besides all the interface problems you might encounter due to this “rogue” behavior, there are also a few issues regarding statistics. It’s harder to inspect the path of a user, the time a user spent on a page, the number of page views in a visit and other related metrics. The other significant issue is that browser usage statistics might be skewed. To answer this last issue we’d have to know how these statistics are measured.

Let’s take a user that is used to clicking the back button while navigating a site with a 2 level deep navigational tree. She comes to the page, goes in one branch and then to a second, very distant branch. Internet Explorer would register 7 page views (1 on the root, 2 to get down, 2 back up and 2 more down), while Firefox would only register 5 page views (1 on the root, 2 to get down, ignore the 2 back buttons, 2 more down) – a 1.4:1 ratio.

If the statistics are based on sessions or unique users we have 50% IE and 50% FF. If we base them on hits we have 58% IE and 42% FF – a 16 percentage point difference or as we said before a 40% difference. This is not something you could just ignore…

Exercise for the reader – why do “unsupported” browsers always have a small browser share in hit based browser metrics?