Opera joins in Jobs v Flash argument

May 06, 2010 1 Comment
Tagged: , , and

opera logoSome interesting comments Opera's product analyst Phillip Grønvold on the future of flash. I think they are right, flash has it's place. But it's usage for video for example is an excellent example of what you should use HTML5 for nowadays.

"But flash as a video container makes very little sense for CPU, WiFi battery usage etcetera – you can cook an egg on [devices] once you start running Flash on them and there's a reason for that."

Don't get me wrong, flash is great for some stuff, but I even see it for building webforms ( with openLazlo ) and that is just plain stupid.

The best line I think was:

"But at Opera we say that the future of the web is open web standards and Flash is not an open web standards technology"

Opera joins in Jobs v Flash argument | News | TechRadar UK: ""

Opera mini on the iphone

Apr 13, 2010 0 Comments
Tagged: , and

After a long wait, it's finally being released into the app store. Opera mini brings many things to the iphone:.tabbed browsing on opera

  • tabbed browsing

    Keep several pages open at the same time and easily switch between them using tabs – just as you would on your desktop computer. On touchscreen devices, visual tabs even allow you to see a preview of the open pages you can select.

  • Integration with the desktop

    Save, edit and organize bookmarks into folders. Sophisticated bookmark management allows you to keep track of a large number of your favorite sites. Turning on Opera Link even allows you to keep your bookmarks synchronized across Opera on your other connected devices, like your computer, so you always have your links when you need them.

  • speed

    Opera Mini uses only a tenth of the bandwidth of other browsers, compressing Web pages by up to 90%. On Opera Mobile, turning on Opera Turbo compresses data up to 80% or leave Opera Turbo off to get full Web site data, as you would on a PC.

But the most important thing it brings to the iphone is choice. We can now choose to use either safari and webkit. This in turn will turn up the heat for on one hand the webkit developers, as Opera will be challenging them as they are doing on the desktop. On the other hand, it's a challenge for us lazy web developers who were developing for mobile safari alone. We now have a different browser to deal with.

So the real winners are the users, who now will encounter websites that are being made not only for mobile webkit, but for multiple browsers. Thus making sure the web moves forward...

If you want to see what opera is capable of, see it's Standards support chart. If you're wondering why the rendering is a tad different, look at this.

Light at the end of the tunnel

May 05, 2009 0 Comments
Tagged: , , , and

After years of domination, finally IE's share is starting to slide down to a respectable level. Web developers rejoice! Go and read for your self here:

Internet Explorer's progressive slide continues: Microsoft's browser is down to 66.10 percent from 73.01 percent a year ago. Half of that loss has been taken up by Firefox (up from 19.03 to 22.48 percent), with Safari also benefiting (up from 6.31 to 8.21 percent).

See the source

And as for mobile, it seems even better for us:

If the breakdown is restricted to mobile platforms, the shares are (to the nearest whole number) iPhone/iPod touch 65 percent, Android 9 percent, Java ME 8 percent, Symbian 7 percent, Windows Mobile 6 percent, BlackBerry 3 percent, others 2 percent.

See the source

But as a word of warning, this may look good. But in my opinion we still have to cater some content to IE6 users, as each user is as important as the others. It just mean that we will have to jump through less hoops, as hopefully customers will be using a better browser than IE6.

Console.log for IE

I write a lot of javascript in my present project. Doing this, I just love firebug and more to the point the console.log function that it lets me use. Bummer is only that it doesn't work in IE, the one browser that needs javascript debugging most. It also throws javascript error in IE when used. That is something that can be avoided by cleanly remove all of those console.log statements before you send stuff to be tested.

But, as everybody knows in the real world people tend to forget such things. So in annoyance with these errors, I set out to recreate the basis console.log function for IE as well. In retrospect it turns out that I set out to create a better mouse trap, but hey, it was fun and good enough to share, so lets...

In my solution and do not worry, I will share other solutions but first I will speak my mind. The console.log function is not used, instead you use logger(message). This sends the message to message to the console, if there is any, or it creates an ul (with an id of 'logger') in which it sets li's with the individual messages. So without further ado, I present to you the code:

 /*
* wilfred nas
*
* info@wnas.nl
* http://www.wnas.nl/
* http://snippets.wnas.nl/
*/

// to intitialize the logger set : var log = 'true';
// change to 'false' to remove logging statements from you app.
// or (better) remove all logger statements from your code.
var log = 'true';
//var log = 'false';
/*
* the logger functionality is a attempt to recreate some of the console functions of
* fire bug for IE, the browser where you need js debugging tools the most. *
* to use it you replace console.log(msg) with logger(msg), this sends the msg to the console or
* it creates an ul to receive your (LIst of) messages...
*/
/*
* works in safari 2, opera 9, camino, webkit, ie 6 and firefox 2 (with or without firebug).
*/
function logger (msg){
if (log == 'true'){
// first we need to do some browser sniffing, look below for the explanation.
var b = navigator.userAgent.toLowerCase();
safari = /webkit/.test(b);
/*
we only sniff what we need...
opera = /opera/.test(b);
msie = /msie/.test(b) && !/opera/.test(b);
mozilla = /mozilla/.test(b) && !/(compatible|webkit)/.test(b);
*/
// bummer, safari seems to think that it has a console, so we make sure that it goes through.
if (window.console && !safari){
console.log(msg);
}
else {
if(!document.getElementById('logger')){
var ul = document.createElement('ul');
ul.id = 'logger';
document.getElementsByTagName('body')[0].appendChild(ul);
}
var ul = document.getElementById('logger');
var li = document.createElement('li');
ul.insertBefore(li,ul.firstChild);
li.innerHTML = msg;
}
}
}

I think that it is a nice solution to a real problem, if you want see my solution here. If you want to try other people's solutions, go and seek googles advice. Something that I should have done before writing my own stuff, but at least it helps me understand javascript a bit better. Something that is always good I think.

My advice to you is, either use my solution (and if you do, please let me know, I will be proud) or go and use faux console by Christian Heilman's. I think his is better javascript, as is to be expected...

The downside is that he wrote it to be included as a seperate piece of javascript and it still needs to have all of the console.log statements removed for the live code. Where as in my logger, all you have to do is change var log == 'true' to false to go live. I think that this is a strong point, in my situation where I deliver stuff to be tested in two day cycles, as it goes faster.