Category Archives: Html5

JSLint-Feature – Error Severity

Hi Douglas,
I have been to a good number of your talks, and I love the idea behind JSLint. I even don’t mind it when JSLint makes me cry every now and then, however, I feel like the priority of JSLint should be around launch successful code early and often.

Here at Kabam we build games that run as HMTL5 apps, and recently we have started to use JSLint as part of our build process. In a few cases it has caught some minor errors and we were later able to resolve them.

Our build process uses Jenkins, which is an open source version of Hanson. These continuous build automation tools make use of another wrapper library you might be familiar with. http://code.google.com/p/jslint4java/

So in this sense let’s say a develop wants to add a new piece of code, and this code causes a problem.

JSLint reacts in the following ways,
– it has a an error limit and stops reporting erros after a certain amount
– errors are not prioritized based on ‘newness’ – because that would be hard
– errors are not prioritized based on priority.

The end result is that a team must fix all errors to get the maximum value out of JSLint.

I propose a 2 part solution.
1. JSLint should not set error priority, unless it sets sensible defaults
2. JSLint should report an error code so that a wrapper like jslint4java could use a config file set an error priority.

This would allow teams to triage error types as part of their build/ development process.

On line 1326 you have a function warn() defined I propose it’s written something like so, including a new warning property, defining an error.type property using the bundle[] accessor name as the error code.

If you think of some other change that could get to the spirit of what I am looking for that would be great too. If I get the time I might try to implement a prototype. Hudson and Jenkins have 3 levels of errors, High, Medium, and Low.

Would you have some suggestions as to what would make good defaults for each of the error.types?

I feel like this change would better support agile development and continuous integration, and would allow teams to prioritize their development efforts.

Thank you for being a beacon and leader in the community.

function warn(message, offender, a, b, c, d) {

        var character, line, warning;

        offender  = offender || next_token;  // `~
        line      = offender.line || 0;
        character = offender.from || 0;

        warning = {
            id: '(error)',
            raw: bundle[message] || message,
            type: message,
            evidence: lines[line - 1] || '',
            line: line,
            character: character,
            a: a || (offender.id === '(number)'
                ? String(offender.number)
                : offender.string),
            b: b,
            c: c,
            d: d
        };

        warning.reason = warning.raw.supplant(warning);

        JSLINT.errors.push(warning);

        if (option.passfail) {
            quit(bundle.stopping, line, character);
        }

        warnings += 1;

        if (warnings >= option.maxerr) {
            quit(bundle.too_many, line, character);
        }

        return warning;
    }

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();
       }
       

Range and Replace

I would like to introduce you to the “Range” object in your browser. document.createRange() allows you to select a range of text ( even between elements, and it very well might be the basis for how the mouse is able to select text in a browser, or how chrome and firefox highlight search terms in the browser window.

Even though Range(s) seem to be used for visual elements, you can use them for less visual manipulation of the text in the page. I have also noticed that by using the range object, you can manipulate these objects much faster than you would otherwise through some other functions like ELEMENT.innerHTML() for instance.

I am still hacking on the RANGE object, but for now it’s promising. Later I will provide an update for a few tricks to use the RANGE object as I have had a few problems with the documentation. Firefox, and Chrome ( WebKit ) seem to work a bit differently, but for the most part are the same. Fortunately I am working on browser plugins at the moment so, I don’t have to worry about IE’s limited access to the object.

Here are a few links if you want to get started hacking on the RANGE object.

Re-thinking CSS, Can Javascript replace CSS or Simplify it?

Today Javascript is everywhere.  When the web was born you might have a browser that could support it, but so many browsers do, that it’s almost as common as HTML.  I think it’s been nearly a decade since I have developed a page without any javascript on it.  We use Javascript for core site menues, for google analytics for so much on the site, that if your browser didn’t support Javascript well you might as well not even browse the web.  Even our phones support Javascript, and if that is not enough, 500 million people a month use sites like Facebook that use Javascript to load content dynamicaly like a desktop application.

So now that we have established that Javascript is everywhere you want to be, and just about everyone has it enabled, you probably can say that it’s at least as common as CSS.

One of the core problems with CSS is how static it is, and how hard it is to get consistaint results between browsers, where as with Javascript all browser support the core of Javascript extremely consitaintly.  Infact the largest difference between browsers is found in the DOM ( Document Object Model ) for which CSS must conform to.  However with Javascript frameworks have been built to extend Javascript just enough to even create consitiansy at the Document Object Model.

To this point, it might make sense to actually describe page layout via a proper Javascript framework that can describe page layout consistiantly across browsers.  If this could be accomplished, then, we as web designers might finally be free from multi browser design.  I now for my self that designing for IE5, or IE6 can eat 80% of your dev time.  What cool sites could you design if you were 2-5x more productive?

Now, I am not saying that CSS will go away, but I am saying that for a number of design choices, Javascript might be the tool of choice, as it’s functionality could grow with the framework rather than at the rate of consistian browser implementation.

Consider implementing rounded corners via javascript, in FF, Opera, and Chrome you could use a CSS property, however in IE, you could programaticly solve the problem.  Consider box model consitiancy between the browsers, the framework could addapt quickly.

What about getting more lateral?  CSS can do alot, but what if you wanted to present data in a parrallaxed plane? http://webdev.stephband.info/parallax.html These UX standards can be brought in easily with Javascript, and not CSS.

Maybe I am stating the obvious, but

Javascript is the new default design language on the web.

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. 😉