Julia Sets with HTML Canvas

I’ve been reminding myself about Julia Sets recently, so I thought I’d build on using HTML Canvas. There are a bunch of Java applets out there but I’ve not seen one in canvas. Seems to work quickly and can be saved as an image; if you want you can change the canvas size or the c value in the function.


See the Pen vGzzpq by chrismichaelscott (@chrismichaelscott) on CodePen.

For accuracy: this is the Julia Set of the function f(zn+1) = zn2 + c, where c is -0.515 + 0.529i.

Factmint Charts WordPress plugin

We, at Factmint, have just released a WordPress plugin to create data visualizations in a WordPress blog. So, I thought I’s give it a go:

Top ten countries by GDP

source wikipedia

Country GDP
United States 16768100
China 9181204
Japan 4898532
Germany 3730261
France 2678455
United Kingdom 2267456
Brazil 2243854
Italy 2149485
Russia 2096774
India 2047811

The plugin is here, if people are interested.

Nice numbers part 2: scales

In part 1 I talked about a problem when developing scales built algorithmically. For example choosing numbers on an axis:

If you want five ticks on the side of bar chart, and the range is 0 – 8, you could do 0, 2, 4, 6, 8. But what about 0 – 5? That would be 0, 1.25, 2.5, 3.75, 5. How about if the chart is displayed on a small screen and you can only fit in 4 ticks, then 0 – 8 is 0, 2.666, 5.333, 8. Those are not nice numbers.

So, an axis (say on a column chart) for those values would look like this:

A poorly formed scale

In that post we developed an algorithm for rounding numbers to an aesthetically pleasing value. However, the value returned from that function was a string – a human readable representation of the number, such as “1.2 trillion”. In order to tackle the problem described above we will need to keep the number as a Number.

