Making an iPad HTML5 App & making it really fast

Jun 15, 2010 0 Comments
Tagged: , , , , and

thomasfuchsNow this is really good for us real web craftsman and women. Real knowledge of your field once again proves itself against frameworks. How much I loved the demos of jQtouch at last weeks @media ( or #wdx as it is called now ), I still think that using a library or a framework isn't the thing to do for speed. So Ipad and Iphone development will create a new demand for good old hand coders.

"Don’t rely on frameworks or what standards zealots tell you. In our case, a highly trimmed HTML page, with inline CSS, just some pure JavaScript without a framework and using the capabilities of the target platform (iPad) as much as possible allows for a lean page that loads almost instantly, caches well and works great offline. Yes, we could have used JavaScript and CSS frameworks, but sometimes less is more (and remember, you don’t need all the cross-browser heavy lifting that frameworks do for you)."

(Via Thomas Fuchs.)

Safari 5

Jun 08, 2010 1 Comment
Tagged: and

whatsnew_performance_thumb_20100607.jpgLot's of new (true) html5 features, like: offline storage and web workers... And fast

" It has innovative new features that improve the way you view the web. And powerful new tools to help developers enhance and customize the browsing experience altogether. Learn more"

(Apple - Safari - Browse the web in smarter, more powerful ways.)

input type=search

Feb 25, 2010 2 Comments
Tagged: , and

In this site I use several html5 elements and attributes. One of them is <input type="search" /> which gives me (for instance) a search button on my Iphone. It degrades to an text kinda input so it's backwards compatible.

What it also does is look kinda ugly in safari, with rounded corners and a frigging shadow and so on.

Default rendering in safari 4 os x
default rendering of search
Custom rendering
custom rendering of search

The way to render this is this one line of css:

input[type="search"]{
-webkit-appearance:textfield;
/* textfield instead of searchbox */
border: 1px solid #39c;
/* and a border of course but that's not relevant :) */
}

But for now that's it, on simple line in your css and apple no longers controls the style of your search field and you can style it (semi) consistent over browsers. A complete list of webkit specific styles can be found on Qooxdoo.org.

As I know, one disadvantage is that the search box does not longer appear as the default one in safari. But in my opinion the search box is not in usage as of now, so people are now more baffled by a strange box than they recognize the search box. In the future, however I think that this trick is no longer needed nor wanted.

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.