Skip to content
Browse files

Updating Slick to 1.1.5

  • Loading branch information...
1 parent 37e200e commit 215c2fa02bb6e23fa7d41b18438e2fea01247be4 @cpojer cpojer committed Feb 23, 2011
Showing with 2 additions and 2 deletions.
  1. +2 −2 Source/Slick/Slick.Finder.js
View
4 Source/Slick/Slick.Finder.js
@@ -162,7 +162,7 @@ local.setDocument = function(document){
// native matchesSelector function
- features.nativeMatchesSelector = root.matchesSelector || root.mozMatchesSelector || root.webkitMatchesSelector;
+ features.nativeMatchesSelector = root.matchesSelector || /*root.msMatchesSelector ||*/ root.mozMatchesSelector || root.webkitMatchesSelector;
if (features.nativeMatchesSelector) try {
// if matchesSelector trows errors on incorrect sintaxes we can use it
@asuth
asuth added a note Feb 24, 2011

Typos: throws and syntaxes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
features.nativeMatchesSelector.call(root, ':slick');
@@ -878,7 +878,7 @@ local.attributeGetters = {
var Slick = local.Slick = (this.Slick || {});
-Slick.version = '1.1.4';
+Slick.version = '1.1.5';
// Slick finder

7 comments on commit 215c2fa

@ibolmo
MooTools member
ibolmo commented on 215c2fa Feb 24, 2011

By the way, why are you modifying Slick directly? Why isn't this a submodule?

@cpojer
MooTools member
cpojer commented on 215c2fa Feb 24, 2011

we only use the Slick code, we don't use the repository. Slick in Core is a copy, not the real thing :D

@fabiomcosta
MooTools member

It's exactly the real/same code, the problem is the structure of the folders...

@ibolmo
MooTools member
ibolmo commented on 215c2fa Feb 24, 2011

Not really a problem. Put Slick in the same level as Packager and Specs. Then update package.yml done, no?

@fabiomcosta
MooTools member

It's more like "all our source files are on our source folder", i think.
I think we should discuss this on IRC.

@Inviz
Inviz commented on 215c2fa Feb 25, 2011

I had to request a feature for my packager to handle this specific issue of bundling 3d party. Even though I can handle it with a packager (i can explicitly state standalone Slick to replace bundled Slick), unbundling it is a better way for everyone.

@ibolmo
MooTools member
ibolmo commented on 215c2fa Feb 25, 2011

Yep.

My solution is to register Slick at my own fork in a separate folder. My projects no longer have js dependencies just that Packager is configured correctly. Kind of like gems and pypy. At deployment, I have a script that compiles a frontend.js which has only the dependencies necessary for the projecto run.

The problem with this is that if a different project depends on a different build of a dependency.. so it gets hairy. One improvement is to have a .packager file inside the repo that packager then looks for. I also don't know if packager is looking for version numbers or branches. That would be best.

Please sign in to comment.
Something went wrong with that request. Please try again.