function getNiceNumber(uglyNumber, precision) {
    if (! precision) precision == 2;

    return parseFloat((uglyNumber).toPrecision(2));

function getDisplayNumber(niceNumber) {
    var order = Math.floor(Math.log10(niceNumber));

    var suffix = '';
    if (order >= 12) {
        niceNumber = niceNumber / Math.pow(10, 12);
        suffix = ' trillion';
    } else if (order >= 9) {
        niceNumber = niceNumber / Math.pow(10, 9);
        suffix = 'bn';
    } else if (order >= 6) {
        niceNumber = niceNumber / Math.pow(10, 6);
        suffix = 'm';
    } else if (order >= 3) {
        niceNumber = niceNumber / Math.pow(10, 3);
        suffix = 'k';
    } else if (order <= -3) {
        niceNumber = niceNumber / Math.pow(10, order);
        suffix = ' × 10' + order + '';       
    return niceNumber + suffix;

var uglyNumber = 0.000326343;
var niceNumber = getNiceNumber(uglyNumber);

As before, that logs:

3.3 × 10-4

Choosing an increment

Now, to return to the problem at hand. In our example, generating 4 tick marks on a scale from 0 – 8 doesn’t give good results. We can see that it won’t. 4 tick marks equates to 3 regions: look at the axis illustration, there are 3 regions between the 4 ticks; in general, for n ticks there are always n – 1 regions. Therefore the (bad) increment chosen in that example is 8 (the range) divided by 3, which is 2.66 recurring.

So, what would make a good increment? Well, a nice number would be a good start, probably. If we  decrease the precision to 1, the increment becomes 3:

function getNiceIncrement(start, end, numberOfTicks) {
    var range = end - start;
    var numberOfRegions = numberOfTicks - 1;

    return getNiceNumber(range / numberOfRegions);

var start = 0;
var end = 8;

var increment = getNiceIncrement(start, end, 4);


Which will log out “3”.

Now, for the example case we could say we are done. If we generate the tick marks by incrementing from the start we get:


Which quite nicely covers the area of interest and only uses nice numbers. As ever, it’s not that simple though. How about 0 to 4, with 4 ticks? Our nice increment is then 1 (4/3 rounded down); the scale would be:


It doesn’t cover the range, so is completely invalid. The obvious solution here (assuming you are not willing to use 5 ticks) is to always round numbers up. However that is not quite as trivial as it may appear: 1203.5 should round up to 2000, not 1204. As with the getDisplayNumber function, the solution lies in logarithms.

function getNiceIncrement(start, end, numberOfTicks) {
    var range = end - start;
    var numberOfRegions = numberOfTicks - 1;

    var uglyIncrement = range / numberOfRegions;

    var order = Math.floor(Math.log10(uglyIncrement));
    var divisor = Math.pow(10, order);

    return = Math.ceil(uglyIncrement / divisor) * divisor;

var start = 0;
var end = 4;

var increment = getNiceIncrement(start, end, 4);


This time, the generated increment is 2. That is better, we get 0,2,4,6.

By way of a quick explanation into the algorithm, rounding down the log-base-ten of the ugly increment gives us the number of digits before the decimal place minus one (i.e. the integer you would raise 10 to to get the largest possible number which is still less than the ugly increment), I will call this the order. Dividing the ugly increment by 10 raised to the power of the order always gives a number between 1 and 10; which we can round up, safely, then multiple by the order to return it to the correct size. By example:

  • start = 120010, end = 863209, numberOfTicks = 4
  • range = 743199
  • numberOfRegions = 3
  • uglyIncrement = 247733
  • order = 5 (as there are 6 digits or 105 = 100000 < 247733
  • divisor = 100000
  • uglyIncrement / divisor = 2.47733
  • Math.ceil(uglyIncrement / divisor) = 3
  • Math.ceil(uglyIncrement / divisor) * divisor = 300000

So, to recap, we now have a function that will generate nice increments and another that will generate display numbers (and getNiceNumber, although that is no longer used).

Centring the range

Consider the case where the scale runs from 11 to 15, with 4 ticks. The range is still 4, so the nice increment will be calculated as 2 and the scale will run:


That is okay, but the 17 seems superfluous as our original scale ended at the penultimate tick mark. We can account for this by moving the start tick backwards to centre the range. We should be a little cautious, though, in the case where the start of the range is zero. In the case of 0 – 4 our scale was 0,2,4,6 – would -1,1,3,5 have been better? Probably not: the negative number are an unnecessary complication. So, we might use:

function getNiceTickMarks(start, end, numberOfTicks) {
    var range = end - start;
    var numberOfRegions = numberOfTicks - 1;
    var niceIncrement = getNiceIncrement(range, numberOfRegions);

    var rangeOfTicks = niceIncrement * numberOfRegions;

    if (rangeOfTicks > range) {
        if (start >= 0 && start < niceIncrement) {
            start = 0;
        } else {
            start -= (rangeOfTicks - range) / 2;

    var tickMarks = [];

    var counter = start;
    while (tickMarks.length < numberOfTicks) {
        counter += niceIncrement;

    return tickMarks;

function getNiceIncrement(range, numberOfRegions) {
    var uglyIncrement = range / numberOfRegions;

    var order = Math.floor(Math.log10(uglyIncrement));
    var divisor = Math.pow(10, order);

    return Math.ceil(uglyIncrement / divisor) * divisor;

var start = 11;
var end = 15;

var tickMarks = getNiceTickMarks(start, end, 4);


That will return:


Perfect. And if we had 0 – 4 (or 0.5 – 4.5, etc) we would get:


That, for now at least, is all I have to say on nice numbers.

Nice numbers part 1

Rendering “nice numbers” has been the subject of a few debates at Factmint over the last few weeks, as we expand our collection of data visualizations, so I thought I’d put some thoughts down…

What’s a “nice number”?

Well, that’s a difficult question; 1729 is a nice number but I am specifically talking about aesthetically pleasing numbers. For example, the series 10, 20, 30 is more aesthetically pleasing than 9, 18, 27 – certainly, if you were using those numbers of the ticks on a bar chart’s axis.

If you want five ticks on the side of bar chart, and the range is 0 – 8, you could do 0, 2, 4, 6, 8. But what about 0 – 5? That would be 0, 1.25, 2.5, 3.75, 5. How about if the chart is displayed on a small screen and you can only fit in 4 ticks, then 0 – 8 is 0, 2.666, 5.333, 8. Those are not nice numbers.

When you look at very big and very small numbers the problem is similar. 1452519892 is not nice; 1500000000 is better; 1.5bn is better still.


So, JavaScript (as with many other languages) provides a simple solution to this problem: Number.prototype.toPrecision.

(1452519892).toPrecision(2); // "1.5e+9"

Doing better

Rounding to two significant figures is definitely an improvement but we can do a lot better, especially if you are not happy with standard form. First off, let’s parse a float so we can work with numbers again:

parseFloat((1452519892).toPrecision(2)); // 1500000000

Now, we need to know the power of 10 from the standard form bit. You could parse that from the "1.5e+9" but it’s easier to get as a log-base-10.

var number = parseFloat((1452519892).toPrecision(2)); // 1500000000
var order = Math.floor(Math.log10(number)); // 9

That is saying that the smallest power of 10 that is less than 1500000000 is 9.

Now we need some more fiddly code to deal with all of the cases. Let’s start with the big numbers:

function niceNumber(uglyNumber) {
    var niceNumber = parseFloat((uglyNumber).toPrecision(2));
    var order = Math.floor(Math.log10(niceNumber));

    var suffix = '';
    if (order >= 12) {
        niceNumber = niceNumber / Math.pow(10, 12);
        suffix = ' trillion';
    } else if (order >= 9) {
        niceNumber = niceNumber / Math.pow(10, 9);
        suffix = 'bn';
    } else if (order >= 6) {
        niceNumber = niceNumber / Math.pow(10, 6);
        suffix = 'm';
    } else if (order >= 3) {
        niceNumber = niceNumber / Math.pow(10, 3);
        suffix = 'k';
    return niceNumber + suffix;

niceNumber(1452519892); // "1.5bn"

That’s pretty cool and does what we want – now for the little ones…

There are a few ways you can deal with very small numbers. One option, is to switch back to standard form but to display it a little more elegantly. This example uses HTML in the output (which may not be an option for all cases) but you could use the “e” syntax or even a standard fraction.

function niceNumber(uglyNumber) {
    var niceNumber = parseFloat((uglyNumber).toPrecision(2));
    var order = Math.floor(Math.log10(niceNumber));

    var suffix = '';
    if (order >= 12) {
        niceNumber = niceNumber / Math.pow(10, 12);
        suffix = ' trillion';
    } else if (order >= 9) {
        niceNumber = niceNumber / Math.pow(10, 9);
        suffix = 'bn';
    } else if (order >= 6) {
        niceNumber = niceNumber / Math.pow(10, 6);
        suffix = 'm';
    } else if (order >= 3) {
        niceNumber = niceNumber / Math.pow(10, 3);
        suffix = 'k';
    } else if (order <= -3) {
        niceNumber = niceNumber / Math.pow(10, order);
        suffix = ' × 10<sup>' + order + '<\sup>';       
    return niceNumber + suffix;


That returns:

3.3 × 10-4


So, that sorts out rendering single values nicely but doesn’t fix the problems, outlined at the beginning of this post, when dealing with picking numbers in a range. Out issue of the picking 4 numbers from 0 – 8 would still be there, just to two decimal places. We have sorted that out in our visualizations and I’ll write about choosing sensible numbers in another post soon.

Shadow DOM: encapsulation for semantic markup

There was a post on CSS-Tricks recently about SVG icons vs font icons. One of the criteria for judgement was semantics (is an or tag better than a inline symbols or :before pseudo class?) Another post on the same site discussed events and targets with inline SVG.

For me, both the issue of semantics and difficulties of handling complex DOM (i.e. the event target problem) are part of the broader topic of encapsulation. That is, you (probably) don’t really want to use SVG to create a button, you just want a button that looks like a filing cabinet icon. Let me expand upon that:

If you want a button that allows the user to select a file the obvious starting point would be a form input:

file type input

file type input, rendered in Chrome

This has a number of merits:

  • It’s simple
  • It’s semantically very accurate, as it allows input of type file
  • The browser does the hard work

The last point is particularly important; as is, with no JavaScript, the browser will render a button, when a user clicks the button a file-system explorer will open and when an enclosing form is posted the reference to the file will be set correctly.

So, now you decide you want to use an icon (this one http://iconmonstr.com/archive-7-icon/) instead of the boring “Choose file” button. How might one go about that? Well, it’s not as simple as adding an image inside the input tag: inputs are void elements so cannot have children. You could just use an img tag and maybe give it a sensible class:

That would look fine but you would definitely have less semantic code and you would need to implement all of the file input functionality yourself (or hack it).

There is a better solution (at least there will be when support improves): Shadow DOM. Shadow DOM, for those who don’t know, allows encapsulation through “functional boundaries in a document tree”. What does that mean? Well, in our example, it would allow us to encapsulate the DOM tree for the nice looking SVG icon (and other stuff if we wanted) as a kind of widget which we can inject into our page under another element – in this case an input – without changing the functionality or semantics of that element.

Consider this simple case:

var button = document.querySelector('input[type="file"]');
var shadowDom = button.webkitCreateShadowRoot();
shadowDom.innerHTML = "<div>Hello from the other side</div>";

See the Pen gHEei by chrismichaelscott (@chrismichaelscott) on CodePen.

It might, upon first glance, appear to be a long winded way of changing some HTML but that isn’t what has happened. If you were to inspect element the input would still be an input, no sign of a div at all. More importantly, if you click on the message a file-system explorer dialogue opens; if you post a form the attachment is set. So what happened, then?

The shadowDom variable in the JavaScript is the point of separation, the “functional boundary”. From the outside, you still have an input, you’ve not changed that at all. However, because we set the inner HTML of the shadow root the browser knows that there is more underneath, and renders that content.

Let’s go back to the icon we want to use for our file input. We can now use the shadow DOM to make a file input render like an image:

var button = document.querySelector('input[type="file"]');
var shadowDom = button.webkitCreateShadowRoot();
shadowDom.innerHTML = "<img src="https://s3-eu-west-1.amazonaws.com/chrisscott/codepen/iconmonstr-archive-7-icon.svg" alt="Select file"></img>";

See the Pen jiqoh by chrismichaelscott (@chrismichaelscott) on CodePen.

Pretty cool, but we can make this much nicer to look at – both from a user’s perspective and the code. Remember that Shadow DOM is a form of encapsulation: so CSS defined for the document cannot affect the encapsulated tree (this is one of the main reasons for Shadow DOM but a different discussion). So how can one style the Shadow DOM? HTML5 allows us to define template elements. These elements are not rendered but the parts of the DOM tree under them can be used as templates. If we define a template we can include a style tag within it. Then, the entire content of the template can be used to define the Shadow DOM. Also, for cleanliness, the template can be defined in the head and kept out of the way:

var buttons = document.querySelectorAll('input[type="file"]');
var fileButtonTemplate = document.getElementById("file-button-template");
for (var x = 0; x < buttons.length; x++) {
  var shadowRoot = buttons[x].webkitCreateShadowRoot();

See the Pen jghes by chrismichaelscott (@chrismichaelscott) on CodePen.

So that’s it! A nice looking scalable vector icon which has all of the functionality of a native file input, is completely semantic and doesn’t feature transparent inputs absolutely positioned over styled content.

Graceful Degradation

Fortunately, Shadow DOM (used in this way, at least) degrades really nicely. The JavaScript could be improved to catch exceptions but functionally this should play well with older (not bleeding edge) browsers. That is, if the browser doesn’t support element.createShadowRoot() then nothing happens, the old file input is left as is. In fact, this is arguably better than using an SVG icon straight up as SVG isn’t supported by older browsers (IE 8 and backwards) and an SVG tag will not degrade nicely.

3D Rendering to SVG

I was on holiday last week, in the Sierra Nevada mountains in Andalusia, Spain. Some people like to read books on holiday, I undertake projects. So, as I was sitting by the pool, I developed a 3D rendering engine in Javascript. Each to their own, hey?

I’d been thinking about this for a little while. A rendering engine was an enticing project and I anticipated some interesting complexities. I had decided that I would use SVG as the medium. As with 2D drawings, HTML5 Canvas seems to get all the attention for 3D drawings (WebGL) but, in both cases, there are pros and cons of each technology. Notable reasons for choosing SVG may be:

  • As SVG is vector based it will be very fast for simple drawings that are animated (as, from a Javascript point of view, you only need move points, not redraw the canvas)
  • If you need to interact with the components, SVG elements natively support mouse events (like mouseover)

So, first off, here’s the result. I’ll explain how it works afterwards.

Use cases

As mentioned above, there are a number of good reasons to use a vector drawing. A use case which immediately springs to mind is architectural drawings. The drawings need not be vastly complex, certainly in terms of fairly regular shapes and textures. Also, a developer could add interactive elements to an application so that hovering over a wall or joist would show you the materials, etc. That would be much more difficult with WebGL or similar as the hover events aren’t there to help.

How it works

The maths behind the engine is fairly simple but quite fun. First, a camera is created, which consists of a point in space and a rectangular plane at some point in front of it. The plane is, in effect, the lens of the camera and I refer to the point as the origin. Then, to plot a point the following algorithm is ran:

  1. A vector is constructed from the point being plotted to the camera’s origin
  2. The point that the vector intercepts the lens is calculated
  3. The intercept point is converted into a 2D co-ordinate, relative to the lens
  4. That co-ordinate is scaled up to the screen and a point is plotted there

So, to draw a plane one merely needs to convert four points in space to be four co-ordinates on screen, then an SVG path can be used to join the dots.

A bit more detail

The interesting part of this project is projecting the point to be plotted onto the lens. I had an idea of how this would work: I wanted to exploit the fact that the dot-product of two vectors at a right angle is always 0. Moreover, a decrease in the dot product implies that the angle is closer to a right angle.

So, take any two points on the lens, La and Lb, which could be corners and a second vector, v, from the camera origin to the point being plotted; then, there exists some λ which minimizes α:


Pictorially, that is:

Therefore, λ minimizes α as λ v approaches the intersect between v and the lens plane. To find the value of λ I simply implemented a “split the difference” algorithm. That is, try λ equal to 0.5; is that better than λ equal to 1? Then try 0.25 and 0.75, which is best? Ect, ect.

Once you have the vector λ v it is quite easy to map the point onto the screen using a bit of trig’ and some vector maths. Then you’re there. If you want more details, best check out the code on my Github page.

The future of the project

This was never meant to be a production library, just a proof of concept. I think that a robust SVG-based rendering engine could have a number of sound use cases but it would take a lot more time than I have available to get to the point where this could be used in production. A number of challenges, just off the top of my head, include:

  • textures – difficult to transform in 3D if you’re using SVG
  • lighting – this could be implemented using dot products between the normal of the plane and a vector from the plane’s centre to a point of light
  • z-index of polygons – i.e. if the example above were opaque, the closest planes should be visible above the farthest ones.

I’d love to know what other people think and if there is any work in this direction already…

Filter Effects for Raphael

I’ve been working lately on an extension to Raphael.js which lets you quickly add Filter Effects – something which I’ve wanted to see in Raphael for a long time. I’m not going to do a big write up just yet but here’s an example of what’s on offer:

You can find out about the project on it’s homepage.

Understanding the prototype property in a Javascript object

The prototypal nature of Javascript is both a common cause of confusion and a well documented topic. I’m not going to look at the basic theory here because it’s been done many times; if you are interested in the basics there is a very good document on MDN. Instead, I would like to outline a few simple experiments which illustrate the properties of a prototype chain and why you might want to take advantage of them.

For the basis of this post, I’m going to use the Constructor pattern and look at the following simple example:

If you were to look at the football object in your browser’s debugger you would see that it has a property called prototype which is a reference to its prototype chain. The chain would go:

Sphere → Object → null

Now, that code can be rewritten using the prototype property of Sphere, like so:

As you can see, the result is the same. But, if one were to compare the two version of the football object they would see a difference. In the first incarnation “pi” and the “volume” function are both own properties of football; in the second version those two properties are no longer part of football but instead are properties of its prototype, Sphere.

You can prove that by changing the value of “pi” in the prototype:

So, without changing football at all, its reference to “pi” has updated. As “pi” was not an own property the prototype chain was consulted and value found in Sphere. That has a very important implication: for any instances of Sphere there is only one object which is the prototype. That is, if we created a second Sphere, called tennisBall, it would not just have the same properties in its prototype as football, it would have a reference to exactly the same object as its prototype. So if “pi” is updated in the prototype it is updated for every instance of Sphere.

That can be a useful property in of itself but it has huge implications for application performance. Suppose we create a large number of Spheres. In the original example (without using the prototype property) there would be a property “pi” and a function “volume” created once for each instance of Sphere; when those properties are part of the prototype they will only be created once. So for a million Spheres there would either be 3 million properties (a radius, pi and volume for each) or 1 million and 2 properties (a radius for each and a pi and volume in the prototype). That makes a huge difference to performance:

Using properties of the prototype:

Using own properties:

On my laptop, the version with the properties stored in the prototype ran in 0.563 seconds, verses 1.349 without. That’s more than three times the speed!

So, it’s not just about coding style: the prototype property is very important, particularly when your code creates many instances, and needs to be understood. If a property is likely to be unique to the instance then it should be ab own property, otherwise it’s often worth moving it into the prototype.

Force distribution bubble chart

For my company, FactMint, a big part of our software is building data visualizations automatically. One of the staple diagram types for visualization designers has always been bubble charts. They always seamed a little complex to build programatically, however, with one needing to to account for a non-overlapping, evenly distributed layout.

Anyway, I finally took the plunge and build a proof of concept in JSFiddle. I think it’s rather neat, so I thought I’d share it:

Rationale for developing the Iugo one-way binding library

Recently I built a new Javascript library for binding objects to the DOM. It’s called Iugo and you can find it here: http://iugojs.com. Now, clearly, there are other binding libraries out there, so I wanted to produce a quick post to summarize my thought process going into this project…

I first started to think about this kind of project around two years ago when I first started using Angular.js. If you are not familiar with Angular , it’s a Javascript framework which includes two-way data binding (i.e. objects are bound to the DOM and changes to those values in the DOM are bound back to the object) and a bunch of other features. It’s a great framework and my initial reaction was very positive; I quickly became a fan.

After getting a little deeper into a fairly complicated Web application, however, I frequently found myself frustrated with the framework’s complexity. In order to understand why I believe there is a place for a new data binding library I need to give a quick review of Angular:

Things I like in Angular

Two way data binding

For me, the data binding feature is the core of Angular (I expect its developers would agree). Without data binding developers often use Javascript to inject HTML segments into a document. There are numerous problems with this approach. In the same way that decoupling style and content is a good idea, decoupling markup and data should be considered a very high priority best practice.

Imaging a designer who is employed to improve the UI of your app is looking at a div elements in their browser’s inspector and they really want to change them to be an unordered list (ul/li elements). The designer also notices inline CSS is applied when a user clicks on one of the divs and they want to change that into a semantic class. The designer looks in the HTML but there that section is just missing. The actual HTML for the divs is injected in a loop in a Javascript file and the click handler which adds the inline CSS is somewhere else in the file. Would you want a designer who doesn’t know the code to make those kind of changes? Would they even find where to make them? The whole situation is a mess.

Using templating or other data binding techniques makes your code much more accessible. Designers work on HTML and CSS and can see everything. Logic can  deal purely with data and just update the model behind the UI.

That said, two way binding is an interesting thing. In one direction data binding is an easy thing to achieve. If a user updated an HTML form input it is easy for a piece of Javascript to update a model – it can just listen for the change event to be fired from the input. The difficult part is binding the model to the HTML – there is no event that fires when an object is changed. That became the functional core of Iugo – it’s a library which fires events when objects are changed.

Things I dislike about Angular


The idea behind Angular scopes sounded fairly simple when I first read about them – basically a scope is a model and it is bound to a part of the DOM. In simple Angular applications there is often only one scope, bound to the whole HTML document. When my application became more complex than that I continually found myself confused and wasting hours debugging my code to work out how to get two scopes to interact. Sure, you should design your scopes to be independent (that’s what a scope is!) but  a couple of times I realized further down the development process that I had some unforeseen need to access two scopes; at that point my options were to redesign my application from a fairly fundamental standpoint or to deal with mounting difficulties and hacks used to get around the scope system.

One mandatory feature for Iugo was the ability to access namespaced models at any point in the DOM. Not to mension a lighter touch so objects don’t need to be treated in a special way if you are using them as a model.

Being a framework

If you need a framework then check out Angular. If you have a requirement for data binding and templating then you may want to consider your options (including Iugo). Angular includes ajax helpers, scenario testing, localization, URL management, dependency injection, event listeners, test helpers (such as angular.isArray()) and a host of other features. Those features may well be useful to you but they add up to 80k minimized – about the same as jQuery; if you already use a framework like jQuery do you really want duplicate HTTP helpers, &c? Personally, I prefer smaller, modular, libraries. Iugo is 5.8k minified, less than a tenth of the size.

Not being HTML5 complient.

For the record, I think Angular may have fixed this with some kind of compatibility mode but their website is littered with examples of non-compliant code. Take the example on the homepage. They use the “html” doctype but have an attribute called “ng-app” in the document’s html tag. That’s not allowed; try it in the W3C’s validator.

Introducing Iugo

So, this those points in mind, I set about creating a simple data binding library. Iugo is:

  • Small, less than 2k minified and gzipped
  • light touch – it will complement other frameworks like jQuery
  • standards compliant, no namespaces or invalid attributes
  • modular, as it is based upon an event system for objects

I’d love any feedback anyone has, so please check out the site.

About me

Contrary to the massive "Chris Scott" at the top of the page, I'm not a (complete) ego-maniac. I just liked the font and couldn't think of anything more interesting to say.

I'm a passionate developer and entrepreneur. My company Factmint provides an elastic RDF triplestore and a suite of Data Visualization tools, so I largely talk about those things.

Fork me on GitHub

GitHub Octocat

chrismichaelscott @ GitHub

  • Status updating...