Tag Archives: Html5

Vid.ly Beta IE size bug work around

        var n = document.getElementById('vidly-wrapper');
        if( n != null && vidjs.prototype.isIe() ){
            vidjs.prototype.flashMarkup =
                        '<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="{width}" height="{height}">' +
                        '<param name="movie" value="http://vidly.dev.jentek.net/templates/js/player.swf"/>' +
                        '<param name="FlashVars" value="src={file}&skin=http://vidly.dev.jentek.net/skin.xml&scaleMode=none"><param name="AllowFullscreen" value="true"/>' +
                        '<param name="allowscriptaccess" value="always"></param>'+
                            '</object>';
           vidjs.prototype.flashMarkup = vidjs.prototype.flashMarkup.replace("{width}", '610');
           vidjs.prototype.flashMarkup = vidjs.prototype.flashMarkup.replace("{height}", '360');
       
           n.parentNode.removeChild(n);
           new vidjs();
       }
       

HTML5 Storage, localStorage, WebDatabase, indexedDB.

For Babelfin, a browser plugin, I have been looking for ways to elegantly store data in the browser for each of the translations of a given word or short phrase.  The goal would be to use a data pattern that was easily portable to the two most popular extensible browsers – Chrome and Firefox.  I decided to start with Chrome durring startup weekend because it has a newer extension model and has simplified a lot of how extentions work.  Firefox still uses xul which is an odd combination of XML and Javascript, where as Chrome uses native HTML and Javascript with a few additional libraries to work with.

So for Babelfin, the goal would be to list a set of phrases that one would want to learn, or that the user might enter, and then the plugin would pre-fetch the translation and store it in the language that the user wants to learn.  If the phrase list is short, using a key-value store like localStorage would make sense, as almost every browser supports it, including IE8, and even though there are small differences, the data model and pattern would still work. However for anything other than the minimal product, a larger data set will be required for more advanced users.  And as a result it would be nice to have a query-able data set.

Twice google has tried to solve this problem, once with Google Gears, and again with Web SQL Database, which works in Chrome, Opera, and Safari, but does not work in Firefox, or IE.  Microsoft and Mozilla do not want to add SQL as a language to browser side logic, and I happen to agree.

The result is IndexedDB, a javascript data storage model in the front end, however,  IndexedDB is not quite CouchDB or MongoDB, but rather a javascript level abstraction of storage data.  Several Mozilla folks seem to think that CouchDB might be built on top of it, and so there is BrowserCouch which will try to do just that.  But, where is the BrowserMongo ( Maybe we can call it Mango, as a Norwegian, told me that Mongo means retard in Norwegian, oops. )

So in any case there is still a gap for Browser Side Storage that is query-able and indexed.  I suppose something could be built on top of localStorage, but it would be a hack until the browsers fully support it.

I am trying to find out how much work it would be to put a stub wrapper on top of Webkit’s Web SQL Database layer and have it look like IndexedDB since that seems to be what Google will support eventually, once they figure out how to thread it, but it would be nice to have something now. 😉