See the comments on this issue. If IE 8 support is needed, we could add a separate branch (or fork) for supporting it (and maybe other old IE versions), that might be updated each release.

An alternative approach would be to just support it in the main version. This could add bloat for those who don't need this, though.

Any way we do this, we should have a clear message - either say that it is not supported or support it somehow.

P.S. I personally don't need this. It probably will fall behind of the main version unless someone requires this and maintains it.

A first version of this module is in master already. However this module should automaticly prefix css attributes that haven't made it into the standard yet. Additionally it's importent to test that cases like

css(node, { "min-height": "20px" });

and

css(node, { "minHeight": "20px" });

and

css(node, { minHeight: 20 });

are treated equally with the same results.

Creates a new DocumentFragment from the specified nodes. Probably should be used to speed up append, prepend, etc.

function fragment(...children)

fragment(document.createElement("test"));
fragment([node1, node2]);

Also, it might be nice to allow nested arrays, that way utilities like append could use it like fragment([].slice.call(arguments, 1)) and still allow arrays to be provided to them.

I would suggest placing source files in the source folder and tests directly in the tests folder. Then put all other files needed for testing (mout, requirejs, test config, etc.) in the lib (or libs) directory.

Currently mout is in the libs directory, even though it is only needed for testing. The other testing libs are in the tests/lib directory.

We should have a standard place for the documentation. Maybe copy mout's method? We could add grunt tasks for this.

One of the easiest ways would be to have a documentation folder that is a Jekyll site and just mirror that to the gh-pages branch. The downside to that is that contributors have to install ruby and jekyll to preview the docs.

Append one or more nodes into a parent node

append(parent, node);

Module for ajax requests. I imagine the API much like jQuery's API.

ajax({
    type: "get",
    data: { foo: "bar" },
    dataType: "json",
    success: function(result) { },
    error: function(result) { }
});

Full list of optional parameters is to be discussed.

Any input for handling event listeners

So far @conradz suggested

listen( nodes, event, callback )
removeListener( nodes, event )

Right?

This would be really convinient as DocumentFragements do not support .innerHTML.

Adds one or more nodes at the beginning of a parent's children.

prepend(parent, nodes);

Remove one or more nodes from the DOM

remove(nodes);

What browsers should be supported? This should probably be written in the readme file also. I would suggest IE9+ and the last two/three versions of Firefox/Chrome, but that's just my suggestion. Not sure about Safari, Opera, and Android.

Right now the tests are failing on IE10.

Hey,

I've been working on another project and haven't had a lot of time for CANE, unfortunately.

A module that could have come in really handy would be something like the jQuery's data module which let's you safe an object on a node.

So setting would be something like data( node, { "data": "foo" } ); and retrieving would be data( node );.

Haven't thought a lot about that so for. What do you think. Different modules for setting and getting?

I would like to some up and discuss the style guide here before we start writing more code.
As you can see I'm a big fan of white space and tabs. I'm open for any style I just want it determined before hand.

So what are the opinions on:

• tabs
• spaces padding objects, params, etc.

@millermedeiros @conradz

This is a shortcut for net/ajax as mentioned #12

Used to create DOM nodes and set attributes easily.

function create(tagName, [attributes], [...contents])

create("div"); // <div> tag
create("div", { "class": "test" }) // <div class="test">
create("div", { "class": "test" }, "test content") // <div class="test">test content</div>
create("div", "test content") // <div>test content</div>
create("div", create("span")) // <div><span></span></div>
create("div", { "class": "test" }, create("span", "test"), create("i", "again")) // <div class="test"><span>test</span><i>again</i></div>

I think it should also treat the contents as text, not HTML, if it is a string to prevent HTML injection.

I was thinking what if allNodes also checks weather or not the nodes argument is a string and if so it uses it in a document.querySelectorAll query and loops over the results.

It would allow you to do things such as:

listen( "a.buy", "click", onClick );
css( ".tile", "width", "1000px" );

What do you think, @conradz?

getJSON should send the exception itself in the error callback. So if for instance you have a valid JSON, pass it through the success callback and many functions later within the same call stack your code causes an exception completely unrelated to this, it will be caught in getJSON and you get the error callback but with a valid JSON data and wonder what the error is all about since it called success already.

so the error callback shoud have this signature:

error( exception, data, status )

so the whole process looks like this

try {
    success.call(this, JSON.parse(data));
} catch (exception) {
    error.call(this, exception, data, status);
}

This issue is a reminder to implement that.

Generally all error callbacks should probably have the error as first argument.

Sets textContent for all the nodes.

function setText(nodes, text);

setText(document.querySelectorAll(".my-label"), "Label Text");
setText(node, "test");
setText([node1, node2], "test");

Is this useful enough to justify another module? It could be useful to set it on more than one node at a time, just not sure how often I would use it.

Hey guys, on my personal lib I have two modules that I use to load and inject CSS or JS files. They're already on AMD. I'm wondering if this library can be a place to them and if you guys have interest in having such functionalities.

Cheers!