Change repo name to on-media-query

[JoshBarr]

Any objections? :)

[patocallaghan]

Go for it..no objections here...

[patocallaghan]

I just noticed that Github doesn't perform redirects when you rename the repo so now everything that was linking to js-media-queries is 404ing ....Seems a shame to lose all that link juice you have going on.

Maybe setup something like this? Create a new on-media-query repo and have a redirect message on js-media-queries....The problem I see with this approach though is that you'll lose commit history, forks, followers on the new repo..

[JoshBarr]

That's annoying! I moved it back.

Josh

On 25/10/2012, at 9:29 PM, patocallaghan notifications@github.com wrote:

I just noticed that Github doesn't perform redirects when you rename the repo so now everything that was linking to js-media-queries is 404ing ....Seems a shame to lose all that link juice you have going on.

Maybe setup something like this? Create a new on-media-query repo and have a redirect message on js-media-queries....The problem I see with this approach though is that you'll lose commit history, forks, followers on the new repo..

— Reply to this email directly or view it on GitHub.

[mhulse]

Similar to what Pat says, check out this.

They have a message in the sidebar that says to "check a different repo".

Personally, I think it's a cool idea to change the name...

TBH, that's why I changed the object name to oMQ, because I thought it fit the name of the project better (onMediaQuery).

Part of me wonders, if you do decide to change the name, would it be wise to just create a GitHub account specifically for this project? The username could be something like on-media-query? Similar to https://github.com/jquery? Overkill? Alternatively, maybe setup a GitHub organization? Overkill as well?

Speaking of, I published my develop branch to my master branch... The latest demo is here (you might need to do a shift + refresh to dump cache if you've been there before.).

Slight change of topics...

If you don't mind, take a look at my fork and my change log...

First, I think my fork solves Issue #7, Issue #8 and Issue #9.

Second, I've worked pretty hard to (IMHO) improve the repo...

From little things like an authors and contributors files to defining/caching lengths of objects/arrays before looping (e.g. for (var i = 0, l = this._callbacks.length; i < l; i++) { ... } and adding functionality for wider browser acceptance (last time I checked, and maybe things have changed in the last couple months, but Opera and font-family dont mix, at least from what my tests showed).

In terms of specifics (some of this is covered in CHANGELOG.md):

• I've simplified the closure
• I've started to version the code (loosely following the semver system.)
• The JS has been thoroughly cleaned (I prefer tabs for indentation and I only use spaces for Python).
• All of the methods have consistent JS doc style comments.
• I've converted non API methods into private functions; so, in other words, only the methods that people need to use are publicly exposed.
• I changed new_context and context vars to context and last_context respectively.
  • I thought this made more sense logically... Before my change, new_context was really the current "context" and context was really the "last context"... So, that's why I thought it made sense to change them. :)
  • I've also changed this.context and this.last_context to this._context and this._last_context now that we have getters for these member variables.
• I've made some tweaks to Pat's additions:
  • getContext(): This method can be called before oMQ has been instantiated.
  • This solves Issue #9
    • I've added a _pickContext() method that is used in the getContext() getter.
  • I changed getPreviousContext() to getLastContext() (to match the variable name).
  • If there is no last context, then the current context is returned. Reasoning: When using addQuery(), when the page first loads, the "last context" returned IS the "current context", so I wanted the return values to be consistent.
• The demo has been simplified signifcantly (I prefer a frills-free demo page, for clarity's sake).
• I've setup develop and gh-pages (that's just a mirror of my master branch) branches... Note: I'm not sure if these will xfer in a pull request, but I'd gladly help you set things up. I find that a develop branch is great for unstable commits, and then I merge develop to master for a public release, and then merge master into gh-pages for the demo page access.
• I've been tagging releases as well. Again, not sure if these will transfer on a pull request, but that's not a biggy... :)
• I dropped the minified version. Reasoning:

people can minify using that online YUI Compressor-based tool (included in the readme), or as part of their build process. (via necolas)

• ...I think the latest trend is for folks to use someting like Grunt and the build process will take into account the minification. Not to mention, it saves time not having to worry about adding a min version for every new version of the JS. :)

So, with that said (sorry it's so long winded):

1. Josh/Pat, any objections to pulling my code into your branch? I won't be offended if anyone takes any issues with my changes. :)
2. Would you be interested, and/or, is it a good idea to start a new account with the new name on-media-query (like jQuery does)? Overkill? I'd still be game for a new repo name under the JoshBarr account. Maybe a GitHub organization might do the trick? Is that overkill? Just spitballing some ideas here. Really, I woud not mind researching the best option here... There has to be a good workflow for this type of team repo/project (Organization has worked out great for my work, but maybe that's overkill for this.)
3. Not sure how helpful you guys would find this info, but I've documented some of my workflow here; I use GitHub for Mac (windows here)... It makes things so easy (I don't mind using command line, but the app rocks).

Thoughts?

Ok, back to work...

Thanks! Micky

[patocallaghan]

Re: the repo name change, what about doing the reverse of what I suggested earlier? If you really wanted to change the name, rename this repo to on-media-query as before, this means you retain forks, commit history and followers etc....js-media-queries will then 404 but to fix that create a new repo called js-media-queries and just have a README.md which points to the new on-media-query repo..you then retain all your history etc and the 404 issue is somewhat solved....

Re: the rest, some nice changes in there especially the font-family/:before stuff but this is Josh's baby so the buck stops with him....

[mhulse]

Re: the repo name change, what about doing the reverse of what I suggested earlier? If you really wanted to change the name, rename this repo to on-media-query as before, this means you retain forks, commit history and followers etc....js-media-queries will then 404 but to fix that create a new repo called js-media-queries and just have a README.md which points to the new on-media-query repo..you then retain all your history etc and the 404 issue is somewhat solved....

I like that idea. :+1:

Re: the rest, some nice changes in there especially the font-family/:before stuff but this is Josh's baby so the buck stops with him....

Totally agree... I won't be offended if the answer is "no". Or, if you have any requests to change things so it's more acceptable, I'm open minded to that as well. :)

[mhulse]

Re-focusing issue: #17